]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commitdiff
docs: about.html: edit (hopefully improve) the "What Makes Tahoe-LAFS Different"...
authorZooko O'Whielacronx <zooko@zooko.com>
Sun, 2 Aug 2009 02:27:33 +0000 (19:27 -0700)
committerZooko O'Whielacronx <zooko@zooko.com>
Sun, 2 Aug 2009 02:27:33 +0000 (19:27 -0700)
docs/about.html

index 820598e415307893d77043b7d26f8b89370d6c62..618134056c6e061a3fc7e2d6cc0a0ca12a303768 100644 (file)
@@ -9,19 +9,18 @@
 
   <body>
     <h1>Welcome to Tahoe-LAFS</h1>
-    <p>Welcome to Tahoe, the Least-Authority Filesystem.  Tahoe-LAFS is the first cloud storage technology with <em>provider-independent security</em>.</p>
+    <p>Welcome to Tahoe-LAFS, the first cloud storage system with <cite>provider-independent security</cite>.</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>All that, and we don't sacrifice convenience or ease-of-use!  Here's how it works.</p>
+    <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 after you've given them the power to read and modify your data, they try really hard not to let this power be misued.  This turns out to be difficult!  Bugs, misconfigurations, or 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 violate your privacy 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 and inexpensive for the service provider to maintain the security of your data, but in fact they couldn't violate its security if they tried.  This is what we call <em>provider-independent security</em>.</p>
+    <p>This guarantee is integrated naturally into the cloud storage framework and doesn't require you to perform a manual pre-encryption step or cumbersome key management.  (After all, having to do cumbersome manual operations when storing or accessing your data would nullify one of the primary benefits of using cloud storage in the first place.)</p>
+    <p>Here's how it works.</p>
 
     <img src="http://allmydata.org/~zooko/network-and-reliance-topology.png"></img>
 
     <p>(See also <a href="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 <a href="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>