On Fri, Jun 12, 2009 at 8:19 PM, Brian Warner<[email protected]> wrote: > > Revocation is a complicated topic. As Kevin said, it basically requires an > intermediary, which might either be a single proxy/gatekeeper or something > distributed (like an intermediate tahoe directory that you can later empty). > Any extra layer will hurt availability/reliability in hard-to-model ways > (what if the proxy is down? what is the probability two directories are > recoverable versus just a single directory?).
Revocation is complicated! And we can't ignore it. We probably need to start using more precise terminology to discuss it. I can think of three kinds of revocation that I might want. One is revocation of read authority to an immutable file. I might want to give someone the ability to read an immutable file and later revoke that ability of theirs. On the other hand, I don't want this very much, because I know that they could have already downloaded it and saved a copy and there's nothing I can do about it. Ping Yee suggested that the user interface should say "send the file" to someone when you give them an immutable-read-cap (rather than "share the file" or "sending a link"). The next is revocation of read authority a mutable file or directory. This is more useful. I may have given many people read-access to a directory, and now I want to make it so that one of them won't be able to see *new* updates that I make to that directory, but the others will be able to. This is a reasonable thing to want to do, and we need to figure out how to offer this without losing too much availability/reliability and without giving some central administrator control over what everyone is allowed to read. The next is revocation of write authority to a mutable file or directory. This is actually the most urgent! Because if you need this one, you can't just work-around it by some quick, safe (but inconvenient) technique like you can with the previous one. Here's an example from real experience: I had a blog on Tahoe at this address: http://tahoebs1.allmydata.com:8123/uri/URI:DIR2-RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html . Then one day I accidentally leaked the secrets which control write access to the blog. Now what I most need to do at that time is to revoke those secrets. (Note: all access control systems have the problem that the authority used to allow access can leak and they need to offer revocation of that authority -- this is not a problem unique to capability access control.) Fortunately this last one is also the easiest to implement in a robust way -- we simply need to define a special "freeze" message that puts a mutable file or directory into a state where it can't be changed again (including that it can't be unfrozen). If I had that, then after updating my old blog to announce that it had moved to a new location, I could freeze it and would then be safe from the danger that someone else would take it over and make updates to it in my name. Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
