Folks: This issue has been bothering me for a while, and it just came up again in the context of #1425 (blacklist support):
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1425#comment:27 """ When releasing 1.9, we should go to extra effort to communicate what this change does and doesn't do. I've been learning that almost all users have very simpleminded models of things, for example I think the existence of the public web gateway made most users think that Tahoe-LAFS was nothing more than some sort of online service. Explaining this feature (in the NEWS/release-notes/etc.) may be a good opportunity to explain the difference between running your own software (Tahoe-LAFS storage client) to upload or download files vs. visiting a web server (Tahoe-LAFS gateway) operated by someone else and asking them to serve files to you. This feature lets the operator of a Tahoe-LAFS storage client (== Tahoe-LAFS gateway == the web server in question) configure their software so it refuses to serve certain files (to anyone). It does not give them any ability to affect whether other Tahoe-LAFS storage clients/gateways access those files. How can we make this clear? Maybe the only way to make this clear is to create a variant of http://tahoe-lafs.org/~zooko/network-and-reliance-topology.png which shows multiple gateways in use, and indicate on that diagram that the blacklisting feature affects only the single gateway that chooses to use it. """ The way this sort of thing has come up before is the way that a lot of people seemed to think that the publicly accessible demo gateway *was* Tahoe-LAFS, or that it somehow added Tahoe-LAFS's security properties to your data when you used it as a public pastebin. We tried to disabuse them of that mistake, first by changing the URL from "pubgrid.tahoe-lafs.org" to "insecure.tahoe-lafs.org", and then by adding a prominent warning (in Mandarin Chinese) on the front page, and then we eventually just took down the public demo gateway altogether. This is actually pretty important because all of Tahoe-LAFS's unique security properties obtain *only* when you operate your own gateway. If you run your own gateway then rely *only* on your own computer for the confidentiality and integrity of the files. That fact is what is new and cool about Tahoe-LAFS! If you use someone else's gateway, then you simply rely on *that computer* for those properties, which means you would be vulnerable to anyone who controls that computer (including its owner and any attacker who can take over control of it). That gives you no particular security properties. From your perspective, whether the host is running Tahoe-LAFS to serve those files to you from a storage grid or whether they are running Apache to serve those files to you from their hard disk makes no difference [*]. What do you think? Did you used to confuse these two concepts in your mind, and if so, what clarified it for you? Can you think of a way to explain the difference between these two deployment modes? I've (perhaps somewhat cynically) started to think that people can only keep one thing in their minds at a time. Maybe we need to stop telling newcomers about the concept of "letting other people use your gateway", and instead just tell them that the way to use Tahoe-LAFS is to run your own gateway on your local computer and then use it yourself. Regards, Zooko [*] There is actually a difference, which is that the capabilities are visible in the URLs so you could in theory set up your own gateway and then use it to download the same file and *double-check* whether they had violated integrity by unauthorizedly modifying the file they had earlier served to you. However, as long as you don't do that, then there is no difference between using a Tahoe-LAFS gateway and using an apache web server. _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
