# Protocol Level Privacy Lesson From Web 2 by Polymutex || Ethereum Privacy Stack, Devconnect 2025

- Channel: [Ethereum Cypherpunk Congress](https://streameth.org/ethereum-cypherpunk-congress)
- Date: 2026-01-09
- Duration: 22:05
- Topics: web3, privacy, now, crypto, cryptography, blockchain, data, security, human right, rights, tech, technology, internet, open source, free, freedom, ethereum, hackers, ethics, cypherpunk, dev, developer, dapp, decentralization, bitcoin, computer, surveillance, cyber, peer2peer, p2p, love, solidity, zk, zero knowledge, education, academy, w3pn, privacy stack, devconnect, 2025, eps25, pse, privacy stewards of ehtereum, ethereum foundation, ef, Education
- Watch: https://streameth.org/watch/yt-dxvwrqGBBZE
- YouTube: https://www.youtube.com/watch?v=dxvwrqGBBZE

## Description

Polymutex from Walletbeat takes us through encryption volution and looks into protocol levels of Web2 and what lessons it gives us to improve with web3.

Ethereum Privacy Stack is a global privacy summit during Devconnect 2025 bringing together Ethereum builders, protocol maintainers, and advocates. 
Featuring Vitalik Buterin, Roger Dingledine, Andy Guzman, Polymutex, Ameen Soleimani, and 30+ speakers on 2 stages, celebrating privacy acceleration.

Ethereum Privacy Stack: 
http://eps25.web3privacy.info

Organized by 
Web3Privacy Now & Privacy Stewards of Ethereum

Web3Privacy now collective: http://web3privacy.info
Privacy Stewards of Ethereum: https://pse.dev/

## Transcript

[applause] Hello everyone. Name is Poly Mutex and I'll be yeah seeing if there's any privacy lessons we can learn from web two. As you can see from the subtitle, web two and privacy kind of sounds like an oxymoron, right? If you think about uh web two and privacy together, you probably think about headlines like these ones. Animations not working. Uh regardless, the web two privacy stakes have been up only recently, right? The privacy problems in web two have been rampant. And uh you know, it sounds kind of like a moxymoron. Regardless, I believe that there are lessons to be learned here, right? And if we look here at this kind of flow of where user data flows through in a web 2 stack, like there's privacy problems at every part of this pipeline. And some of the latest headlines are probably from the right hand side of this. Today I'd like to focus on this particular part of the pipeline which I call the transport layer. And I think that out of all the boxes in this diagram, this is the one where we can say with a straight face that the level of privacy that the everyday user gets is undeniably better than it was probably a decade or two ago because of the protocol upgrade that happened within the web to stack which is a transition from HTTP to HTTPS. And uh while HTTPS doesn't solve every privacy problem at the transport layer, you know, there's still metadata leakage and DNS requests that still leak information, it is still a net upgrade from the state of web to privacy. And this is why I want to focus on this particular one. It has many parallels to the state of privacy on web 3 on chain today. My name is Polymutex. uh I've worked somewhere in web two approximate to this particular issue of HTTPS and making that be um more um more widespread than it is and uh while I did not have a real front row seat I would say that I have a either second row or third row type of perspective on this uh right now I'm working on wallet beat which is the L2 bit of wallets uh if you understand that phrase you know what that means this is one of only two slides where I will shield this project because this talk is mostly on HTTPS and the parallels there not so much on wallet beat. Back to HTTPS. What can we learn from this? Uh, first up, a disclaimer. HTTPS and privacy and encryption. I'm going to use these terms interchangeably. And I'm aware that they do not mean the same thing at all. Uh, but all the points that I'm about to make, I think, stand regardless of this abuse of language. And so, for that reason, I'm going to just use it as a shorthand. Again, I'm only talking about the the confidentiality you get from HTTPS, which comes from its use of encryption. And that gives you some level of privacy from network intermediaries like your ISP or your proxies, your VPNs and whatnot. All right, the web in with that language we can say that the web started with no privacy. Why is this? The need for privacy was actually clear from the very beginning. This is a document that most in the audience should probably be familiar with. This is the cippher punks manifesto from 1993 by Eric Hutes in which he says privacy is necessary for an open society and in another paragraph privacy in an open society requires cryptography. So not only was the need for privacy clear in the very early days of the web but cryptography as the solution for bringing privacy to the network society was already clear as well. And despite this knowledge in the cyberpunk movement the web started with no privacy. Why did this happen? I believe that there are four core reasons and I would start with this first one as immature cryptography at the time that these protocols were being designed. This is a mailing list post from Halini who you probably know from 1995 in which he uh is challenging others on the mailing list to break the SSL encryption algorithm of the time which was 40bit RC4. And sure enough a few months later someone cracked it. And this happened not just once, this happened multiple times in a cycle where the latest uh default encryption algorithm of INSSL got broken and then a new one was replaced and the cycle repeated. So much so that this eventually made it to Wired magazine in 1996 under this particular uh article and uh you know this was back when Wired was pretty cool in which they covered this type of thing. And uh the there was a few of such iterations before SSL really was reliable and had actual encryption that was uh hard to break for everyday users. Number two is regulatory uncertainty. You are probably aware of this particular shirt which contains uh an implementation of the RSA encryption algorithm written in pearl in the barcode. And for this reason, at the time that the shirt was printed, this was designated as ammunition for uh reasons that it contained an encryption algorithm which itself was that was what was uh classified as ammunition. And this was not just for physical articles which you would think munitions would be limited to, but even software. So here on the right like this is a floppy disc contain containing version 1.1 of Netscape Navigator in which it says uh US and Canada only not for export because it contain cryptographic algorithms and so whoever would transport this over the border would technically be considered an arms dealer and have to register as such. Uh same for purely digital thing like you could argue that the floppy disc is a physical object still but here like this is the Netscape navigator download page from 1999 in which if you try to download Netscape the default version you would get here uh is the one that has 56 bits encryption and if you wanted the real stuff like the actual you know 128 bit encryption you needed to scroll down in this thing here and then click a bunch of obscure links that take you to like a bunch of FTP directories to find the right setup.exe exe to find the one that actually had the 128 bit encryption. Number three is the cost of encryption specifically here on latency. This was the subject of multiple research papers of which uh this is one where uh the mere fact of having an extra handshake adds a lot of latency to any web page load. Uh this is some graphs from this paper which show that for the Alexa top 500 websites basically you would make the load time be multiple of its existing level and it would add whole seconds to load the web page which means it would be a huge UX regression for web users and this is one reason why websites were reticent to actually use it. On top of latency there is also throughput overhead. These are a couple graphs from other papers that show basically that the more you encrypt like it takes time just to add the level of encryption even after the extra latency of having the handshake that you need to do for every connection. I believe these are some of the four core reasons why it was impractical to have privacy at the protocol level in the early days of the web and uh now I would like to make the parallels to web three. I want to point out that in the same way that the need for privacy and encryption was clear in web two from the get-go, in the very same document at the cipher pack manifesto, there is another paragraph here that says, "Privacy in an open society requires anonymous transaction systems." Again, this is from 1993. And it was already clear at the time for the cipher punks that financial privacy would be necessary for ubiquitous uh human rights in the open society of the of the network. And yet, Bitcoin did not start with privacy. Uh, Satoshi Nakamoto was himself or themselves aware of the need for this as well. This is one of the posts in the Bitcoin talk forums in which it states if a solution was found in the context of privacy on Bitcoin, uh, a much better, easier, more convenient implementation of Bitcoin would be possible. And yet, it did not launch. Now you might think maybe this is just like a Satoshi Nakamoto not being aware of how to do this but uh I don't think so because uh while it does say in the same post here lower that it is hard to think of how to apply zero knowledge proofs in this case for privacy on Bitcoin uh this here is Halini in 1998 giving a lecture about zero knowledge proofs of possession of pre-im images of a Shiaan hash and whether or not you think Halini is Satoshi Nakamoto it is the case that they shared ideas by virtue of being on the same mailing list regardless of whether or not they're the same brain. And so the knowledge that zero knowledge proofs exist and can be used for those types of things was definitely part of the set of knowledge that Satoshi Nakamoto had access to and yet Bitcoin launched with no privacy. So zero knowledge proves immature at the time. Two, regulatory uncertainty. Uh the screenshot on the right is uh it's a bit overlaid here because no animations but it was it is the Roman storm case that everyone here is familiar with. There is clearly some regulatory uncertainty here. Roman still needs our help. And uh if you remember that shirt with the RSA encryption algorithm from a few slides back. There is a tornado cache version of this t-shirt representing the fact that uh we're not out of the woods yet for this particular problem. Number three, the proof generation latency for zero knowledge proofs which are a necessary part of many of the uh privacy preserving token transfers that are necessary to have privacy on chain. This here is uh the performance of doing 100 E transfers and to prove them under various ZKVMs and the particular numbers don't really matter. What matters is the x-axis which uh I'm not sure you can see well here but it goes from 10 seconds to 1,00 seconds which uh is slow for 100 if transfers if you were to run the same computation in a non-provable context that would be milliseconds or microsconds perhaps and that while that's not a target it still needs to come way down and much closer to have it be ubiquitous and being able to run on phones or these type of things. A lot of work has been done in the last year but my point being that like initially it was impractical to use at the time that these protocols were originally designed. And number four is uh block space throughput overhead. This is the cost of gas of proving zkar zero knowledge proofs onchain for example this here is a tweet from Andy Guzman who's probably in the audience somewhere uh of a dashboard that does not yet exist. If someone wants to build it please I want to see it too. It would compare the gas cost of privacy preserving token transfers compared to their transparent equivalent to see what multiple away we are from having very cheap and abundant uh ways to do token transfers because as long as that's expensive then that's a major barrier for widespread adoption compared to transparent token transfers. All right. Uh so why did these start out with no privacy? In both cases, there was a clear need for privacy, but immature cryptography, regulatory uncertainty, high latency before the cryptographic algorithms give you something useful. And once you do get something useful, it takes a long time to actually or uh has a high throughput overhead to actually get to the end, meaning in one case the encrypted uh transmission stream, in the other case, the proof the proof generation and verification. Obvious parallels here, right? This is why I think that we can look at the progression of HTTPS and try to figure out what happened and why did it eventually take off to see if we can apply those lessons onto the web free privacy uh landscape. This here is data from Firefox telemetry which uh by the way you can opt out of but it is showing the percentage of page loads that are over HTTPS over time and the data starts in 2014 and I've just taken the liberty to like draw a random line to connect back to 1995 but that's probably what the the actual data probably looks like and we're going to go over this timeline and see where things line up. How did web 2 get to where it is today of 84%. Step one I think is to make privacy possible. This is making specs, making standards and create making privacy legible as an attribute that you can actually implement and uh have multiple implementations of and you know iterate over a standard like this. This is TLS and DSSL specification. This is the first part of the timeline and we're clearly not off the ground yet but it is clearly the first step. Number two is we need to make it legal. This is uh some of the work of many uh court cases and the FF has done great work on this to uh make civilians have access to real encryption algorithms with their DS cracking machine back in the crypto wars 1.0 day. The QR code here is a documentary from the NHK about the cypher punk movement and the crypto war specifically. And uh even if you already know all about this, this one is from the NHK in the '9s. So it has 90s level CGI. And because it's DNHK, it has a Japanese. It's it's all in Japanese. And so you can watch this video just for the vibes because they are immaculate. This is here on the graph. We're still not off the ground. Let's keep going. Step three, I think, is to make privacy cheap. Uh what happened over the next decade was hardware accelerated up codes inside the assembly function set that Intel started to have. So here there's uh it's behind the graph, but there's uh AES hardware accelerated AES for encryption. and then the Shiaan uh hardware accelerated up codes to make those cryptographic operations much faster and more efficient and uh increased L2 cache sizes which I think is a funny uh conflict of names because you know L2s if we put this on the graph here this took multiple it took a decade and then even more years I think the the reason why this is so slow is because this is requires a hardware refresh cycle meaning servers physically need to be rebought with the fresher CPUs before you can actually take advantage of this so it is a very slow rollout Number four, a mainstream o a mainstream oh moment that galvanizes the industry to actually do something about this problem. Uh here you know you're all familiar with this particular uh event. And let's put it on the graph here. Uh you can see that that's not exactly where things start but that's where things start to get interesting. The thing that happened quite a quite recently after this is to basically make privacy very easy to adopt. And I don't think that those two particular events are unrelated. There's a lot of work that's been done by the by the AFF like the SSL observatory. there's certificate transparency but I think the one that really changed the game was let's encrypt which was like the first very popularly adopted uh free SSL certificate provider which uh made it very easy for anyone with the domain name to get a SSL certificate and there are others like start SSL but uh what let's encrypt did there differently from them was to make it extremely simple and easy and to have the process of regenerating certificate be the default and the path of least resistance compared to like start SSL and all the others which used to do this yearly where you have to do this little dance of opening a web form and filling some information downloading a certificate ftping it over to your server and remember to do that every year otherwise your site is going to break here it is on the graph you can see that this is where really things really start to pick up and uh I don't think this is a coincidence and this doesn't mean that the previous steps were needless they were all necessary but you need that fourth step of the tooling to make it super simple to have the adoption actually happen number six you need to make it the default. Browsers are starting to do this where they will automatically upgrade to HTTPS whenever that's possible. And you can see on the graph, it doesn't actually move the needle that much, but it is a prerequisite for the next and final step, which I think is to make privacy normal. Um, what that actually means in practice is to make non-privacy abnormal or to remove the double negative. It means we must stigmatize non-privacy. And this is what browsers are starting to do where they're going to be showing these types of warning messages whenever you go over any HTTP site because that's an insecure thing to do. And so the default and normal thing to do now becomes the HTTPS version. This is here on the graph. This just started last year in browsers to have this type of policy. And so we will see the effects of this in a few years. But I believe this will get it much closer to 100%. Although there will always be a long tail that will never upgrade and that's fine. To recap the protocol privacy transition, you need to make it possible, legal, cheap. Then maybe you need to have an oh moment to get the rest of the things done. Making it simple, default and normal. And uh now I'd like to bring this back to web 3. Let's see where we are. So on making it privacy possible, I think this means standards, right? Same as SSL and TLS. So we have stealth addresses which have been formalized. There's a lot of deposit based um privacy preserving token transfer technologies. There's the wormhole EIP that I I really like as well. So, I think we're pretty good on this front and this is uh making good progress on the legal front. Um I don't think this is quite as good. This here is still other legal cases that need our attention. The last panel was pretty that give me a little bit more hope. But what I what I would really like to see as well is the EFF getting involved here because I think the only thing they've really done in the space is uh to write one amicus brief in the Roman storm case and that's about it. I would really want to see more from them, especially given how strong the parallels between the crypto wars 1.0 and these particular cases are. Um, yeah, so more work to do here on making privacy cheap. I think everyone here uh is well aware of those efforts, but you know, we need more efficient proving. This is very much alive. Uh, EVM upgrades and pre-ompiles for proof verification to make the it very gas efficient and zk friendly hash functions. For the same reason, we can use L2s here to help us iterate faster before bringing them to L1. So, this is doing great progress as well. Then, I'm not sure about an oh moment. I was trying to think of like what could it be? And the only thing I could think of that had like the same level of mainstream awareness that forces external mainstream pressure to force an industry into compliance might be this one in terms of magnitude only. But it was not really privacy related unfortunately. So, we couldn't really use that crisis as a galvanizing moment. Now, I'm not saying we need to like do do something on purpose here, but I do think cynically speaking that uh we will have the need to have some kind of moment that forces us to galvanize. Perhaps this conference itself is going to be a sufficient call to action. That's my best case, but you know, the cynic in me is a skeptical still. Next, making privacy simple. We need tooling for wallets. This is obviously where Kohaku comes in and possibly other implementations. And uh we need other things too like privacy first wallet APIs to do things that currently would leak information to dabs like doing asset balance requests or payment requests. Right now you leak your address and you know could be done in a more privacy preserving way tooling for dabs to be able to use these new particular APIs doing address isolation. There's a bunch of others on this list. I think there needs to be some work here beyond Kohaku as well. But Kohaku is a great great step. Making privacy the default. This is the only other part where I'm going to talk about wallet beats but we need privacy by default and wallet bit will be the force that adds this pressure and uh yeah we're here for that and then privacy normal this is where you come in because normalizing something needs means everyone needs to create that normalization so please do your part here's a summary of every actor that needs to step up which I think covers basically everyone in the room the only thing I'm not sure about is this oh moment part but uh Yeah, other than that, I think we're on a great track and thank you for listening. [applause] Thank you. So, we do have some questions. Thank you for uh for asking. So, one I thought that was particular in particularly interesting is how do I stop being shamed for being private? >> Privacy is normal, right? This is what we must have ubiquitously be the normal stance. This again means that we need community awareness. We need outreach. We need organization organizations like like wallet beat to make that be the default and we need to stigmatize the inverse right like that. That to me like is the logical endgame. We can shame them back, right? I think it should be shameful for people to do non non-private payments for I don't know uh doing peer-to-peer transfers or having like DAPs also be shamed back for like not caring about privacy. Look at how dabs treat things like um your metadata leakage when you open them. Open the network inspector, see what they're doing and complain, open bugs, make privacy the normal thing to be. And there there was another that was maybe a little too spicy. So I'll just take it down a tiny bit which is to ask uh which wallets we should be cautious of. So perhaps we'll say what kind of wallet behavior should we be aware of? What are warning signs? You might want to look at one of the recordings from another talk of uh me and uh Nico from the EF on wallet beat in which I displayed a particular screenshot from a particular wallet which uh has five letters in its name and start with an R uh in which it is shown that this particular wallet whenever you connect to a DAP will leak your IP address and your ARM address and the URL of the page that you're visiting to their servers without asking you about this. And uh wallet beat does have this wallet listed and you can see that it says that it's doing that. They still have not fixed it. I'm hoping that uh they eventually fix it. But uh no wallet is perfect still on this particular metadata point. This is just like the most egregious one. >> Thank you very much. >> Thank you. [applause]