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

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

Expand Messages
  • 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 1 of 11 , Aug 3, 2009
      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 2 of 11 , Aug 4, 2009
        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 3 of 11 , Jun 24, 2010
          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 4 of 11 , Jun 24, 2010
            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 5 of 11 , Jun 24, 2010
              > 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 6 of 11 , Jun 28, 2010
                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.