[tahoe-dev] new project

Brian Warner warner at lothar.com
Tue Sep 4 22:34:55 UTC 2012


On 8/18/12 3:29 PM, Nathan wrote:
> 
> Perhaps one of the "smoothest" user experiences for that particular
> use case is to have a tahoe-lafs gateway embedded in the browser as a
> plugin or extension. The html payload I send Alice, when opened, will
> say "You need the Tahoe-LAFS plugin/extension/add-on to view this
> page".

> Furthermore, the same-origin issue *may* be addressable by an
> extension.

For sure. Extensions can do anything.

> I recall that Warner was prototyping a kind of "Tahoe next gen" which
> started from the browser UI and worked from there backwards toward the
> platform level. Warner, does this use case fit with your
> prototype/vision at all?

Yeah. Some of my thinking is recorded in the "storage-club URLs" message
from last year:

  https://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006159.html

Distributed content can be referenced by normal-looking HTTP URLs, which
are either resolved by helper gateways (revealing the filecaps and
plaintext to the gateways and some set of SSL PKI parties), or by a
browser plugin (preserving all the expected security properties). In my
storage-club scheme, the data is always accessible: installing extra
code just improves your security (by removing dependence upon others).

You could flip that around, so that data was *not* retrievable unless
you'd installed the extra code, in exchange for limiting your security
exposure to other parties. The most hard-core way to do that would be to
use a completely custom URL scheme (maybe starting with "lafs:"). Such
links would resolve normally for extension-enhanced browsers, and would
be completely unusable on vanilla browsers ("fail-stop").

You could also go halfway, maybe by using "http://STUFF#FILECAP", and
arrange a server at STUFF to return some help text (and an install link
for the addon), so vanilla browser users get instructions without
immediately leaking the filecap. However the filecap would still be
pretty vulnerable: anyone who could influence the response (at least the
help-text server, but also the CAs) could instead return javascript that
reads the filecap off window.location and delivers it to the bad guy of
your choice.

I don't know how to get both safety against everybody and
downgrade-to-instructions for unmodified browsers, at least when the
payload is just a single URL.

If the payload can be an HTML fragment, then I can imagine something
like:

 <div class="lafs-url" display="none"><a
href="lafs://FILECAP">here</a></div>
 <div class="lafs-help">Please install the browser plugin from HERE..</div>

A vanilla browser would show the instructions but not the link. Once
installed, the plugin could scan pages for these CSS classes and hide
the instructions while revealing the link. The same technique is used to
show a "this page needs javascript" message to non-JS-enabled browsers.

cheers,
 -Brian



More information about the tahoe-dev mailing list