Part 1: Building for privacy in web3
May 19, 2022
We believe building in the open is core to building better data infrastructure. Accordingly, we are proud to present the Privy mindmap — this first part runs through how we are thinking about tradeoffs made in building Privy and the system today. For more on where we go from here, check out part 2.
We are in a moloch trap when it comes to data ownership online: no one likes the system as it is, but there is no incentive for any single powerful actor to try and break out of it. The foundations of our data stack on the Web are fundamentally broken and enable systemic abuse of user privacy. New regulation seeking to improve data privacy online is leading to new forms of regulatory capture. It is de facto impossible for users to opt out of a datavore system.
The situation is no better for developers. There has never been a worst time to take on user data as a developer. It shouldn’t be so hard for developers to build great products whilst respecting their users’ privacy. This is why Privy exists.
Web3 presents a unique opportunity to break out of this coordination problem and present new paradigms for user privacy and identity on the web.
Blockchains give us the opportunity to build a new stack built atop open standards and protocols, free of structural debt and incentivizing coordination across actors who benefit from a common identity layer.
While blockchains’ transparency makes them bad for privacy, they are easily auditable and promote interoperability by default.
Every user in web3 comes with their own PK-pair (their wallet) enabling us to ground data ownership with the end-user.
Now, this is not to say that private, user-owned systems are inevitable in web3. There is a very real risk that web3 will go the way of web2 in spite of the structural opportunity at play.
Lack of good tooling has put developers in a bind when it comes to managing user data. As a developer in web3 today, you have two choices: eschew user data and build poorer UX or go back to the systems that have failed us the last 30 years over and dump user data in Postgres. We have a small window of time to reinvent the data stack before developers go back to what the system we know, and which has failed us on the Web.
The hard truth is there are no silver bullets in privacy, and privacy without usability is no privacy at all. There are tradeoffs in every decision you make — think of those GDPR consent banners that have forced users to take on a second-class experience in exchange for their privacy.
Welcome to France — would you like a second rate experience?
Developers today are faced with a tradeoff when it comes to user data: convenience vs privacy. This tradeoff will improve as new primitives are unlocked (like productizable homomorphic encryption, or generalizable, efficient zero-knowledge proofs). Recognizing that privacy choices exist on a spectrum, we are building Privy to help you thread the needle of building delightful products and protecting your users. We do this with developer productivity in mind: Privy allows you to get started fast, so you can ship safer products faster.
We recognize the tension between convenience and decentralization given the current state of infrastructure. Our job is to stake out nuanced positions and build opinionated software so developers have a way forward. This is why Privy runs infrastructure for its users today. We believe we can continually improve upon the status quo, until defaults have been upended. As with all nuanced issues, it is a question of tradeoffs.
With that, let’s get into the weeds of Privy: the product today, and where we go from here.
Data sovereignty breaks down when interoperability is enforced at the cost of privacy. We believe your users should not have to choose between data silos and control over who sees their most personal information. We aim to empower them by striking a pragmatic balance that enables you to build great products without putting users at risk.
Why start with any standard short of full data sovereignty?
The last 30 years have shown that, as users, we choose convenience over privacy online — in order for a self-sovereign identity system to be widely adopted by end users, it must be adopted by developers first. This is why our first order of business at Privy is to make it easy for developers to take on user data safely in web3 so they can protect and empower their users.
Our goal is to build simple, usable software with clean abstractions to unblock and delight devs. We do this by building tooling that just works™, the protocol comes later.
And so today, Privy’s trust model today is “trust but verify.” Under this initial model, the developer/org retains control over user data but uses Privy to handle that data securely and transparently. As a developer, you never have to have access to user data if you don’t want to, and Privy makes it easy for your users to verify how their data is used. Infrastructure is Privy-run for convenience and security.
Today, we provide top-of-class privacy solutions, based on well-worn cryptography. At a high-level, Privy takes care of key management and encryption, permissions and storage for you.
As a developer, you integrate Privy into your front-end in order to take on user data and have it bypass your backend (in fact you no longer need a backend to take on user data).
The base interaction is simple:
User enters information into their browser
That data is encrypted in the browser directly
The ciphertext is sent to Privy
At a later time, if you or the user needs data, you can call it back from Privy where it’ll be decrypted client-side. All of this is done through two simple calls:
// encrypt and store privy.put() // retrieve and decrypt privy.get()
Privy generates new keys for every piece of user data and runs Hardware Security Modules (HSMs) to protect those keys. Data is stored in the cloud and permissions are set by the developer and upheld by Privy’s API.
A view of the Privy console where you can set permissions for data.
All data is encrypted end-to-end and Privy never sees it. We rely on cryptography and infrastructure best practices to help developers better protect their users. Our infrastructure and encryption solutions are all accessed via open-source libraries.
Now as we pointed out, this is just the beginning. Privy is working across two main axes: more user control and less platform trust.
control is about who makes decisions as pertains to user data (e.g. the developer or the user),
trust is about how these decisions are enforced — i.e. what agency does the underlying platform have in enforcing the controller’s decisions, more concretely “can the infrastructure be subpoenaed or co-opted?”
Rather than having to replicate their data with every website they go to, users should have full control in deciding what data to give to what services and when to revoke it. This is where we are going, with Privy helping users control such personal data vaults.
Mockups of the Privy control center, from which you control your data flows as a user
Check out part 2 for more on where we go from here.