[tahoe-dev] Giving away the farm (was Re: Google Summer of Code 2010 -- Ideas Needed!)

Chris Palmer chris at noncombatant.org
Fri Mar 12 18:27:16 PST 2010


Jeremy Fitzhardinge writes:

> An aside, this URL represents a (presumed) error I've been desperately
> afraid of making myself because it seems so easy to do.  This is a
> *writable* directory cap, so Toby has given away the farm on this
> directory, and we have no idea whether the explorer.zip referred to is the
> one he intended.

There is also the threat of copy/paste mishaps. As they should be, the
gestures to perform pasting are very easy and habituatable. Have you ever
swiped your mouse across an array of xterms and pasted your email into IRC
by accident? :)

> I have no idea how to address this.  The problem is fundamental to a
> capability system, so the question is: how to mitigate it?

Octavia's approach is/will be to get the sensitive thing out of the primary
UI. There are still cryptographic references/capabilities/magic beans, but
they are stored in a "directory descriptor" file (one per directory). The
intent is for the UI to be the user's normal means of filesystem navigation
(Windows Explorer, bash, Finder.app), and the client software cares about
the directory descriptors and manages them behind the scenes.

If a user wants to share, they have to leave the primary UI flow, retrieve
the descriptor file, and send it to their friend --- it's not in the
windowing system's clipboard as a matter of course.

And when you share a descriptor, that is read-only access: the descriptor
tells your friend how to get blocks and how to decrypt them, but your friend
still has to have registrations with servers that allow them to write. And
when they write, they are forking, not updating your copy.

In fact, my current big problem is how to reconcile divergent updates...



More information about the tahoe-dev mailing list