Privacy Habitat and Infrastructure

The talk argues that privacy must be designed as the habitat of a system, including its metadata and external side effects, rather than added as a narrow content-encryption feature.

Key takeaways

01

Encrypting content does not prevent metadata from revealing relationships, routines, and communication patterns.

02

DC-nets trade bandwidth for anonymity that survives as long as one participant remains uncompromised.

03

A private agent also needs private side effects because searches, messages, and compilation requests can reveal what the agent is doing.

Summary

The central claim is that privacy is an environment, not a feature. Content encryption can hide words or files while metadata still exposes who communicates, when they connect, which groups they join, and what kinds of attachments they exchange.

As an alternative direction for anonymous broadcast, the speaker described DC-nets based on shared secrets and one-time-pad-style XOR operations. In the stated model, strong anonymity remains if one participant is honest, with bandwidth efficiency as the explicit cost.

The design rule is to minimize assumptions from the beginning. A system should not be called private merely because one component uses encryption or a trusted execution environment while side channels and metadata remain exposed.

The proposed agent use case places an agent and its private data inside a trusted execution environment, then mixes the external actions that would otherwise disclose its intent. The examples include messages, search queries, and code-compilation commands.

How it works

01

Map every disclosure

Identify the content, relationships, timing, attachment sizes, and external requests that would remain visible despite content encryption.

02

Form an anonymity set

Participants use shared secrets inside an anonymity set; the stated anonymity guarantee holds as long as one participant remains uncompromised.

03

XOR the shared secrets

The DC-net combines one-time-pad-style shared secrets with the message to create an anonymous broadcast, trading additional bandwidth for privacy.

04

Route every side effect through the mixer

Messages, search queries, and compilation commands leave the private TEE agent through the anonymity layer instead of directly exposing its task.

Slides

Transcript

Who loves privacy? Who wants privacy? Who feels they have good privacy right now, it's pretty good, and they don't really want any more? Yeah. Okay. So privacy is pretty important. We all know that. We've heard a lot about it over only the last few days. So what I'm gonna talk about in this talk is where I see the future of privacy technology going in the next maybe two to three years, or at least where I would like it to go. This is, this is something I've been, dreaming about for a very long time, and I think between the two kind of, communities of blockchain and AI, both of which are kind of represented in this room, we have actually a really, really cool opportunity to build privacy.
So the first thing I'm gonna say is that privacy isn't a feature, it's the habitat. We talked about coordination yesterday, and one of the things that came up was kind of the balance, of information, the power of information, the trade-off between exploitation and kind of coordination, when you reveal information, and this is present throughout every aspect of society. It's particularly salient between people and their governments, but it also exists in financial settings, for example. Like a lot of people may, you know, know about WallStreetBets and the kind of meme stonk movement. A lot of that stuff, kind of, goes through Robinhood, right? And there are companies, there are companies right here like, you know, maybe right across the river from us, that can see that private data or ostensibly private data before other people, and therefore make, you know, billions of dollars every year of profit off of that kind of thing.
So privacy is pretty central to outcomes, both in terms of how people relate to their governments, how people relate to their communities, how people relate to their money and the systems that exchange it, and, things like that.
So this is, this is, one thing I want you to walk away from. So encryption, which is commonly one solution to privacy, and you can replace encryption here with your favorite privacy technology buzzword of the day, whether it be zero-knowledge proofs, multi-party computation, you know, fully homomorphic encryption, IO, whatever. A lot of these things are kind of designed and proven to hide very specific pieces of information and very specific contents. So when you encrypt a message on Signal or something like that, what is actually being hidden? The contents of your message, the words that you're writing are being hidden. And that is actually a very nice thing. So your words reveal a lot and, you know, your pictures and the other things you might send, those things reveal a lot, but so does your metadata.
And your metadata includes things like who's talking to who, what times are you connecting to the service, what is your phone number if you're connecting to Signal, what group chats are you in with what other subsets of users, what does your social graph look like, what are the sizes of your attachments and the files that you're sending, you know, and, all of these kinds of pieces of information. When is your phone on to pull for notifications, et cetera. So a lot of these things actually reveal much deeper things about your life than even the contents of your messages might reveal. They reveal who you're talking to, they reveal who you're closest to, who you answer the most quickly, and in many cases, properties of what you're sending, like how many documents, are you sending pictures, are you sending videos, things like that.
And so encryption alone or any single privacy technology is really not enough, to kind of build this habitat of privacy where we actually get to a better outcome, and, better control of our data. So you want privacy today. Let's say you wanna browse the internet. This is a very common use case. What are you gonna do? So one common answer is just use Tor. So much like a lot of the other technologies that I just mentioned, Tor is proven in a very particular environment or designed in a very particular environment. It's designed to basically obfuscate or hide internet traffic and communications, through something called onion routing. So in onion routing, you basically choose a number of computers, let's say seven, in this kind of mesh of volunteers that are signing up to mix your traffic.
And then you send from one to the other to the other to the other sequentially encrypting your thing basically in an onion. So you encrypt it first to this person, then you encrypt the encryption to this person, and backwards down the path. So every node you send it to can then unwrap one layer of the encryption. They see where it's going next, so they're able to send it, but that's all they see. They don't necessarily see if the person it came from was the source of the message or not. They don't see how many hops might be left on the path. They don't see the contents of the message unless they're this last node to whom it's intended.
There's some details there about proxying the internet and stuff. But there's a pretty fundamental flaw with onion routing, and that is that if you have compromised the majority of this mesh or this cloud, or even a substantial percentage over time, you're actually able to gather a lot of data about the routes people are using. And especially for use cases like internet browsing and things like that, these kind of have traffic patterns and fingerprints that are easy to identify and analyze. So in terms of an empire, when you have something like NSA's PRISM or you have like people who like the Carnegie Mellon attack on Tor directory servers where people are able to spend a lot of money over a long period of time, kind of poisoning this pool of volunteers, this is actually very dangerous because you may think you have privacy, you may think you're able to be free, but you may actually be being recorded.
So onion routing is, is not actually very good privacy like in a global sense. So unlike onion routing, this is one troll that I have. We at Flashbots believe that systems for anonymous broadcast globally that are much more similar to, DC-nets in the literature. So these are, kind of systems that work via XORing shared secrets, and then there's a bunch of variations of them. There's also mixnets and other systems that kind of encrypt among sets of people or, sorry, shuffle among sets of people. But DC-nets, what's nice about DC-nets is that they have no assumptions, so they actually don't use cryptography. You kind of have to use encryption for an authenticated channel, but that's basically the only cryptography you're using.
The security and the privacy is based on one-time pad. It's based on the XORing of messages, which is somewhat inefficient, but it is very, very private. So as long as one person in the entire network is not compromised, you basically have the maximum level of possible privacy guarantee, and you do pay an efficiency cost for this in bandwidth. So what I call this is basically privacy without assumptions. So, my troll today is that we actually can build systems of privacy that don't assume that your network is not being surveilled, that only assume that one person in the entire network is honest, that give you very, very good anonymity guarantees among those sets of people. And these things are useful for everything from messaging to, you know, whistleblowing to, for example, agents that need to do sensitive operations and maybe don't want to reveal, the data that they're actually doing those sensitive operations on.
So false privacy is a deadly product. This is something I believe very strongly. This is one reason you all may know I have many rants against Signal and Tor, because in many cases, it's actually more dangerous to believe you have privacy and then not actually have privacy than to not have it at all. I have a rant about how I think Signal is actually a government backdoor because of the sheer amount of metadata it leaks into a single centralized collection service. Not only that, but they require phone numbers, and they've actively resisted changes, to even have forks use things like usernames that are kind of less metadata-laden, more anonymous, and harder to compromise by state actors.
So we have to be very careful. I think this is our obligation as technical people. When we tell something something when we tell someone, "This is secure, this is private," it's not like a box that you check where you, like, encrypt something in a TEE. Maybe you don't really think about the side channels and you say, like, "Here you go, turbo ship it." We need to design privacy from the beginning, from kind of the, habitat, as I say, of where the products exist in and the core architecture of what we're building, not kind of bolted on later. That's not good enough. And we should start with zero assumptions. So there are already systems we can use for privacy that require much fewer assumptions than anyone's one's in use today, and we should move to those immediately.
Why I say we have an opportunity, I think crypto and AI together, they demand these things. And they actually have some very, very nice properties that work well with these kinds of mixing systems, like they don't necessarily need that millisecond synchronous UX that humans demand on Web2. They're able to use more private information retrieval systems that maybe have some bandwidth or latency overhead. So I think we should start with zero assumptions. We should push privacy as far as we can go before, whether it's crypto or whether it's AI, before it gets enshittified and corporate, by the large forces of capital that kind of push against us all the time. We should build this kind of as far as we can.
And let's put the whole stack underground, not only Ethereum, but also agents. Let's have them, go dark so that we have as little information revealed, in the substrate as possible. Finally, for you AI people, you agent people, this is kind of one use case we're thinking about for agents, so if this interests you, reach out. We're in the process of kind of speccing this out and building it. So in this sense, it, you can think about having an agent in a TEE, and all of the data that agent has is private. Well, that agent still needs to do things. It still needs to Google stuff, and if it's Googling like, "Hey, what are the best doctors near 29 Nassau Avenue, Brooklyn, New York?"
Well, Google probably knows that you just asked your TEE agent to look up doctors, near 29 Nassau Avenue, Brooklyn, New York. So how do you actually mix these side effects? You can think of what we're building as a kind of mixer, but for any kind of information, from messages to agent search queries to code compilation commands to whatever, and we hope that you all explore, once this is kind of further along, plugging this in. So this is going live in demo and hopefully paper form, next week. If you're interested in being part of this and building on top whatever else, find someone at Flashbots who isn't me and ask them how to do that, and they will help you out because I have to run to a birthday party right now.
Hey, I just want to say I really enjoyed your presentation, and I have, I guess some questions about how you think about, some of, like, the wicked problems that come with privacy. For example, like cyber lockers and things like that. What's how do you think about it, from your standpoint in terms of, like, we have a lot of the same problems. We're creating private technology. How do you, how do you think about addressing that as people, bring it up?
Yeah. So this is maybe gonna be a, maybe an unpopular answer or maybe not in this crowd. I think the way I think about it personally is, like, starting with things that are very purpose-specific and valuable, and legitimate and kind of building on those. In terms of, like, people misusing or attacking various aspects of it, like, I think that is somewhat inevitable. But I think today we're in, like, such a bad trade-off point with privacy that, like, people doing that at the edges, as long as it's not what we're building and, encouraging and working towards as a At this point, I think is an acceptable cost. I might have been, like, more cautious to just kind of turbo send privacy a few years ago.
But I think the, game theory of surveillance and, all of our other privacy systems kind of dying out, and the concentration of data, and LLMs storing and categorizing it all, I have less, sympathy to slowing down the acceleration. That's kind of my view. But I think privacy also doesn't always mean, like, a lack of control. Like, a lot of what we build at Flashbots are kind of those balanced systems. It's like, okay, you want your trade data to stay private, but someone wants to be able to compute on it, but you want to know that they're only using this data and not that data. That, I think, is the kind of system that we're able to build as a society.
So I think this is, like, a broader conversation in the world of, like, what does this mean? How should we govern it? What rules should the system we use subscribe to in terms of, like, what is or isn't executed inside? But the system itself you can kind of customize however you want. So can't stop people from abusing that. We won't encourage it, but, you know. Hopefully, that was like a, like a legally line-towing but acceptable answer. Yeah.
You mentioned this is good for, like, async systems that, aren't as, dependent on, like, the latency trade-off. Is there anything where more synchronous, like, real-time systems could in any way benefit from what you're doing? Or do you feel like they're kind of just inherently gonna have to eat the risk?
I mean, I think, depends what, what exact use case we're thinking about. I think So messaging, I think, is somewhat okay. So basically, there's a trilemma that we believe at least exists in anonymity systems with three points. There's privacy, there's bandwidth, and there's latency. So you can have very good privacy, but you have to trade off one of very bad bandwidth or latency. So for messaging, like, the way I think about it is it's okay if the backends, for example, think the infrastructure running the internet, the servers running Signal and your messages, consumes a lot more bandwidth than today. I think that's actually okay, and we can keep the latency, like, actually pretty similar. There may be a little bit of an inherent penalty because you need input from multiple participants inherently versus one, so you're kind of stuck with, like, a response time that's, like, the slowest mixing server plus the round parameterization for the anonymity.
But it's, like, not too bad. Like, I think... Like, I could totally see this being used in, like, sub-millisecond blocks and, you know, messaging with almost imperceptible latency and things like that if you're willing to trade off bandwidth. Yeah, with some design changes.