Henri Stern on Privy and building for security/privacy

Show notes

Henri Stern is building Privy. Henri was previously a research scientist at Protocol Labs and worked on Filecoin’s consensus protocol. After many years of thinking through problems related to data privacy and security, he recently co-founded Privy where they provide a suite of API tools to store and manage user data off chain.

In this conversation, we talked through a set of topics that Henri has a unique point of view on - starting with the question around the seeming trade-off between privacy/security on the one hand and UX/convenience on the other. We talked about principles he has in mind in designing an off-chain data system; how Privy does encryption and key management; how they do permissioning; and how they think about data storage.

Timestamps:

• (00:02:30) designing the product/protocol roadmap
• (00:10:30) privacy/security vs. convenience
• (00:19:27) building a web3 application
• (00:23:20) decentralizing Privy
• (00:32:09) key management architecture
• (00:46:11) verifiability, transparency as a disinfectant
• (00:59:02) building a product with private data
• (01:07:08) cofounder relationship

Transcript

Henri: One of our differentiators as a company and as a product in the space has to be around ease of use. Too much protocol-first tooling in this space is so hard to use. I think unless tools come out that make it easier for developers to handle user data privately in the next year and a half, the default will be to just dump this into Postgres. So, we’ve taken the approach of starting off way SaaS-ier than a lot of folks in Web3 to build for an easy experience.

Obviously, that also means it can be really easy to lose sight of where the company is headed, which is why building a product roadmap felt really important. We need to remember that the end goal is self-sovereign identity in a very real way. Users should control their data, even if we start with developer control in mind.

Sina: If we’re talking about the Web3 ecosystem, a lot of people take this point of view of designing a protocol first and starting from the most idealistic version of the future that we’re trying to see. This kind of inadvertently creates a multi-year roadmap of building these technical puzzle pieces that all have to come together to result in a good user experience. One thing I appreciate is that you, very intentionally with Privy, made the decision to start from where the world is today—what the user experience is that you’re trying to create, what developers can actually integrate into their applications—and then have a longer-term roadmap about how you can back into more of an open protocol.

Henri: Yeah, I think there are three main reasons for it, at least. I’ll try to outline them here. The first is a question of personal preference and how I like to build. The second is about emergent behavior in the space and what happens if you try to build something too far out in the future. And the third is the urgency around this because of what happens if we don’t build this quickly, given the time it takes to build protocols.

Going a bit deeper into each, the first is personal preference. Ultimately, one of my frustrations with protocol building is that the decisions you’re making— and to be fair, I was working on the consensus protocol for a layer-one blockchain, so this is kind of the bottom brick of a lot of this stuff—have a product effect on a multi-year timescale. For example, decisions regarding block time or the number of blocks that could be emitted in any given round had long-term impacts. I really missed being closer to users. What does it mean to build with a user in mind in Web3? It seems like there’s a pretty wide divide between consumer products in Web3 and developer tooling or infrastructure. I wanted to get closer to a place where we could talk to developers we were building for and get feedback on a daily, weekly, or monthly basis. So, that was the first reason why we’ve opted to build a much SaaS-ier product than a protocol.

The second reason is about emergent behavior. The market is changing so quickly. We can set a flag for where we hope to be in 10 years—what self-sovereign data should look like, what it should mean to be a user surfing Web3 when it comes to your personal data, and the experience around giving people or protocols permissions and access to your personal data. Yet, there’s a bit of futility in trying to build the 10-year vision because the market changes out from under you. I didn’t want us to be building a religious vision, like follow our path to the holy land and we will guide you. Instead, it had to be a tool that could be useful to developers in this space yesterday. So many of my friends were saying, “I built this prototype, it’s still a dApp, and I really like it, but I’m never going to ship it because to make it any good, I’d have to take on user data, which I don’t want to do.” I felt there was tension between the 10-year journey where we make a promise of suspending disbelief and building with us for a decade, versus addressing a real need for developers today. Even if that means being a little less perfect in what we ship up front, we can ship something useful tomorrow in a way a protocol might take longer.

The third reason is urgency. Web3 is at a nice edge where you’ve got two schools of thought. You’ve got the Web3 OGs who say everything happens between the client, the frontend, and the chain—there is no backend to a Web3 product, no cloud or state being kept anywhere but on-chain. Then you’ve got new entrants in the space who are used to Web2 experiences, coming from Web2, saying, “I can’t build a good product at all, so I’m going to go back to what I know and drop user data into a database or a warehouse.” I really worry that users have shown they will choose convenience and delight over privacy because privacy is such a nebulous promise. Unless we can help level the playing field today and make it easier for developers who want to protect their users to do so, I fear the space will take a left turn in the coming year and a half. Developers might start dumping user data into databases to build user experiences, and we end up with the same data silos we had in Web2. Web3 would just become a business model—you have a chain to make money, but otherwise, your infrastructure is exactly the same as before.

Sina: Yeah, it’s a very astute observation that this is happening. The dichotomy is really there between developers who’ve bought into the ideals of Web3—having self-sovereign data, pushing power to the edges, all these sorts of things—and they elect to build products that basically forsake user data at the expense of user experience.

Sina: I’ve been reading some of the stuff you’ve written, and you have a lot of great examples. For instance, if you don’t get a notification to your email when you’re about to get liquidated, or there’s just a lack of email communication from these sites about what’s happening with your on-chain behavior, it’s a direct fallout of developers not wanting to even hold a user’s email address. On one hand, people stick to their beliefs at the expense of a good product experience. On the other hand, there’s this convenience factor where users don’t actually care about privacy. Some argue that the blockchain is just a global settlement layer for value, and everything else can still use a Web 2 stack, which is a very narrow definition of the overarching vision we’ve all been thinking about.

By the way, the notifications example is a really good lens through which to look at this space. It’s obviously a clear UX problem we have, and there are others too. For instance, your wallet isn’t your identity. When you try to log into a product with a given wallet and then switch wallets—I have five or six wallets with which I’ve collected NFTs—there’s no unified user experience across all of them. So, a number of issues fall out from the fact that we don’t have private state or off-chain state in a Web 3 native way.

But notifications are a particularly good example because you’ve got all these schools of thought playing out in the many startups tackling this problem. You’ve got projects like XMTP and EPNS doing, as I understand, on-chain native notifications. Then there are folks like Notify Network or others building messengers on top of wallets and public key cryptography rails, rather than on-chain in a precise way. I’m curious how you see this landscape and where Privy fits in.

Henri: Yeah, that’s a great point. For us at Privy, the interesting thing is trying to pick the right beachheads where we can prove out the value of having a Web 3 native, off-chain data storage solution—private data storage for your users. Where can we demonstrate that value? Whether notifications as an issue will ultimately be solved through a product like Privy or through any of the companies dealing specifically with that is a question I don’t have the answer to. All I know is that there are a number of ways in which developers are hemmed in because they don’t have off-chain storage they can reliably touch in a non-siloed way.

Sina: That makes sense. One of the things you’ve written about, which I wanted to dive into, is this question you posed: Is the decision between security and privacy on one hand, and convenience and user experience on the other, a real invariant of how internet services are built? Is this just how it’s always going to be, or is it a path-dependent thing that has emerged, and we’ve gotten stuck in this local piece of the landscape that kind of sucks? How do you think about this in the context of the next couple of years with Web 3’s evolution? Why is this the time to build Privy, for example? Why couldn’t you do what you’re doing a few years ago? Is there something special about what’s happening right now, or is it just a shift in the Overton window with crypto?

Henri: Let me start with the first part of your question about path dependency versus invariant. As I understand it, you’re asking if there’s some inherent tension between good UX, convenience, and ease of use on one side, and privacy-respecting technologies that empower users on the other. To me, this question feels most urgent today in the context of custodial versus non-custodial systems in Web 3.

To define it, the core question is: who owns the keys at the end? If I have assets in a Coinbase account, Coinbase is the custodian—it’s a custodial solution. If Coinbase decides to cut off access to my assets, as they have with various Russian nationals on sanction lists, I can’t get my assets back. The core ethos of crypto early on was that I’m dependent on no centralized third party to own the things I own, including my data, even though that wasn’t in the original white paper.

On the flip side, key management and wallet management as infrastructure today pretty much suck. There’s a real tension between democratizing access to Web 3 and enabling non-custodial experiences where users control their assets. Convenience often means adding a middleman, and adding a middleman means being disempowered. So, I think there is a fundamental tension where you have to choose between doing things in a more manual way, at the cost of UX, or doing things more easily, at the cost of control.

The design space of different mechanisms helps navigate these trade-offs. For example, social recovery wallets might be a design that finds a middle ground. The user holds their own keys, but you’re not putting all the onus on them—if they lose their keys, they’re not totally screwed. There’s a baked-in mechanism for recovery. I think Argent, for instance, has done a really good job of finding a middle ground here. They offer a very Web 2-native way for me to say, “Here’s my mother’s phone number or my brother’s email,” to do key sharding and have a non-custodial experience. By default, Argent steps up as the guardian if you nominate no one else, but if you don’t want them in control, you can substitute someone else.

Now, on the more exciting part about path dependency—I think the internet, circa Web 2, took a hard left toward convenience. It was all about hiding complexity from users and handling everything for them. I think there’s a special time in crypto for two reasons. One, because of the original ethos of the space. Two, because of what’s happening on the regulatory side. To a large extent, regulation is crypto’s friend—or at least, it’s a friend to crypto-native ideals. You’re seeing businesses refuse to do things that would be easier for consumers because they don’t want to be on the hook for it. So, there’s a push toward non-custodial solutions, not for UX purposes, but for regulatory reasons.

That’s where I think crypto is really the nexus for much better privacy-preserving technologies. For the first time in the history of the web, there’s an alignment of incentives between developers who don’t want to touch user data and users who want to own their data. Does it fully solve the tension? No, I think the tension will always remain. There won’t be any silver bullets in data privacy—that tension will always exist. But it opens up the solution space in a way we haven’t had in Web 2. On top of that, you’ve got tools like zero-knowledge proofs and other primitives that are giving developers better ways to create solutions that are both more private and more user-friendly.

Henri: So, to the question of why Privy now, I think that’s kind of the answer. We’re having twin moments where, as crypto enters the mainstream, it’s also getting heavily regulated. For the first time, there’s developer demand for more privacy-preserving technologies, maybe in the name of privacy, but mostly in the name of liability control. That’s a really exciting place to be as someone working in privacy-preserving infrastructure and data infrastructure more generally.

Sina: I want to plug this now—you have a series of blog posts from 2021 that I thought were super well-written. You discussed the landscape of privacy, how it’s evolved over time, and how regulation is impacting things today. You made a point that I found really interesting: in the absence of proper infrastructure that developers can easily plug into, this often leads to a weird mess of people complying with regulations without actually doing anything meaningful. You had a screenshot of an NPR GDPR notice—a massive blob of legalese text with a “Yes, I agree” button, and the “No” option was just “Show me the website in plain text.” I was just in Europe for the Devconnect conference, and this problem is very much alive. I probably agreed to ten different GDPR notices without really thinking about it. These privacy regulations aren’t actually achieving much.

Henri: Yeah, this is what I mean when I say there’s no silver bullet for privacy. I’ll make two points here. First, I think Web3 is kind of the only place right now where you can build privacy tooling that is developer tooling and not just compliance tooling. If we were building Privy in Web2, we’d be selling to general counsels or CSOs, not to devs. This is a unique opportunity in Web3, also enabled by the fact that every user has their own cryptographic materials—they’re custodians of their assets with wallets. This unlocks new product experiences we can’t have elsewhere.

I think better privacy experiences online don’t just offer the same user experience but in a more respectful way. They open up entirely new UX that we can’t even imagine today. That’s something I’m excited to see coming from Web3 that I don’t think could come from Web2.

On the other path, I keep going back to the fact that the Cambridge Analytica data breach wasn’t a hack. It was Facebook misconfiguring systems—it was bad systems design and users agreeing to exactly what happened, which is any third party I share data with can share my data with other third parties. The onus will always be on developers and app builders to make these decisions. We need tooling that makes it easier to do so.

By not building a protocol but instead building Privy as developer tooling—hosted infrastructure while giving developers and end users the chance to host their own infrastructure if they don’t want to trust us—I think that’s really important. Giving people optionality, but also providing an option where we host infrastructure, means we’re getting our hands dirty and helping set good defaults for developers. The question of how to ask users for consent is a hard one. The anti-pattern we’re seeing because of GDPR, with those consent banners at the bottom of webpages that push you into either opting in or getting a subpar experience, isn’t much of a choice. That’s the risk if we don’t design good tooling around this.

Sina: Yeah, it’s so bad. It makes no sense. Maybe just describe what Privy is so people can place it on the landscape as we continue this conversation.

Henri: Privy is a simple API to manage user data off-chain. Ultimately, Privy takes care of three things for you: key management and encryption, permissions, and storage. You have two main calls—Privy.put and Privy.get. Add those to your frontend, and you can basically say, “Privy.put,” pass in a key like a user wallet address, and a value, say a user’s email, to associate an email to a wallet address. You can associate any data—structured or unstructured, videos, images, and so on—to user wallets in a privacy-preserving model.

What that means is when you call Privy.put, Privy encrypts all of that data client-side in your user’s browser, stores the ciphertext—we have no access to the underlying user data—and then, as you or your user needs it, serves that data back. This lets you build better UX. You can have user profiles that take both on-chain and off-chain data to create an experience around that. We’ve talked about use cases like notifications, but at its core, Privy is a way to add a few lines of code to your frontend so you can integrate sensitive data into your product without taking it onto your stack or having to build a backend.

Sina: Got it. So, let’s say I’m a Web3 developer at a fork in the road. Do I completely forsake user data and not have notifications built into my site, for example? Or do I go full Web2 and have a client-server setup with a database that I keep? Now there’s this third path open where I integrate the Privy API. It gives me two methods, which is super easy. You can store data, and all the complexity—the encryption, the permissioning—is abstracted away through this API. You push user data into this external service, which is Privy, and at any point in the future, through some key management handshake stuff, you can get that data back for a particular user. Is that the premise of how this works?

Henri: Exactly. Today, the focus is really on helping developers protect their users and themselves. Let’s make it so that if your stack gets hacked, you’re not leaking user data left and right, which would just harm everybody. Let’s help you do better for your users. The goal thereafter is to move from a viewpoint of developer control—where the developer sets both the schema, meaning here’s the data I need, and the permissions, meaning here’s who gets to use it within my company, across my user base, and across other apps—to a place where the developer still sets the schema, but Privy is under user control.

The end vision is to move to a place where, just like when you turn on Uber on your iPhone and get a modal that says, “Uber would like to access your location. Do you want to give access? Yes or no?” you’d log into Uniswap, and it might say, “Uniswap needs access to your email so they can tell you if a transaction gets dropped from the mempool. Would you enable access? Yes or no?” Then, as a user, you have a control center where you can see what apps have access to what data of yours, and you can revoke that access. So, what you’ve described is exactly where we are, which is still a developer-centric world because we think that’s the starting point.

Henri: Making this easier for developers is the first step, but moving towards a more B2B2C aspect—helping developers communicate around data permissions with their users—is key. Today, if you get Privy API keys, the system works by having the developer set the permissions on behalf of the user. The path from Privy today to Privy tomorrow is split across three axes, at least in how we’re thinking about the product right now.

The first axis is turning things into a user-controlled data store, where the user is the one making permissions decisions. This is ultimately a UX question. Apple, for instance, does a great job with notifications, modals, and other interfaces that make this intuitive. There’s a lot of work on the UX and product design front to make this easy, but also to help users make informed decisions—unlike, say, how Facebook handled it in the past. So, that’s the first path: a more user-controlled Privy.

The second axis is a more decentralized Privy. In the vision you described, Privy holds the permissions list. Ultimately, though, we shouldn’t have to be trusted. If you don’t trust us, you should still be able to use the system by nominating another delegate or even a network to hold that permissions list on your behalf. We’re looking to decentralize our infrastructure. Right now, Privy runs HSMs—hardware security modules—that handle key management for users. But we want to move to a place where we plug into the user’s own wallets, so users encrypt their data with the same keys that safeguard their assets.

Of course, this raises questions: when a user isn’t online, how does someone access that data? How do you decrypt it? This is where you’d need some version of a data delegate to step in. Ultimately, you should be able to say, “I don’t trust Privy at all, but I do trust Sina, so I’ll give him access to handle my data delegation.” Further down the line, we envision full networks using threshold encryption, like what Keep Network or Lit Protocol are doing, to have actual networks act as data guardians or watchtowers. This way, you’re not trusting a single party. So, we’re moving from “trust Privy” to “you choose who you trust” to “you don’t need to trust any single party” to make this work. That’s the vision for a more decentralized Privy.

The third axis is a more integrated Privy. How do we unlock privacy-preserving usage of that data within product tooling? This includes things like homomorphic encryption or zero-knowledge proofs once the tech matures or the right use cases emerge. It also involves building proxy servers where, for example, you can send an email directly from Privy by having a separate server spin up, decrypt the email, send it, and then squash all that data. Essentially, we’re running computation on Privy nodes. To start, we’re hosting those, but the idea is to quickly move away from that. We’d rather not host them at all. Instead, let’s have a marketplace of Privy nodes that run certain computations. You could pick from, say, Henry’s or Asta’s email provider—Henry’s integrated with Mailchimp and charges this way, Asta’s integrated with SendGrid and charges that way. You’ve got these data engines running for you as a user. That’s where we’re thinking about this. It’s a huge idea, and it’s really exciting to think about this future.

Sina: So, to make sure I understand, Privy today is this narrow, simple tool—a wedge that’s going to open up into a whole world in the future. Right now, it’s basically an API you call to push data to a centralized data store backed by a key management system that you’re running. It stores only encrypted data and pushes all the decryption stuff to the client and the developer. The developer is your primary user at this point, defining what sort of data needs to be stored and the permissions they want from the user. The user doesn’t actually get a view into this or a say in it, right?

I’d like to retrace what you said because these are deep rabbit holes. The first thing was about permissioning—bringing a view similar to iOS, where a new app prompts you, or like when you authenticate with Gmail, it tells you what the app needs. You want to create a version of this where every developer integrating with Privy, or every application, gives a prompt to the user that clearly explains what they’re trying to do with the data. Then the user can make an educated decision about whether they want to proceed with that. Is that correct?

Henri: Yeah, that’s absolutely correct. And that itself is a very hard problem to crack. You have to think about the internals of these different applications and what they’re doing with the data, then build interfaces that create just the right amount of friction. If we build no friction into it and allow this data to just flow, we’re back in Web 2. If we build too much friction, nobody uses the tooling, and we’re back to Web 2 as well. So, it’s about helping developers keep their users informed and helping users make good decisions, all without destroying the user experience.

Sina: Yeah, but at least there’s an analog for this in the existing world—models to learn from. Then, the second thread, which is very interesting, is decentralizing Privy, the actual architecture. So, how does it work today behind the scenes?

Henri: Maybe what’s helpful is I can give you a single sentence that summarizes all three of these epics. The first topic about user control is: who controls permissions? The second is…

Henri: Privy is currently a custodial solution, though from an infrastructure security standpoint, we are non-custodial. What I mean by that is it’s nearly impossible for anyone on our team to access user data without taking over the entire stack and changing a lot of configurations. Essentially, the whole company would have to go rogue for something to go wrong. However, the unfortunate truth is that Privy can be subpoenaed to hand over user data due to how things are architected today. We want to change that and move toward truly non-custodial solutions. For what it’s worth, I think there’s a lot of “custody theater” in Web3, where so-called non-custodial solutions, when you really look at them, turn out to be custodial after all. We’re seeing more of that, and that’s where we stand today.

Sina: So, how does Privy work today? Like, how is it architected under the hood? Where are the keys held, and where is the data stored?

Henri: Today, the data itself is stored with a cloud provider, specifically AWS. That’s a deliberate choice, but when it comes to the order of decentralizing Privy, the first step is authentication. We don’t want to depend on service providers to authenticate users. Instead of trusting a third party to confirm, say, that this is Henri logging in, we want users to log in on their own using technologies like anonymous Ethereum and others. This ultimately unlocks access to a global data store that belongs to you and follows you around Web3. This “data backpack” exists because you don’t have to rely on a third party to authenticate yourself.

The second step is creating a portable data store for users across different applications, where they can log in without needing a third party to validate their identity. Then comes key control, where users encrypt their own data and manage who has access to it through encryption and decryption.

Right now, when a new customer signs up with Privy, we spin up a new HSM—hardware security module—dedicated to key management. For each user, we have a root key. When a customer, by which I mean a developer, calls Privy.put, our open-source client libraries generate symmetric keys client-side in the browser. These keys encrypt the user data, and then a call is made to the Privy KMS—these HSMs—saying, “This is the user for whom I want to encrypt data. Send me a new wrapper key derived from that root key.” This wrapper key encrypts the symmetric key under which the data was encrypted.

To break it down, the data is encrypted under a client-side generated key—this is standard envelope encryption. Then, that key is itself encrypted using another key that sits in our HSM. The important point is that every piece of user data is encrypted under a unique key. So, if there’s a breach or malware on a server, it only risks that specific piece of data, not all of a user’s data. A new symmetric key is generated every time a new piece of data comes into Privy, and even the wrapper keys are unique to each piece of data being stored.

The entire Privy system was built modularly. The permission system, key management system, and storage system are all separate modules. Currently, the KMS is managed by Privy’s HSMs, but down the line, we can swap that out for a user’s own wallet. Imagine getting a MetaMask pop-up asking, “Would you like to encrypt this data?” You, as the user, would be the one encrypting it using the APIs that wallets provide. That’s how we decentralize the system over time.

The next step after that is decentralizing permissions. We want the permission system to be signed by the user and run on any node they choose, rather than sitting with us. Eventually, it could even run on-chain, though not today. You wouldn’t want to reveal permissions on-chain—like saying who has access to my Social Security number. Even stating that Alice can read it but Bob can’t is still not ideal. The goal is that you shouldn’t have to trust Privy to run the permission system correctly. You should be able to fork our permissions code and run it yourself or have someone else run it for you. That’s the third piece—logic-gated permissioning rather than purely cryptographic, which I can dive into more if you’d like.

Sina: Okay, so on the key management piece, the current architecture is that you’re spinning up keys on these hardware security modules you manage. These keys are used client-side to encrypt field-specific symmetric keys that encrypt the user’s data, right?

Henri: Exactly, that’s correct.

Sina: And over time, you’re planning to switch out this backend KMS that you manage with individual user wallets. So, a user would use their own hardware wallet or MetaMask to encrypt these keys created for each piece of data?

Henri: That’s right. The idea is that by default, Privy manages this for you. But if you don’t want us to, we absolutely don’t need to. You can manage your own infrastructure and key management system. We integrate easily with wallets so you can do that in a very simple way.

Sina: In the current system, there are many other platforms out there holding sensitive data, like 1Password, which stores all your passwords. There are established architectures for storing sensitive information. I’m curious, with the model you have, how would you analyze the risk vectors of something like this?

Henri: I’ll start with a straightforward answer: it’s already a lot better than just dumping data into PostgreSQL or something you’re securing on your own. I’ll make the claim that while Google and Facebook might not be great at data privacy—and I wouldn’t put them in the same bucket—they are very good at data security. It’s impressive how well they’ve secured data for the most part.

The most Web2 version of the Privy pitch would be this: you’ve got these huge companies with teams of a hundred people dedicated to data security. Let us handle that for you. It makes no sense for you to build this in-house, but you should still offer the same level of service to your users. At the very least, we’re taking this data out of your stack and encrypting it at a cell level.

Henri: So, this is better than if you threw this into your own stack, even if you enable encryption at rest. Here, the data is end-to-end encrypted, which makes a significant difference in terms of security posture. There are three attack vectors worth looking at. The first is malware. What if someone is lying in wait in the user’s own browser? Well, it means the data is leaked, but it would have leaked anyway because the user is typing it in. You probably have some version of keylogging or something similar. However, it has no implication on other data stored in Privy. You’re not revealing anything else about how Privy works beyond what pertains to you as a user and the specific data you’ve been typing in.

The second vector is our own data store. In our data store, we have encryption at rest, but underneath that, we’re getting ciphertext in. The text is basically the data blob encrypted, and the key itself that was used to encrypt the data is also encrypted. If somebody breaks into the data store and siphons off ciphertext, unless they also have access to the Key Management Service (KMS), all they have is encrypted data. One reason I think people shouldn’t put encrypted data on-chain is because ciphers break over time. It’s known that governments like the US or China are storing ciphertext with the understanding that 50 years from now, they might be able to break the encryption and read the underlying data. That’s one reason why decentralizing storage in Privy, so you can run it on your own nodes, makes sense. Nonetheless, today, it’s all ciphertext. If you break into Privy’s data stores, you don’t get access to any underlying data.

The third piece is the KMS. The short answer is, if you can break Hardware Security Modules (HSMs) today—these are run by cloud providers in secure facilities—then all bets are off, and basically all security guarantees go down. We’re not building our own; we’re piggybacking off the learnings of the last 30 years. What we take care of is plastering these bricks together in a way that the wall comes out solid. The first rule of cryptography is never roll out your own crypto. We’re using best-in-class systems to protect this Web3 data. We’re moving through cryptography history as we go. Right now, we’re in the 1970s, using public key cryptography. We’ll move on to proxy re-encryption, and maybe someday we’ll get to zero-knowledge proofs and threshold cryptography. But today, we’re squarely in the 70s and 80s in terms of the crypto we use. Obviously, we’re limited by the quality of the infrastructure of these cloud-run HSMs, which, to be fair, a lot of other services also use. Maybe we’re talking about it more openly, but everybody uses this stuff.

The last piece is the permissions oracle, and I think this is the most interesting one. This is why it comes next in our decentralization journey after the KMS. Ultimately, if you control permissions, regardless of whether the key system is working properly, then you control everything. That’s the trust you get with different pieces of data. So, that’s the really key part of having Privy be user-centric, where the user controls the data stored. This comes down to how the permission system is architected.

Sina: And how is that architected?

Henri: We’re trying to do cell-level permissions. Let me describe the model quickly. A user has fields; the user, in a sense, is a row in a database, and the fields are columns. The user can give requesters—who are people or entities asking for access to the data—read or write access to certain columns in certain rows. For example, I get to say Uniswap has access to my email, Sound.xyz has access to my phone number, and Sushi has access to my home address, or something like that. That’s how we’re setting these permissions. Today, we’re using the existing cryptographic infrastructure to enforce them.

Sina: It’s just so interesting. I like this term you’re using, “cell-based permissions,” which I imagine means any cross-section of a row and a column—right, a person and a piece of data, and who has access to it. So, you’re using your existing cryptographic infrastructure to secure this table, basically, that keeps all of these permissions together?

Henri: Yes, exactly. As a user of Privy yourself, or if you’re a developer, it’s as if you’re storing this table of permissions on Privy. But ultimately, right now, Privy is the one controlling that permissions table. That’s the part we need to change. Today, you are trusting Privy to enforce permissions as you’ve set them. This is where it’ll become really important to ensure that Privy cannot lie about the permissions you’ve set. There are a number of solutions around this in terms of how we evolve the crypto system to do that. At the simplest level, it might just mean the developer signs the permissions they send over to Privy, so Privy can justify the permissions decisions it makes. We can’t spoof and say, “Well, no, Sina did give us access to this,” because we have a signature that shows you didn’t.

Moving back to a product feature level, the first step we’re taking toward what’s often called “trustlessness”—a term I hate, by the way—is building auditing logs so users can verify how their data has been used. I dislike “trustlessness” because it implies there’s such a thing as a trustless system, and there isn’t. It’s a spectrum, a question of what trade-offs you’re making. But in moving toward the less trust-dependent end of the spectrum, the first thing we’re doing is building these auditing logs.

If you zoom all the way back out to the top-level system, what this means is a privacy policy that doesn’t suck. Instead of going to a website and seeing, “Here are ways we might use your data and types of data we might collect about you,” you’re seeing, “Here’s the exact data we have on you, and here’s how it’s been accessed over the last 30 days in a non-spoofable way.” That’s how we’re thinking about walking that line toward less trust dependency. Let’s start by making these systems verifiable, and then let’s hand over control to the people who should have it, as long as we build infrastructure that makes it easy for them to control it, rather than it being the burden that GDPR pushes onto developers.

Sina: Wow, that makes a lot of sense. These auditing logs are such a cool idea. You can go to a place and see every time a third party has accessed a piece of your data because any time they do, there’s this cryptographic handshake happening, and there’s a record of it.

Sina: There’s this idea that transparency is a disinfectant, right? Just seeing what’s happening and making that exchange transparent can have very positive downstream effects. I’m going to pop this up to a more philosophical question, but to me, the DAO hack is such an interesting case. Looking back on it now, a few years after the fact, the truth of it is less about “code is law,” which obviously didn’t end up being true, but more about how transparency in these systems allows us to make better decisions. It acts as a disinfectant and forces us to have conversations that we wouldn’t have in more opaque systems.

That all makes a ton of sense at a high level. I think we’ve talked about key management and encryption, and my very hand-wavy takeaway is that you’ve thought through this. It feels like this is just the starting point, and it’s going to further decentralize over time.

Henri: Yeah, and this is something I hadn’t thought as much about before I got into Privy. There are two orthogonal questions: who should control the system, and how can we ensure that the system is doing what we think it’s doing? Those are often lumped together, but they’re separate. For us, decentralizing Privy—meaning giving you assurances that the system is doing what it says it’s doing—is a different epic from who actually gets to type in settings for the system or make decisions around permissions.

Sina: Got it. So, the third piece of the puzzle, which we haven’t talked about yet, is storage. Let’s dive into that.

Henri: Frankly, I think storage is the least interesting part, and I say that having spent a lot of time thinking about it during my Protocol Labs days. But here’s my hot take: I think there’s a bit too much decentralization zealotry in Web3. Decentralization is awesome, and the ideals behind data sovereignty and ownership are central to what Web3 means to me. However, I have too many conversations where people ask, “But is it on-chain?” and I’m like, that’s not the right question.

To me, the question of who controls the system is deeply important, and decentralization has a role to play there. Decentralizing infrastructure is really important. But when it comes to storage, the threat model we’re addressing is data leakage—will your data end up all over the internet without your consent? It’s not about censorship resistance, which is whether a third party can withhold data from you. To that end, using centralized storage is a very sensible decision for us right now. We’re putting the data in the cloud, it’s encrypted end-to-end, and the real question is who controls the encryption keys.

Down the line, we want to enable you to plug in your own data module. If you don’t want to use our cloud account, you should be able to plug in your own virtual private cloud, use a server in your basement, or use the IPFS network. You should absolutely be able to do all of those things. However, I think the clear and present danger is data leakage more so than censorship resistance.

Maybe the simple point I can make is that a lot of what people want to store with Privy is off-chain data, meaning real-world data. The honest answer is, I know my Social Security Number. Even if Company X refuses to serve me my SSN, I still have it. There’s a path back from that. The real fear, though, is that everybody else also knows my SSN. Obviously, we want to tackle data silos by giving users control over who can access their data. So, I think it makes sense to start with centralized storage.

Sina: So, you’re basically making a judgment that although censorship resistance is important and an ideal we all aspire to, the real threat vector for this kind of data is not censorship resistance but data leakage—having that data plastered all over the internet. And then there’s the point of comparison: what are developers doing today? They’re just putting it on their own servers in a Postgres database, right? That’s the baseline.

I also like the point you make around censorship resistance. A lot of this data is stuff that the user already knows and can re-input into the system on demand or reconnect the dots another way. Does that imply that you envision Privy being primarily used for identity-level data, or at the intersection of a person and an application, rather than, say, building a decentralized messenger where you need to store every message in the system in a private way?

Henri: That’s a really good question. The short answer is that identity and the cross-app intersection of identity is where we started our thinking. We’re doing a lot of work now around decentralized social networks, messengers, and maybe the notion of a data pod. I’ll name-check another project I really like, Farcaster, which has a great model around sufficiently decentralized data stores where the social graph lives online. By default, they give you infrastructure to manage your own casts, but if you don’t want them to manage it, you can swap out the storage for something you control yourself.

So, hopefully, we’ll do all of these things in time. However, to start with, it seems to me that the bigger threat is data leakage, not censorship resistance. The one caveat is that interoperability is extremely important. We need to give users a way to port their data from one Web3 service to another.

Sina: Got it. So, the takeaway on the storage piece is that there’s a set of servers holding all this encrypted data using cloud providers. The fact that the data is encrypted using all these mechanisms we’ve talked about is the real value proposition at this point. Over time, that potentially leaves the vector of censorship resistance open—like, I don’t know, if the US government wants to make this data inaccessible, they might have a way to do that. But because you’ve built this system in a modular way, where the three pieces plug together, you can just change how the data is stored while it remains interoperable with the rest of it.

Henri: Yeah, and there’s a really interesting question here, something we thought a lot about at Protocol Labs as well. How do we help build a system that emphasizes not just decentralization in terms of the entities running services, but also decentralization in terms of the underlying hardware on which this stuff is run? To some extent, I would question whether putting your data on a peer-to-peer network is enough. Who is running the peer-to-peer nodes? If your threat model is the US government, how do you know that the peers you’re storing data on are not also running in a cloud?

This is the distinction between economic decentralization—who are the actors making decisions around this?—versus infrastructure decentralization. I agree with you, down the line, if that is your threat model, the core step is to address that deeper level of decentralization.

Henri: If your threat model involves having a government come after you, then you should run all of your own infrastructure, in my opinion. There’s a lot of decentralization theater and fuzzy thinking that conflates the different layers of the stack and what’s actually happening. People just call something decentralized without really understanding it. It reminds me of Vitalik Buterin’s exploration a while back, where he discussed a metric for decentralization—looking at the number of independent client implementations for different blockchains, the number of developers on each, and where the nodes are being run. Really, the level of decentralization is only as strong as the weakest link in that stack.

But this is where I’ll come in with my most libertarian idea. At the end of the day, the only solution is transparency and user choice. I don’t think we can predict how decentralization will turn out or on which layers of the stack it will play out well or fall short. The best we can do is build a system that is composable, so as the world evolves, we give our users optionality and allow them to tune the system to fit their preferences and risk models.

The world is evolving, and there are a lot of very smart people working on different pieces of this puzzle. Building in a modular way lets you plug into these new developments as they happen. One of the most exciting things I’ve been seeing is the amount of work happening around self-sovereign identity and Web3 data. We’re addressing a segment of it through secure, private, off-chain data storage as a complement to on-chain storage. But there are composability networks and folks doing fantastic work there. I’m thrilled to watch how this stack will come together. The ISO layering hasn’t really landed yet. We’re in a post-Big Bang state where matter is plasma, and we’re starting to see granules of planets forming. I’m excited to see what the ecosystems will look like and how, as a builder in this space, I can create a stack that includes user data in Web3 five years from now.

If you’re building a product or protocol—which a lot of people are, like Uniswap with its frontend and smart contract system—you could use Privy very easily through our two APIs to store users’ private data. You can bake it in a way that’s much more secure than doing it yourself, leaning into all the composability that comes with it. Over time, users will be able to tie their data directly to their address. I think it’s a very worthwhile path for people to consider.

Down the line, the idea is that you can have an honest conversation with your users, with delightful UX, about their data. You can look them in the eye and say, “This is how things are being handled,” without worrying about cutting corners. I talk to so many developers who wince a little, knowing they could be doing better for their users but think, “I’ll figure it out once I have product-market fit,” or “once I’m done scaling this product.” It never happens, and it ends up screwing over both the products they’ve worked so hard on and, more importantly, their users. So, can we give you tooling that allows you to do a much better job on your own and also bring users back into the loop so they can exercise control over their own data decisions?

Sina: How do you think about how such a developer would run analytics or think through how their product is being used? How do they glean information and insights from that?

Henri: That’s such a good question, and one I only have the beginnings of a response to. Data analytics and privacy-preserving analytics in Web3 is a huge, underexplored space. It exists across levels like public intelligence—think the whole block explorer space, where I believe we’ve only started scratching the surface. Then there’s telemetry, understanding how peer-to-peer networks work. I think MEV—maximum extractable value—is, in a weird way, a version of blockchain telemetry. It’s about what happens in the dark space between the mempool and the transactions on-chain. The same goes for who’s running nodes and where they’re located. A couple of years ago, there was a huge power outage in a region of China, and Bitcoin’s hash rate dropped by a sizable fraction. That was the first time we realized, “Oh, that’s where the nodes are being run.” I find that fascinating.

Then, of course, there’s data analytics for end users—understanding who is accessing my protocol from my website, mobile app, partner integrations, or directly through my smart contract. The short answer is that Privy, as an encrypted-by-default key-value store, has some answers to bring there. However, I think you need more abstractions on top of such a store to build easy-to-use analytics for developers. It’s not our focus today, but shout out to everybody listening—if you’re thinking about data analytics for Web3, we’d love to help you build. Doing this in a way that respects users and their privacy is extraordinarily hard but also extraordinarily worthwhile, so developers can keep building better products.

Sina: There’s almost a need for an entirely new stack built on a fundamentally different architecture for how data flows in an application—across clients, on-chain, and off-chain systems. But every path seems to lead back to identity. How do you define a user? Is it my 0x1 Ethereum address? If I log in through Solana, can I link my Solana wallet with my Ethereum wallet? How do I do that?

Henri: That’s something Privy has thought a lot about. We actually have a data linkage, a wallet linkage API, that allows you to link multiple wallets together in a privacy-preserving way. But beyond that, there’s the question of whether I want that linkage to be made public and to whom. I might have a different DeFi identity and an NFT identity. How should that be taken into account by analytics providers in the space? Ultimately, this is a whole area we haven’t touched yet, but I think there are really interesting things to be built there. It’s a bit outside of our purview for now.

What I like about this approach is that it starts from the point of view of current usage—what specific applications need something like this today—and then backs into the larger vision. I think a lot of people, myself included for a short period in 2018, have thought about these broader ideas without grounding them in immediate needs.

Henri: These questions of identity and reputation just don’t work if you try to approach them in the abstract and design some magnificent system where all the pieces are supposed to plug in. There’s a lot of uncertainty in how everything evolves, and you also need to get adoption. Systems in the real world evolve from individual threads that grow in complexity over time. To double down on what you said, I completely agree. Most developers don’t wake up thinking, “How do I solve identity?”—unless they’re specifically working on identity solutions. Most wake up thinking, “How do I build a delightful tool for my users? How do I solve their problems? How can I send notifications without touching PII or information that puts my users at risk?”

So, that’s the problem we’re trying to solve for today. Frankly, this is why transparency is a core thing we’re building with at Privy. We’re making sure the systems are auditable before they’re decentralized, ensuring they’re open for scrutiny. As we make mistakes—and this space is too complicated for mistakes not to happen—we can be called out, and we can improve. Ultimately, the system is open source, so if you don’t like how we’re running it, you can run it yourself, and we make it easy for you to do so.

Sina: How has your personal experience working on Privy been? Are you enjoying it? What’s been particularly surprising or strange about this journey so far?

Henri: The biggest delight I get is working with my co-founder, Asta. She comes from the self-driving car world, so we were both thinking about similar data infrastructure and privacy problems. I was approaching it from a Web3 perspective, while she was more in the Web2 space. Merging forces and working together on this in a Web3-native way has been such a delight and a great complement. We have a zealot and a convert, and it’s been a lot of fun to see Web3 through new eyes. At this point, I’d say she’s a grizzled veteran.

Even with something like wallets, I started using new mobile wallets just last month because I realized there are all these wallets out there now that I didn’t know about. I had my old system with a hardware wallet and my way of doing things that I developed back in 2017. Now I realize the space is light years ahead of that. So, first, there’s the delight of working with Asta. Second, there’s the ability to see the space with fresh eyes as I dive deeper into the UX of Web3.

Another thing I find really interesting, going back to our conversation, is the tension between protocol-level thinking and product-level thinking in Web3. I find it easy to fall back on what I know from Protocol Labs, thinking about things at a systems level rather than focusing on the immediate problem I’m trying to solve for developers right now.

Sina: Totally. I think that’s one of the unique strengths you have—you can fluidly go back and forth between these two worlds, whereas most people primarily approach things from one perspective.

Henri: I hope you’re right. This problem of upgrading your own wallet setup is something I definitely resonate with. I think I’m squarely stuck in the 2017 paradigm, and I’ve had it on my to-do list to figure out how to update it. If I write a blog post about that, I think it’d make a very small subset of people incredibly happy. I’ve been thinking about doing a post where I run through a simple action with six different wallets and compare the experiences. You’ve given me the push I need to do it.

Sina: Amazing. I’m curious about your co-founder, Asta. I read a blog post you wrote a while back about questions to ask your co-founder. You’ve founded a company before and have been thinking about these things for a while. How would you describe your relationship with her? What can you share about that?

Henri: The first thing I’ll say is that I don’t think there are any hard and fast rules here. Whatever I’m about to share is useful only in the context of my personal journey. I’m a bit allergic to the Silicon Valley tendency to model out relationships or define what it takes to be a good co-founder. Ultimately, to each their own, but I’ll talk about what our relationship has been like.

One thing we did really well early on was investing in trust and communication. When we met, we were both on our way to building companies on our own. We just really liked each other. I was extraordinarily impressed with her intellect, hunger, and drive. I thought, “I really want to work with this person. I’ll be better for it, and whatever I build will be better.” We got introduced through a common friend who said, “You’re both thinking about data privacy; you should chat. Maybe at some point, you’ll want to work together.” We had a first call, and I hung up thinking, “Oh no, we need a second call ASAP.” We ended up talking every day for a week or two before saying, “Let’s get serious. Do we want to build this together?”

At the time, she lived in San Francisco, and I was in New York. I flew out there, and we spent a week together doing what I’d call hardcore therapy. We were walking, talking, and working through all the things that aren’t fun to discuss. What I’ve learned is that in the heat of the moment, when you’re working on a product, it can be easy to make everything about the product and forget the means of communication with your co-founder or team. So, we invested upfront, not in working on the product, but in talking about how we communicate, how we disagree, whether something I say is hurtful, or if I’m being unreasonable. We built up the trust so that today, it’s really easy for us to hop into a channel after a meeting and say, “I didn’t like this,” or “I really liked this,” without it feeling personal or like we’re attacking each other. We’ve built a communication pattern that allows us to be very earnest with each other, and that saves us a lot of time.

So, maybe the best thing I can say about our relationship, beyond her being amazing in general, is that it feels very safe. That sense of psychological safety with your co-founder means you can actually focus on the product and your users, which is where your focus should be.

Henri: I 100% agree. The level of trust you have together allows you to communicate with much more efficacy. You can communicate knowing that this person understands you’re coming from a good place. There’s no 3D chess happening. I think we’re both checkers players when it comes to communicating, which just saves a lot of time.

She brought in this cultural point, which I really appreciated. She used to work at Aurora, and a fun fact about Privy is that most of our team today comes from self-driving. We’ve got people from Cruise, Aurora, and Nuro. I know nothing about machine learning or self-driving, so it’s really fun to be a part of it. One of the things she introduced, which I thought was a great cultural point to have at a company, is to assume the best in others. When people come with an idea, start off assuming the best. I think that’s something we’ve been working with internally, and it’s been super helpful.

Sina: Yeah, kind of tying into this week that you spent together talking about things. I mean, it’s probably the most important decision in the lifetime of the company—who you’re starting it with. I’m curious, were you talking about these meta-level points, like how do we communicate? My sense has been that you can only really get a read on these things by going through an actual experience together and seeing how it happens in practice. Working on a project together is a very good way to get a sense of the underlying principles that this person holds. But I’m curious if you found an effective way of unpacking that root data itself.

Henri: The short answer is, I agree with you. We weren’t just talking about meta-level stuff, to be honest. We also put the guts of company building up front. What should the equity split be like? What should titles be? What will each person be working on? We talked about all the very uncomfortable subjects right away. Maybe it was helped by the fact that we didn’t know each other before. If we had been close friends, I think this is one of the pitfalls—when you work with a really close friend, you already have a language with that person. Sometimes it’s the same language as working together, and sometimes it’s not. It’s very easy to mistake one for the other and under-invest in the hard conversations when working with friends.

So, maybe it was helped by the fact that we were clearly here to figure one thing out: do we want to work together? Do we want to saddle each other’s product aspirations to one another? I’m maybe a deep co-founder romantic, but I think ultimately, the moment you take on a co-founder, the product isn’t really your own anymore. You’re co-parenting it with whoever you work with, and that obviously requires a huge amount of trust to put in someone.

Some of it was product conversations, some of it was tactical conversations around, say, fundraising, and some of it was guts conversations around equity ownership, ways in which decisions are made, and so on. Then, I think my last point is, I really like the image of exponential backoffs in linked lists in computer science. To me, there’s sort of an exponential backoff as you work on an idea and as you work with a partner. Initially, you commit to the day. After that first call we had together, we were committing to having a second call. Maybe after the second call, we were committing to another two, and after the next two, another four. By the time we flew out, we were committing to trying to make this work for two months. At some point, you kind of forget about the exponential backoff, and you’re just doing it. I think incrementally longer commitments is the way I found not to overthink things. I don’t need to sign in blood that this is all I’ll be doing forever the moment I meet someone. That trust can come over time; it just needs enough structure that we’re going through the tough things up front.

Sina: Awesome. Well, we’ve been talking for a while, so I think this is a good place to close. Thanks so much, man.

Henri: Thank you so much. Thanks for having me on. I love all this, and I’m really thankful to be a part of these things. Also, I don’t know if this is a thing you’re allowed to say, but I think the opening jingle is dope.

Sina: Thanks, man.