Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] ANNOUNCING Tahoe, the Lofty Atmospheric Filesystem, v1.5

Expand Messages
  • Lucas Gonze
    What s the difference between a cloud storage system and a decentralized p2p storage system, Zooko?
    Message 1 of 11 , Aug 3, 2009
    • 0 Attachment
      What's the difference between a cloud storage system and a decentralized
      p2p storage system, Zooko?

      zookoy2 wrote:
      > Folks:
      >
      > I'm pitching Tahoe-LAFS as a cloud storage system, and it has commercial use as a cloud storage system, but it is actually a decentralized p2p storage system which acts as a cloud storage system in one particular configuration.
      >
      > Regards,
      >
      > Zooko
      >
      > ---
      >
      > The Tahoe-LAFS team is pleased to announce the immediate
      > availability of version 1.5 of Tahoe, the Lofty Atmospheric
      > File System.
      >
      > Tahoe-LAFS is the first cloud storage technology which offers
      > security and privacy in the sense that the cloud storage
      > service provider itself can't read or alter your data. Here is
      > the one-page explanation of its unique security and
      > fault-tolerance properties:
      >
      > http://allmydata.org/source/tahoe/trunk/docs/about.html
      >
      > This release is the successor to v1.4.1, which was released
      > April 13, 2009 [1]. This is a major new release, improving the
      > user interface and performance and fixing a few bugs, and
      > adding ports to OpenBSD, NetBSD, ArchLinux, NixOS, and embedded
      > systems built on ARM CPUs. See the NEWS file [2] for more
      > information.
      >
      > In addition to the functionality of Tahoe-LAFS itself, a crop
      > of related projects have sprung up to extend it and to
      > integrate it into operating systems and applications. These
      > include frontends for Windows, Macintosh, JavaScript, and
      > iPhone, and plugins for duplicity, bzr, Hadoop, and TiddlyWiki,
      > and more. See the Related Projects page on the wiki [3].
      >
      >
      > COMPATIBILITY
      >
      > Version 1.5 is fully compatible with the version 1 series of
      > Tahoe-LAFS. Files written by v1.5 clients can be read by
      > clients of all versions back to v1.0. v1.5 clients can read
      > files produced by clients of all versions since v1.0. v1.5
      > servers can serve clients of all versions back to v1.0 and v1.5
      > clients can use servers of all versions back to v1.0.
      >
      > This is the sixth release in the version 1 series. The version
      > 1 series of Tahoe-LAFS will be actively supported and
      > maintained for the forseeable future, and future versions of
      > Tahoe-LAFS will retain the ability to read and write files
      > compatible with Tahoe-LAFS v1.
      >
      > The version 1 series of Tahoe-LAFS is the basis of the consumer
      > backup product from Allmydata, Inc. -- http://allmydata.com .
      >
      >
      > WHAT IS IT GOOD FOR?
      >
      > With Tahoe-LAFS, you can distribute your filesystem across a
      > set of servers, such that if some of them fail or even turn out
      > to be malicious, the entire filesystem continues to be
      > available. You can share your files with other users, using a
      > simple and flexible access control scheme.
      >
      > We believe that the combination of erasure coding, strong
      > encryption, Free/Open Source Software and careful engineering
      > make Tahoe-LAFS safer than RAID, removable drive, tape, on-line
      > backup or other Cloud storage systems.
      >
      > This software comes with extensive tests, and there are no
      > known security flaws which would compromise confidentiality or
      > data integrity in typical use. (For all currently known issues
      > please see the known_issues.txt file [4].)
      >
      >
      > LICENCE
      >
      > You may use this package under the GNU General Public License,
      > version 2 or, at your option, any later version. See the file
      > "COPYING.GPL" [5] for the terms of the GNU General Public
      > License, version 2.
      >
      > 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 "COPYING.TGPPL.html" [6] for the terms of the
      > Transitive Grace Period Public Licence, version 1.
      >
      > (You may choose to use this package under the terms of either
      > licence, at your option.)
      >
      >
      > INSTALLATION
      >
      > Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris,
      > *BSD, and probably most other systems. Start with
      > "docs/install.html" [7].
      >
      >
      > HACKING AND COMMUNITY
      >
      > Please join us on the mailing list [8]. Patches are gratefully
      > accepted -- the RoadMap page [9] shows the next improvements
      > that we plan to make and CREDITS [10] lists the names of people
      > who've contributed to the project. The Dev page [11] contains
      > resources for hackers.
      >
      >
      > SPONSORSHIP
      >
      > Tahoe-LAFS was originally developed thanks to the sponsorship
      > of Allmydata, Inc. [12], a provider of commercial backup
      > services. Allmydata, Inc. created the Tahoe-LAFS project and
      > contributed hardware, software, ideas, bug reports,
      > suggestions, demands, and money (employing several Tahoe-LAFS
      > hackers and instructing them to spend part of their work time
      > on this Free Software project). Also they awarded customized
      > t-shirts to hackers who found security flaws in Tahoe-LAFS (see
      > http://hacktahoe.org ). After discontinuing funding of
      > Tahoe-LAFS R&D in early 2009, Allmydata, Inc. has continued to
      > provide servers, co-lo space and bandwidth to the open source
      > project. Thank you to Allmydata, Inc. for their generous and
      > public-spirited support.
      >
      > This is the second release of Tahoe-LAFS which was created
      > solely as a labor of love by volunteers; developer time is no
      > longer funded by allmydata.com (see [13] for details).
      >
      > Zooko Wilcox-O'Hearn
      > on behalf of the Tahoe-LAFS team
      >
      > Special acknowledgment goes to Brian Warner, whose superb
      > engineering skills and dedication are primarily responsible for
      > the Tahoe implementation, and significantly responsible for the
      > Tahoe design as well, not to mention most of the docs and
      > tests. Tahoe-LAFS wouldn't exist without him.
      >
      > August 1, 2009
      > Boulder, Colorado, USA
      >
      > P.S. Just kidding about that acronym. "LAFS" actually stands
      > for "Lightweight Authorization File System". Or possibly for
      > "Least-Authority File System". There is no truth to the rumour
      > that it actually stands for "Long-lived Axe-tolerant File
      > System".
      >
      > [1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=3853
      > [2] http://allmydata.org/trac/tahoe/browser/NEWS?rev=4033
      > [3] http://allmydata.org/trac/tahoe/wiki/RelatedProjects
      > [4] http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt
      > [5] http://allmydata.org/trac/tahoe/browser/COPYING.GPL
      > [6] http://allmydata.org/source/tahoe/trunk/COPYING.TGPPL.html
      > [7] http://allmydata.org/source/tahoe/trunk/docs/install.html
      > [8] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
      > [9] http://allmydata.org/trac/tahoe/roadmap
      > [10] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=4035
      > [11] http://allmydata.org/trac/tahoe/wiki/Dev
      > [12] http://allmydata.com
      > [13] http://allmydata.org/pipermail/tahoe-dev/2009-March/001461.html
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • Marc Manthey
      ... i am just thinking clowd is on the net and decentralised is on each machine ?
      Message 2 of 11 , Aug 3, 2009
      • 0 Attachment
        Am 03.08.2009 um 17:55 schrieb Lucas Gonze:

        > What's the difference between a cloud storage system and a
        > decentralized
        > p2p storage system, Zooko?

        i am just thinking "clowd" is on the net and "decentralised " is on
        each machine ?


        >
        > zookoy2 wrote:
        >> Folks:
        >>
        >> I'm pitching Tahoe-LAFS as a cloud storage system, and it has
        >> commercial use as a cloud storage system, but it is actually a
        >> decentralized p2p storage system which acts as a cloud storage
        >> system in one particular configuration.
        >>
        >> Regards,
        >>
        >> Zooko
        >>
        >> ---
        >>
        >> The Tahoe-LAFS team is pleased to announce the immediate
        >> availability of version 1.5 of Tahoe, the Lofty Atmospheric
        >> File System.
        >>
        >> Tahoe-LAFS is the first cloud storage technology which offers
        >> security and privacy in the sense that the cloud storage
        >> service provider itself can't read or alter your data. Here is
        >> the one-page explanation of its unique security and
        >> fault-tolerance properties:
        >>
        >> http://allmydata.org/source/tahoe/trunk/docs/about.html
        >>
        >> This release is the successor to v1.4.1, which was released
        >> April 13, 2009 [1]. This is a major new release, improving the
        >> user interface and performance and fixing a few bugs, and
        >> adding ports to OpenBSD, NetBSD, ArchLinux, NixOS, and embedded
        >> systems built on ARM CPUs. See the NEWS file [2] for more
        >> information.
        >>
        >> In addition to the functionality of Tahoe-LAFS itself, a crop
        >> of related projects have sprung up to extend it and to
        >> integrate it into operating systems and applications. These
        >> include frontends for Windows, Macintosh, JavaScript, and
        >> iPhone, and plugins for duplicity, bzr, Hadoop, and TiddlyWiki,
        >> and more. See the Related Projects page on the wiki [3].
        >>
        >>
        >> COMPATIBILITY
        >>
        >> Version 1.5 is fully compatible with the version 1 series of
        >> Tahoe-LAFS. Files written by v1.5 clients can be read by
        >> clients of all versions back to v1.0. v1.5 clients can read
        >> files produced by clients of all versions since v1.0. v1.5
        >> servers can serve clients of all versions back to v1.0 and v1.5
        >> clients can use servers of all versions back to v1.0.
        >>
        >> This is the sixth release in the version 1 series. The version
        >> 1 series of Tahoe-LAFS will be actively supported and
        >> maintained for the forseeable future, and future versions of
        >> Tahoe-LAFS will retain the ability to read and write files
        >> compatible with Tahoe-LAFS v1.
        >>
        >> The version 1 series of Tahoe-LAFS is the basis of the consumer
        >> backup product from Allmydata, Inc. -- http://allmydata.com .
        >>
        >>
        >> WHAT IS IT GOOD FOR?
        >>
        >> With Tahoe-LAFS, you can distribute your filesystem across a
        >> set of servers, such that if some of them fail or even turn out
        >> to be malicious, the entire filesystem continues to be
        >> available. You can share your files with other users, using a
        >> simple and flexible access control scheme.
        >>
        >> We believe that the combination of erasure coding, strong
        >> encryption, Free/Open Source Software and careful engineering
        >> make Tahoe-LAFS safer than RAID, removable drive, tape, on-line
        >> backup or other Cloud storage systems.
        >>
        >> This software comes with extensive tests, and there are no
        >> known security flaws which would compromise confidentiality or
        >> data integrity in typical use. (For all currently known issues
        >> please see the known_issues.txt file [4].)
        >>
        >>
        >> LICENCE
        >>
        >> You may use this package under the GNU General Public License,
        >> version 2 or, at your option, any later version. See the file
        >> "COPYING.GPL" [5] for the terms of the GNU General Public
        >> License, version 2.
        >>
        >> 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 "COPYING.TGPPL.html" [6] for the terms of the
        >> Transitive Grace Period Public Licence, version 1.
        >>
        >> (You may choose to use this package under the terms of either
        >> licence, at your option.)
        >>
        >>
        >> INSTALLATION
        >>
        >> Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris,
        >> *BSD, and probably most other systems. Start with
        >> "docs/install.html" [7].
        >>
        >>
        >> HACKING AND COMMUNITY
        >>
        >> Please join us on the mailing list [8]. Patches are gratefully
        >> accepted -- the RoadMap page [9] shows the next improvements
        >> that we plan to make and CREDITS [10] lists the names of people
        >> who've contributed to the project. The Dev page [11] contains
        >> resources for hackers.
        >>
        >>
        >> SPONSORSHIP
        >>
        >> Tahoe-LAFS was originally developed thanks to the sponsorship
        >> of Allmydata, Inc. [12], a provider of commercial backup
        >> services. Allmydata, Inc. created the Tahoe-LAFS project and
        >> contributed hardware, software, ideas, bug reports,
        >> suggestions, demands, and money (employing several Tahoe-LAFS
        >> hackers and instructing them to spend part of their work time
        >> on this Free Software project). Also they awarded customized
        >> t-shirts to hackers who found security flaws in Tahoe-LAFS (see
        >> http://hacktahoe.org ). After discontinuing funding of
        >> Tahoe-LAFS R&D in early 2009, Allmydata, Inc. has continued to
        >> provide servers, co-lo space and bandwidth to the open source
        >> project. Thank you to Allmydata, Inc. for their generous and
        >> public-spirited support.
        >>
        >> This is the second release of Tahoe-LAFS which was created
        >> solely as a labor of love by volunteers; developer time is no
        >> longer funded by allmydata.com (see [13] for details).
        >>
        >> Zooko Wilcox-O'Hearn
        >> on behalf of the Tahoe-LAFS team
        >>
        >> Special acknowledgment goes to Brian Warner, whose superb
        >> engineering skills and dedication are primarily responsible for
        >> the Tahoe implementation, and significantly responsible for the
        >> Tahoe design as well, not to mention most of the docs and
        >> tests. Tahoe-LAFS wouldn't exist without him.
        >>
        >> August 1, 2009
        >> Boulder, Colorado, USA
        >>
        >> P.S. Just kidding about that acronym. "LAFS" actually stands
        >> for "Lightweight Authorization File System". Or possibly for
        >> "Least-Authority File System". There is no truth to the rumour
        >> that it actually stands for "Long-lived Axe-tolerant File
        >> System".
        >>
        >> [1] http://allmydata.org/trac/tahoe/browser/relnotes.txt?rev=3853
        >> [2] http://allmydata.org/trac/tahoe/browser/NEWS?rev=4033
        >> [3] http://allmydata.org/trac/tahoe/wiki/RelatedProjects
        >> [4] http://allmydata.org/trac/tahoe/browser/docs/known_issues.txt
        >> [5] http://allmydata.org/trac/tahoe/browser/COPYING.GPL
        >> [6] http://allmydata.org/source/tahoe/trunk/COPYING.TGPPL.html
        >> [7] http://allmydata.org/source/tahoe/trunk/docs/install.html
        >> [8] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
        >> [9] http://allmydata.org/trac/tahoe/roadmap
        >> [10] http://allmydata.org/trac/tahoe/browser/CREDITS?rev=4035
        >> [11] http://allmydata.org/trac/tahoe/wiki/Dev
        >> [12] http://allmydata.com
        >> [13] http://allmydata.org/pipermail/tahoe-dev/2009-March/001461.html
        >>
        >>
        >>
        >> ------------------------------------
        >>
        >> Yahoo! Groups Links
        >>
        >>
        >>
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
      • Zooko O'Whielacronx
        ... Let s say that it is cloud if you are outsourcing the administration, i.e. if the infrastructure, servers, operating systems, networking etc. is being
        Message 3 of 11 , Aug 3, 2009
        • 0 Attachment
          On Mon, Aug 3, 2009 at 9:55 AM, Lucas Gonze<lucas@...> wrote:
          >
          >
          > What's the difference between a cloud storage system and a decentralized
          > p2p storage system, Zooko?

          Let's say that it is "cloud" if you are outsourcing the
          administration, i.e. if the infrastructure, servers, operating
          systems, networking etc. is being administered by pros and you are
          paying them for the service. Let's say it is "p2p" if you are
          benefiting from resources owned and administered by other users like
          you.

          Tahoe-LAFS is currently in use in "cloudy mode", where a bunch of
          end-user are paying allmydata.com to backup their files, and all of
          the computer resources are owned and operated by allmydata.com. It is
          also currently in use in p2p "friendnet" mode where a small group of
          friends provide each other with free storage service from their own
          machines. (Don't call it a darknet.)

          Because of its unique "least-authority" properties, Tahoe-LAFS would
          also lend itself to a "p2p cloud" topology -- let's call it
          "multi-provider cloud" -- where you are paying multiple independent
          service providers to give you service, so that if any subset of them
          fails you can keep on chugging. E.g. you can imagine paying for some
          storage space with Amazon and Rackspace and Nirvanix, and then using
          Tahoe-LAFS on top of that to ensure that if any one out of the three
          is currently functioning then you still have access to your
          filesystem.

          The reason why Tahoe-LAFS might be useful in that situation is that
          the security guarantees mean that the three service providers that you
          have hired have almost no power at all to interfere with each other's
          operation. This minimizes the opportunity for finger-pointing and
          confusion among them.

          Regards,

          Zooko
        • Lucas Gonze
          I wonder about applications for this feature. The one thing I can think of is items with very large scale political pressures attached. For example, in the US
          Message 4 of 11 , Aug 3, 2009
          • 0 Attachment
            I wonder about applications for this feature.

            The one thing I can think of is items with very large scale political
            pressures attached. For example, in the US the push to the 2nd Iraq
            war entailed the government convincing powerful companies like the New
            York Times to contribute to the push. (For example, with Judith
            Miller's writing).

            I could imagine a future where cloud storage becomes a de-facto
            duopoly along the same lines as search and operating systems, and
            where both duopolists are susceptible to pressure. Let's say it's
            Google and Facebook, they are both in monopoly investigations, and the
            FCC submits a covert order to to apply their ToS policies on planning
            crimes to organizations planning marches.


            On Mon, Aug 3, 2009 at 4:02 PM, Zooko O'Whielacronx<zookog@...> wrote:
            > On Mon, Aug 3, 2009 at 9:55 AM, Lucas Gonze<lucas@...> wrote:
            >>
            >>
            >> What's the difference between a cloud storage system and a decentralized
            >> p2p storage system, Zooko?
            >
            > Let's say that it is "cloud" if you are outsourcing the
            > administration, i.e. if the infrastructure, servers, operating
            > systems, networking etc. is being administered by pros and you are
            > paying them for the service.  Let's say it is "p2p" if you are
            > benefiting from resources owned and administered by other users like
            > you.
            >
            > Tahoe-LAFS is currently in use in "cloudy mode", where a bunch of
            > end-user are paying allmydata.com to backup their files, and all of
            > the computer resources are owned and operated by allmydata.com.  It is
            > also currently in use in p2p "friendnet" mode where a small group of
            > friends provide each other with free storage service from their own
            > machines.  (Don't call it a darknet.)
            >
            > Because of its unique "least-authority" properties, Tahoe-LAFS would
            > also lend itself to a "p2p cloud" topology -- let's call it
            > "multi-provider cloud" -- where you are paying multiple independent
            > service providers to give you service, so that if any subset of them
            > fails you can keep on chugging.  E.g. you can imagine paying for some
            > storage space with Amazon and Rackspace and Nirvanix, and then using
            > Tahoe-LAFS on top of that to ensure that if any one out of the three
            > is currently functioning then you still have access to your
            > filesystem.
            >
            > The reason why Tahoe-LAFS might be useful in that situation is that
            > the security guarantees mean that the three service providers that you
            > have hired have almost no power at all to interfere with each other's
            > operation.  This minimizes the opportunity for finger-pointing and
            > confusion among them.
            >
            > Regards,
            >
            > Zooko
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • Alen Peacock
            I think the point of decentralization over cloud services in this setting is reliability in lieu of security. Security should be (and is in tahoe) provided at
            Message 5 of 11 , Aug 3, 2009
            • 0 Attachment
              I think the point of decentralization over cloud services in this
              setting is reliability in lieu of security. Security should be (and is
              in tahoe) provided at the endpoints, and so as long as private keys
              remain private, even collusion among servers will reveal no secrets.

              However, I think you are right that collusion could allow for
              censorship.

              Alen



              On Aug 3, 2009, at 8:12 PM, Lucas Gonze <lucas@...> wrote:

              > I wonder about applications for this feature.
              >
              > The one thing I can think of is items with very large scale political
              > pressures attached. For example, in the US the push to the 2nd Iraq
              > war entailed the government convincing powerful companies like the New
              > York Times to contribute to the push. (For example, with Judith
              > Miller's writing).
              >
              > I could imagine a future where cloud storage becomes a de-facto
              > duopoly along the same lines as search and operating systems, and
              > where both duopolists are susceptible to pressure. Let's say it's
              > Google and Facebook, they are both in monopoly investigations, and the
              > FCC submits a covert order to to apply their ToS policies on planning
              > crimes to organizations planning marches.
              >
              >
              > On Mon, Aug 3, 2009 at 4:02 PM, Zooko
              > O'Whielacronx<zookog@...> wrote:
              >> On Mon, Aug 3, 2009 at 9:55 AM, Lucas Gonze<lucas@...> wrote:
              >>>
              >>>
              >>> What's the difference between a cloud storage system and a
              >>> decentralized
              >>> p2p storage system, Zooko?
              >>
              >> Let's say that it is "cloud" if you are outsourcing the
              >> administration, i.e. if the infrastructure, servers, operating
              >> systems, networking etc. is being administered by pros and you are
              >> paying them for the service. Let's say it is "p2p" if you are
              >> benefiting from resources owned and administered by other users like
              >> you.
              >>
              >> Tahoe-LAFS is currently in use in "cloudy mode", where a bunch of
              >> end-user are paying allmydata.com to backup their files, and all of
              >> the computer resources are owned and operated by allmydata.com. It
              >> is
              >> also currently in use in p2p "friendnet" mode where a small group of
              >> friends provide each other with free storage service from their own
              >> machines. (Don't call it a darknet.)
              >>
              >> Because of its unique "least-authority" properties, Tahoe-LAFS would
              >> also lend itself to a "p2p cloud" topology -- let's call it
              >> "multi-provider cloud" -- where you are paying multiple independent
              >> service providers to give you service, so that if any subset of them
              >> fails you can keep on chugging. E.g. you can imagine paying for some
              >> storage space with Amazon and Rackspace and Nirvanix, and then using
              >> Tahoe-LAFS on top of that to ensure that if any one out of the three
              >> is currently functioning then you still have access to your
              >> filesystem.
              >>
              >> The reason why Tahoe-LAFS might be useful in that situation is that
              >> the security guarantees mean that the three service providers that
              >> you
              >> have hired have almost no power at all to interfere with each other's
              >> operation. This minimizes the opportunity for finger-pointing and
              >> confusion among them.
              >>
              >> Regards,
              >>
              >> Zooko
              >>
              >>
              >> ------------------------------------
              >>
              >> Yahoo! Groups Links
              >>
              >>
              >>
              >>
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >
            • Zooko O'Whielacronx
              ... Good points, Alen. We distinguish confidentiality , integrity , and reliability . In Tahoe-LAFS, the owners and operators of the storage servers have
              Message 6 of 11 , Aug 4, 2009
              • 0 Attachment
                On Mon, Aug 3, 2009 at 6:28 PM, Alen Peacock<alenlpeacock@...> wrote:
                >
                >
                > I think the point of decentralization over cloud services in this
                > setting is reliability in lieu of security. Security should be (and is
                > in tahoe) provided at the endpoints, and so as long as private keys
                > remain private, even collusion among servers will reveal no secrets.
                >
                > However, I think you are right that collusion could allow for
                > censorship.

                Good points, Alen.

                We distinguish "confidentiality", "integrity", and "reliability". In
                Tahoe-LAFS, the owners and operators of the storage servers have no
                ability to violate your confidentiality (read the contents of your
                files without permission) and almost [*] no ability to violate
                integrity (change the contents of your files). They do, collectively,
                have the ability to violate your reliability by going out of business,
                getting disconnected from the Internet, deleting all your data, etc.,
                which is why we add the erasure-coding so that you have a chance to
                get your reliability from an alternate server when some subset of the
                servers are failing.

                Regards,

                Zooko

                [*] subtle details of integrity versus roll-back attack available upon request
              • Lucas Gonze
                Zooko, can operators of storage servers identify whose bundles belong to who?
                Message 7 of 11 , Jun 24, 2010
                • 0 Attachment
                  Zooko, can operators of storage servers identify whose bundles belong to who?

                  On Tue, Aug 4, 2009 at 7:06 AM, Zooko O'Whielacronx <zookog@...> wrote:
                  > We distinguish "confidentiality", "integrity", and "reliability". In
                  > Tahoe-LAFS, the owners and operators of the storage servers have no
                  > ability to violate your confidentiality (read the contents of your
                  > files without permission) and almost [*] no ability to violate
                  > integrity (change the contents of your files). They do, collectively,
                  > have the ability to violate your reliability by going out of business,
                  > getting disconnected from the Internet, deleting all your data, etc.,
                  > which is why we add the erasure-coding so that you have a chance to
                  > get your reliability from an alternate server when some subset of the
                  > servers are failing.
                • Zooko O'Whielacronx
                  ... Yes—storage clients upload shares of ciphertext directly to storage servers and download them directly from storage servers over SSL. Some folks
                  Message 8 of 11 , Jun 24, 2010
                  • 0 Attachment
                    On Thu, Jun 24, 2010 at 10:20 AM, Lucas Gonze <lucas@...> wrote:
                     

                    Zooko, can operators of storage servers identify whose bundles belong to who?

                    Yes—storage clients upload shares of ciphertext directly to storage servers and download them directly from storage servers over SSL.

                    Some folks affiliated with the "i2p" project got Tahoe-LAFS running over i2p and contributed some patches. Also some folks have contributed patches so that you can run Tahoe-LAFS over Tor. With either of those then, if I understand correctly, storage server operators wouldn't be able to learn the IP address of the storage client.

                    Regards,

                    Zooko
                  • Lucas Gonze
                    ... How does a client authenticate? Is it a key in the user agent?
                    Message 9 of 11 , Jun 24, 2010
                    • 0 Attachment
                      > On Thu, Jun 24, 2010 at 10:20 AM, Lucas Gonze <lucas@...> wrote:
                      >> Zooko, can operators of storage servers identify whose bundles belong to who?

                      On Thu, Jun 24, 2010 at 5:55 PM, Zooko O'Whielacronx <zooko@...> wrote:
                      > Yes—storage clients upload shares of ciphertext directly to storage servers and download them directly from storage servers over SSL.
                      > Some folks affiliated with the "i2p" project got Tahoe-LAFS running over i2p and contributed some patches. Also some folks have contributed patches so that you can run Tahoe-LAFS over Tor. With either of those then, if I understand correctly, storage server operators wouldn't be able to learn the IP address of the storage client.

                      How does a client authenticate? Is it a key in the user agent?
                    • Zooko O'Whielacronx
                      ... There isn t a notion of client authentication. But there is a notion of *authorization*. You are authorized to access a file or directory by me giving you
                      Message 10 of 11 , Jun 28, 2010
                      • 0 Attachment
                        On Thu, Jun 24, 2010 at 7:16 PM, Lucas Gonze <lucas@...> wrote:
                        >
                        > How does a client authenticate?  Is it a key in the user agent?

                        There isn't a notion of client authentication. But there is a notion
                        of *authorization*. You are authorized to access a file or directory
                        by me giving you a capability to that file. Here is a URL which
                        contains embedded within it the capability authorizing you to read a
                        directory:

                        http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/papers/diet_research

                        You can see from going to http://tahoe-lafs.org and clicking on "Try
                        Tahoe-LAFS now! live on the web." that anyone who looks at our wiki is
                        authorized to read and write to a certain directory in Tahoe-LAFS.

                        Regards,

                        Zooko
                      Your message has been successfully submitted and would be delivered to recipients shortly.