<p>Welcome to Tahoe, the Least-Authority Filesystem. Tahoe-LAFS is the first cloud storage technology with <em>provider-independent security</em>.</p>
<h2>provider-independent security?</h2>
<p>Every seller of cloud storage services will tell you that their service is secure. But what they mean by that is something fundamentally different from what we mean. What they mean by "secure" is that they try really hard not to misuse the power to read or modify your data. This turns out to be hard. Bugs, misconfigurations, and operator error can accidentally expose your data to another customer or to the public, or can corrupt your data. Criminals routinely gain illicit access to corporate servers. More insidiously, employees of the service provider itself may read or modify your data out of carelessness, avarice, or mere curiousity. The most conscientious of these service providers spend considerable effort and expense trying to mitigate these risks.</p>
<p>What we mean by "security" is something different. <em>The service provider never has the ability to read or modify your data in the first place.</em> Never. If you use Tahoe-LAFS, then all of the threats described above are non-issues to you. Not only is it easy for the service provider to avoid exposing or corrupting your data, but in fact they couldn't do so if they tried. This is what we call <em>provider-independent security</em>.</p>
<p>(See also <ahref="http://testgrid.allmydata.org:3567/file/URI:CHK:4rd7ous7b5xgbmpan6mmdbx3za:2jywqfnobreondkanwnekugmxv3cyuzdv34fpyazkb5htjmokdta:3:10:102761/@@named=/network-and-reliance-topology-paranoid.png">Tahoe-LAFS for Paranoids</a> and <ahref="http://testgrid.allmydata.org:3567/file/URI:CHK:mpa737uu7suao7lva2axhbtgw4:5rpemho4d3cqsgvgsqmg3hbn2mzeibsbdpthmpyo5jwnj7f2fqfa:3:10:114022/@@named=/network-and-reliance-topology-corporate.png">Tahoe-LAFS for Corporates</a>.)</p>
<p>The filesystem is encrypted and spread over multiple servers in such a way that it continues to function even when some of the servers are unavailable, malfunctioning, or malicious.</p>
<p>A "storage grid" is made up of a number of storage servers. A storage server has local attached storage (typically one or more hard disks). A "gateway" uses the storage servers and provides access to the filesystem over HTTP(S) or (S)FTP.</p>
<p>Users do not rely on storage servers to provide <i>confidentiality</i> nor <i>integrity</i> for their data -- instead all of the data is encrypted and integrity-checked by the gateway, so that the servers can neither read nor modify the contents of the files.</p>
<p>Users rely on storage servers for <i>availability</i>. The ciphertext is erasure-coded and distributed across <cite>N</cite> storage servers (the default value for <cite>N</cite> is 10) so that it can be recovered from any <cite>K</cite> of these servers (the default value of <cite>K</cite> is 3). Therefore only the simultaneous failure of <cite>N-K+1</cite> (with the defaults, 8) servers can make the data unavailable.</p>
<p>In the typical deployment mode each user runs her own gateway on her own machine. This way she relies on her own machine for the confidentiality and integrity of the data.</p>
<p>An alternate deployment mode is that the gateway runs on a remote machine and the user connects to it over HTTPS or SFTP. This means that the operator of the gateway can view and modify the user's data (the user <i>relies on</i> the gateway for confidentiality and integrity), but the user can access the filesystem with a client that doesn't have the gateway software installed, such as an Internet kiosk or cell phone.</p>
<p>There are two kinds of files: immutable and mutable. Immutable files have the property that once they have been uploaded to the storage grid they can't be modified. Mutable ones can be modified. A user can have read-write access to a mutable file or read-only access to it (or no access to it at all).</p>
<p>A user who has read-write access to a mutable file or directory can give another user read-write access to that file or directory, or they can give read-only access to that file or directory. A user who has read-only access to a file or directory can give another user read-only access to it.</p>
<p>When linking a file or directory into a parent directory, you can use a read-write link or a read-only link. If you use a read-write link, then anyone who has read-write access to the parent directory can gain read-write access to the child, and anyone who has read-only access to the parent directory can gain read-only access to the child. If you use a read-only link, then anyone who has either read-write or read-only access to the parent directory can gain read-only access to the child.</p>
<p>For more technical detail, please see <ahref="architecture.txt">architecture.txt</a> and the <ahref="http://allmydata.org/trac/tahoe/wiki/Doc">The Doc Page</a> on the Wiki.</p>
<p>You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file <ahref="../COPYING.GPL">COPYING.GPL</a> for the terms of the GNU General Public License, version 2.</p>
<p>You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to wait for up to twelve months after you redistribute a derived work before releasing the source code of your derived work. See the file <ahref="../COPYING.TGPPL.html">COPYING.TGPPL.html</a> for the terms of the Transitive Grace Period Public Licence, version 1.</p>
<p>If you would like to inquire about a commercial relationship with Allmydata, Inc., please contact <ahref="mailto:partnerships@allmydata.com">partnerships@allmydata.com</a> and visit <ahref="http://allmydata.com">http://allmydata.com</a>.
