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... _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
