Web3 is Reintroducing Cross-Origin Tracking

Transcript

[music] [music] There we go. Um, yeah. So, just wanted to That's not my slides. All right. We may need to just plug in my stuff. >> So, yeah, we'll keep it quick. Um, yeah. Uh, basically, I just wanted to call out that we're reintroducing a problem that the browsers have already solved. uh everybody except for Chrome because they actually can't. Um but yeah, essentially re reintroducing cross origin tracking.

If you think about what a uh wallet address is, um effectively uh what the consent pattern that we have within the wallet today, you show up at a website, you hit connect, and you share a wallet address. Um that is incredibly similar to what you're doing under the hood when you're actually sharing a cookie. Um so when you hit that accept all button for the uh cookie consent panels um you're actually doing the exact same thing where uh a cookie is being set in your uh browser and then it's being stored in that sort of way. Your wallet is just effectively the difference in the storage layer. Um so this is the comparison between the two. Um, effectively when you're visiting the site and then you get prompted, you know, connect the wallet and then you click connect. Um, you're sharing an address uh with the site is the same

thing as sharing just a random string which is what a cookie is. Um, so an address because of its bit entropy and its uniqueness. Um, it does the exact same thing. You approve it and then um, yeah, it gets shared with the site and then the site is able to utilize that to be able to continue to track you later on. Um, so essentially why browsers killed this. Uh first of all, we don't trust the the site in general. Um we sandbox it away from it. Uh similarly, so uh we realize that this is a privacy problem. Um and so because of that, like that's essentially why I'm trying to call this out here, that we shouldn't be doing this in the first place of trusting uh the site to be able to have this address because it will operate maliciously over time. uh today it's

it's been kind of like the only design pattern that's available to DAPs. But uh as we go forward essentially you're publishing all of your economic data and all your transactions by uh sharing that uh with the any sort of site. Um and the other fact that comes into play is uh it's persistent. So uh all of your money stays within your account and so then that becomes that sort of problem around like uh how EU's cookie consent law works. um when you hit that you're effectively consenting to these sorts of things. Uh similarly, so you know the sign in with Ethereum uh UX actually made this worse because now you don't just have one uh consent pattern, you actually have two because you need to first share the address so that then uh the site can generate the transaction to

then be able to sign over it. Um so it this is the UX problems that we have in the first place. It actually goes back to the way that we design our APIs. Um so how do I propose like doing this differently? I think we actually need to be looking at the RPC layer between the DAP and the wallet itself. Um, so this is something that we've been working out at CASA. Um, that's the chain agnostic uh standards alliance. Uh, that's wallet connect and and many different wallets have been proposing this. This is effectively a design of how you can do a checkout flow uh without needing to share the wallet address in the first place. Instead, the site says send me this amount of money to this address with this token on this network. Um, it's a very uh agnostic design approach to be able to make that work. Um, and in

that sort of way, you're having this highle API that does it in such a way that the wallet doesn't need to share the APIs in general, as well as you can abstract all the complexity of the network away from the site and make it much easier for them to be able to utilize blockchain. Um, so yeah, essentially don't rebuild the patterns that we've already solved. Um, we should be fixing these problems instead. That's it. [applause] >> Thank you very much, Kyle. I really appreciate the way that you're uh helping us become private again in the web 3 space. So, are there any questions for Kyle? One up the front.

>> Do the deposit address flow change this problem or it's kind of similar with uh sharing your address and private? >> Yeah. >> Um so there you have the whole other problem of network tracking that occurs as well. Um, and so this is where you need the actual protocol layer to be solving this. So like thing that comes into it. Um, and yeah, we we need to be combining this in a composable layer. And so this is actually makes it easier for us to be able to do this because the wallets can hide all of that under the hood and can start changing and swapping it um because of the better API design.

>> Beautiful. Good to have time for another question up the front. >> Awesome. From another browser. >> Exactly. From browser to browser. Um, so it's in it's very convenient to just log in with your wallet and uh just press a button and click. Is there anything that replaces this with a less tracking pattern apart from I mean this was just for making payments what you what you talked about or is it also for authentication or logging in like crossite? >> Yeah. So effectively you're designing around a login uh flow instead. Um so you're just designing a different level high level API and that's kind of the generalized pattern that we should be looking at within the wallet space is how do we define uh these APIs for these generalized flows. So if you think about

it uh there's like the web crypto API within the browser itself which does very low-level just signatures but then you can also use something like uh pass keys and the web authentic design. So that's kind of the difference between the two. What we have within the wallet today is just very low-level APIs because that was the original design choice that was made and it made it easy. Um, but we need to start looking at what highle APIs we can do and then how we can deprecate some of these older ones. >> Beautiful. Thank you very much, Kyle.

That's all time for questions we have. So, we're going to have a short one minute break before we get Thomas up here to talk about some robotics. [music]