The Path from S4 to PrivateStorage

Post Author
Post Author
Post Author
Post Author

In March 2019, Least Authority announced PrivateStorage, our new joint venture with Private Internet Access, a privacy-focused VPN provider, to launch a new secure cloud storage product based on Tahoe-LAFS. Since then, we have been asked questions about how PrivateStorage relates to our currently offered Simple Secure Storage Service (S4), including what will make PrivateStorage different enough to warrant an entirely new service. To address those questions, first we need to provide some background.

History of S4

We originally launched S4 in 2013, after the Edward Snowden leaks and in the wake of the PRISM scandal, but Tahoe-LAFS — the underlying open source project — pre-dates these events. Our goal was to offer a convenient cloud storage service that didn’t require trusting the service provider. We believe in building a service where you don’t need to depend on the service provider to preserve the confidentiality and integrity of personal data, one that incorporates an ethos that we operate by: to make our systems secure by design, not by policy, and to abide by the Principle of Least Authority.

Since launching S4, we’ve improved the service by: implementing Magic Folders to power better syncing of data; added Gridsync, the graphical user interface, to make S4 more user-friendly; implemented Servers of Happiness to improve the erasure coding algorithm, and performed a few rounds of user testing, including at the Internet Freedom Festival and RightsCon in 2018.

Beyond S4

Through customer feedback, watching the industry develop, and doing internal analysis on how to continue to develop a better S4 product, we realized that our current S4 infrastructure and architecture was not going to support the kind of growth we wanted and needed. Additionally, we had discussions with Private Internet Access about how we could partner to offer an even better customer experience and reach a broader market.

With S4, we control access to our storage servers by setting up one, single-server grid for each subscription paid for with the Stripe payment service. This approach has served us well, as it allows us to shut off service to a single customer by shutting down their grid. In Tahoe-LAFS, however, sharing is only possible within one grid (although designs to facilitate inter-grid sharing through a federation of grids have been discussed), so this limits our ability to facilitate people sharing beyond their own additional devices.

Over the years, we at Least Authority, along with the Tahoe-LAFS community, discussed various ways to implement a more robust access control method that would allow us to operate just one grid for all of our S4 customers to use collectively. However, these past accounting designs presented challenges for controlling access, including problems pertaining to whether a customer has paid or not, while still preserving privacy. Traditional accounting or subscription systems typically correlate activities and behaviors to real users (e.g., to monitor and measure resource usage for the purposes of billing). This common practice conflicts both with our commitment to preserving user privacy and with the object-capability model, which differentiates Tahoe-LAFS from other secure storage systems.

ZKAPs -> PrivateStorage

In order to better address the access-control issue in our development of the PrivateStorage service, we are implementing Zero Knowledge Access Passes (ZKAPs). For ZKAPs, we have designed a variation of Privacy Pass, a zero knowledge cryptographic protocol, to facilitate access-control to our Tahoe-LAFS storage servers. For our PrivateStorage implementation, we are using the Privacy Pass zero-knowledge proofs — along with proof-of-payment, instead of proof-of-humanness — as with the original implementation. By integrating blinded tokens with the existing sharding and lease system in Tahoe-LAFS, we have created a Zero Knowledge Access Pass (ZKAP) to require a proof of payment for the storage servers to allow ciphertext shards to be stored.

In PrivateStorage, the use of ZKAPs allows us to provide a more private solution, while requiring payment to store data with PrivateStorage. By decoupling users’ on-activity from any underlying “account” or any specific payment methods, ZKAPs provide a level of anonymity for users, while still providing us, as grid operators, a form of access-control.

Tahoe-LAFS has a decade’s worth of community contributions, and the idea for ZKAPs has been a community effort, too. The ZKAPs approach in Tahoe-LAFS could be easily adapted to require something other than proof-of-payment — like friendship, donation, or whatever other gatekeeping method a grid would like to employ. We look forward to others in the community exploring the potential of ZKAPs in Tahoe-LAFS, or even other open source projects, by using the Tahoe-LAFS plugin system and our open source released code.

These efforts support our mission to bring technology that empowers everyone’s right to privacy through our commitment to Privacy by Design in software and product development, along with our commitment to open source code and running an ethical and transparent business.

Are you interested in the PrivateStorage public launch? Sign up to be notified when PrivateStorage launches later this year.

If you are a current S4 customer, there is nothing you need to do right now. Shortly after the public launch of PrivateStorage, we will help you switch to PrivateStorage as we discontinue our S4 service. Before that, we’ll be providing further information about the transition. In the meantime, we’ll operate S4 as usual and do not plan to shut it down until PrivateStorage is publicly launched, and thereby a suitable option for all of our customers.


Update July 2021:

You can read the Whitepaper here and watch our talks on ZKAPs here. If you would like to talk to us about using ZKAPs as a standalone service, email us at