[tahoe-dev] How to use Caja to solve the same-origin policy hazard (hosting both webapps and untrusted content in Tahoe)

Zooko O'Whielacronx zooko at zooko.com
Sat Jul 30 15:06:43 UTC 2011


Dear Kevin:

Your letter fills me with internal conflict!

On the one hand I'm delighted because what you propose is not only the
best way to further protect against the dangers of looking at files
stored inTahoe-LAFS through a web browser, but it also opens up the
possibility of even better decentralized web apps. That's because caja
supports the safe composition of mutually distrusting Javascript
programs. What could people do with that? I'm not sure, but I have a
feeling it could be fantastic.

On the other hand: Java.

I hate Java, and I hate the JVM. And even if I could hold my nose and
overcome my personal antipathy, the fact that caja requires Java to
run the cajoler imposes a huge difficulty in terms of packaging and
deployment for Tahoe-LAFS. I haven't thought through all the details
yet, but would it would mean the end of the "quickstart" procedure
[1]? With the quickstart procedure, users on any operating system can
build Tahoe-LAFS themselves from source. (This currently works most of
the time for most users.) If we can no longer support that method of
deployment, that would herald the beginning of a new era in which
users (who aren't skilled developers) can't really use the source code
themselves but need to rely on someone else to provide them with a
prebuilt package.

That would be regrettable, but I guess it would be worth it, since it
is probably the best way to further improve the WUI's safety and the
only way to allow safe composition of mutually distrusting Javascript.

Regards,

Zooko

[1] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/quickstart.rst



More information about the tahoe-dev mailing list