docs/about.rst

   1 .. -*- coding: utf-8-with-signature -*-
   2
   3 Welcome to Tahoe-LAFS!
   4 ======================
   5
   6 Welcome to Tahoe-LAFS_, the first decentralized storage system with
   7 *provider-independent security*.
   8
   9 .. _Tahoe-LAFS: https://tahoe-lafs.org
  10
  11 What is "provider-independent security"?
  12 ========================================
  13
  14 Every seller of cloud storage services will tell you that their service is
  15 "secure".  But what they mean by that is something fundamentally different
  16 from what we mean.  What they mean by "secure" is that after you've given
  17 them the power to read and modify your data, they try really hard not to let
  18 this power be abused.  This turns out to be difficult!  Bugs,
  19 misconfigurations, or operator error can accidentally expose your data to
  20 another customer or to the public, or can corrupt your data.  Criminals
  21 routinely gain illicit access to corporate servers.  Even more insidious is
  22 the fact that the employees themselves sometimes violate customer privacy out
  23 of carelessness, avarice, or mere curiosity.  The most conscientious of
  24 these service providers spend considerable effort and expense trying to
  25 mitigate these risks.
  26
  27 What we mean by "security" is something different.  *The service provider
  28 never has the ability to read or modify your data in the first place: never.*
  29 If you use Tahoe-LAFS, then all of the threats described above are non-issues
  30 to you.  Not only is it easy and inexpensive for the service provider to
  31 maintain the security of your data, but in fact they couldn't violate its
  32 security if they tried.  This is what we call *provider-independent
  33 security*.
  34
  35 This guarantee is integrated naturally into the Tahoe-LAFS storage system and
  36 doesn't require you to perform a manual pre-encryption step or cumbersome key
  37 management.  (After all, having to do cumbersome manual operations when
  38 storing or accessing your data would nullify one of the primary benefits of
  39 using cloud storage in the first place: convenience.)
  40
  41 Here's how it works:
  42
  43 .. image:: network-and-reliance-topology.svg
  44
  45 A "storage grid" is made up of a number of storage servers.  A storage server
  46 has direct attached storage (typically one or more hard disks).  A "gateway"
  47 communicates with storage nodes, and uses them to provide access to the
  48 file store over protocols such as HTTP(S), SFTP or FTP.
  49
  50 Note that you can find "client" used to refer to gateway nodes (which act as
  51 a client to storage servers), and also to processes or programs connecting to
  52 a gateway node and performing operations on the grid -- for example, a CLI
  53 command, Web browser, SFTP client, or FTP client.
  54
  55 Users do not rely on storage servers to provide *confidentiality* nor
  56 *integrity* for their data -- instead all of the data is encrypted and
  57 integrity-checked by the gateway, so that the servers can neither read nor
  58 modify the contents of the files.
  59
  60 Users do rely on storage servers for *availability*.  The ciphertext is
  61 erasure-coded into ``N`` shares distributed across at least ``H`` distinct
  62 storage servers (the default value for ``N`` is 10 and for ``H`` is 7) so
  63 that it can be recovered from any ``K`` of these servers (the default
  64 value of ``K`` is 3).  Therefore only the failure of ``H-K+1`` (with the
  65 defaults, 5) servers can make the data unavailable.
  66
  67 In the typical deployment mode each user runs her own gateway on her own
  68 machine.  This way she relies on her own machine for the confidentiality and
  69 integrity of the data.
  70
  71 An alternate deployment mode is that the gateway runs on a remote machine and
  72 the user connects to it over HTTPS or SFTP.  This means that the operator of
  73 the gateway can view and modify the user's data (the user *relies on* the
  74 gateway for confidentiality and integrity), but the advantage is that the
  75 user can access the file store with a client that doesn't have the gateway
  76 software installed, such as an Internet kiosk or cell phone.
  77
  78 Access Control
  79 ==============
  80
  81 There are two kinds of files: immutable and mutable. When you upload a file
  82 to the storage grid you can choose which kind of file it will be in the
  83 grid. Immutable files can't be modified once they have been uploaded.  A
  84 mutable file can be modified by someone with read-write access to it. A user
  85 can have read-write access to a mutable file or read-only access to it, or no
  86 access to it at all.
  87
  88 A user who has read-write access to a mutable file or directory can give
  89 another user read-write access to that file or directory, or they can give
  90 read-only access to that file or directory.  A user who has read-only access
  91 to a file or directory can give another user read-only access to it.
  92
  93 When linking a file or directory into a parent directory, you can use a
  94 read-write link or a read-only link.  If you use a read-write link, then
  95 anyone who has read-write access to the parent directory can gain read-write
  96 access to the child, and anyone who has read-only access to the parent
  97 directory can gain read-only access to the child.  If you use a read-only
  98 link, then anyone who has either read-write or read-only access to the parent
  99 directory can gain read-only access to the child.
 100
 101 For more technical detail, please see the `the doc page`_ on the Wiki.
 102
 103 .. _the doc page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc
 104
 105 Get Started
 106 ===========
 107
 108 To use Tahoe-LAFS, please see quickstart.rst_.
 109
 110 .. _quickstart.rst: quickstart.rst
 111
 112 License
 113 =======
 114
 115 Tahoe-LAFS is an open-source project; please see README.rst_ for details.
 116
 117 .. _README.rst: ../README.rst