On 01/07/11 15:52, Manuel Simoni wrote: > Hi Tahoe folks! > > I've been thinking about two issues related to Tahoe+Web: > > By putting the read-cap after the URL fragment, e.g. > > http://example.com/path/to/file#cap > > one can guarantee that the cap is never sent over the network when the > link is clicked. Combined with in-browser JavaScript crypto code, one > doesn't even need a trusted gateway; a stupid WebDAV server will do as > ciphertext storage.
The cap does need to be sent over the network to the gateway, even if it is in a different request. The motivation would be to not have the browser send it directly as part of the URL, on the grounds that it may not handle request URLs as securely as other data (for example, they may be leaked in HTTP Referer headers). The Tahoe developers are aware of this idea and refinements of it (see <http://waterken.sourceforge.net/web-key/>), but: - we want any dependency of the web API on JavaScript to remain optional. - this technique would still need a trusted gateway. Implementing the Tahoe decoding and decryption in JavaScript is possible in principle, but is a large amount of work, and not a current priority. Even if that were done, some trusted server would need to provide the JavaScript (unless it is installed as a browser add-on, which is yet more work). - the technique works well for HTML but is more difficult to apply for other content-types. We would still want to support download of arbitrary files. There are similar techniques for preventing the leak via Referer that don't necessarily depend on JavaScript and that work for arbitrary content types; see <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/127#comment:21>. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
