On Wed, Jun 1, 2011 at 11:42 AM, toby cabot <[email protected]> wrote: > > I'm starting to play around with Tahoe-LAFS and it looks very > interesting. The quickstart instructions and public storage grid make > it quick and easy to get going. Thanks!
I'm delighted to hear this! Please let us know if there's more we can do to make it easy for people to experiment with Tahoe-LAFS. > I have a question about sharing files with other people and I can't > find the answer on the site but I hope this isn't a FAQ. We should write a FAQ about this! But the answer might be long. Might need to be its own wiki page. Any volunteers? > If I run my > own client with the web user interface, I imagine that I can share > files by simply giving someone a directory URL. Could they then give > this URL to someone else, perhaps someone that I wouldn't want to see > the directory? Is there an authentication component that I'm missing? Yes they could. There is no other authentication component built into Tahoe-LAFS at this time. > If I give someone a URL to a directory can I later revoke that URL > somehow but still be able to access the directory myself? This totally depends on how you are sharing. In terms of the "Tahoe-LAFS network topology" graph -- http://tahoe-lafs.org/~zooko/network-and-reliance-topology.png -- you can share with someone else either by letting them connect to your Tahoe-LAFS gateway with an HTTP client or by letting them connect to the storage servers with a Tahoe-LAFS gateway. The former has more or less the same access control properties as any HTTP server. The latter's access control policies are further constrained by the fact that the user doesn't have to go through your gateway. If you let them connect to your Tahoe-LAFS gateway with an HTTP client then you can enforce whatever access control policies you like, just as with any other HTTP server. They are completely vulnerable to your HTTP-server/Tahoe-LAFS-gateway for availability (whether they get the file or not when they request it), as well as for confidentiality (your HTTP server can read the contents of any file they request), as well as for integrity (your HTTP server can change the contents of any file they request before they see the file). This is the approach that I was suggesting to Brandon Meskimen in my recent post: [1]. If you let them connect to the storage servers with their own Tahoe-LAFS gateway, then you can't use your control over the gateway to enforce your own access control policies. There are advantages to this—you eliminate a Single Point of Failure in your system and the end user can verify the confidentiality and integrity of the data directly by relying on their own Tahoe-LAFS gateway. What do you think? Let's talk about this more. I'm fairly proud of the access control scheme that Tahoe-LAFS already offers (which is summarized in [2] and detailed in [3]). I think it is a powerful and flexible architecture to build on top of. But I'm sure that it can be improved, both by building more apps on top of it and by extending the behavior of Tahoe-LAFS itself (#152, #795, #954, #958). Feedback from real users about what they want, and more importantly what the experience when they *try* it, is extremely valuable for this project. Regards, Zooko http://tahoe-lafs.org/trac/tahoe-lafs/ticket/152# build "sharing slots" / use mutable files as primitives for sharing messages http://tahoe-lafs.org/trac/tahoe-lafs/ticket/795# append-only files http://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revoke write authority http://tahoe-lafs.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently [1] http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006394.html [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-control [3] http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Capabilities _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
