 Web 3 is redefining the level of control people have in ways that was deeply different and how this had been done before. Not only that, Web 3 has started with literal financial value. Even though this is an empowering proposition, we see how meaningful has their money compromised every day. I'm Antonella, I do product security at MetaMask. My folks are there. Before that, I've been led the user experience team at the Tor project for half of the decade. Deploying privacy and hasing technology is not a crime. Wallets can be a lot of things. We can define wallets as a container of private keys and their system of permissions to manage them. Every time a DAB asks the wallet to execute a transaction, the wallet is asking the user to confirm the usage of these keys. Dan Fili and Eric Marx made a beautiful definition. Wallets are built around the responsibility of mediating the interactions between untrusted applications and users' keys on the computers, getting appropriate consent from the user. If we map a threat model of a non-cute wallet, like MetaMask, we will discover that the two more important assets that we have at stake are a pair of keys and the permissions to use these keys. This talk is not going to be about private keys, it's not going to be about artifacts to protect these private keys, like seed phrases, passwords, past phrases, or attacks or that. Today I'm going to talk about permissions, and I want to talk about permissions because permissions is the elephant in the room, usability topic depth for end users in this ecosystem. There is a lack of interest at protocol level on how protocol decisions affect everyday people's lives, and the responsibility of giving users the chance to understand what they are giving permissions to falls on wallets when we talk about permissions. We talk about an invoker requesting a wallet access to certain user information. It can be different depending on what the DApp is prompting the user to do. During a connect flow, for example, the DApp is requesting access to users' public keys, the address, to be able to push requests in this way, and this is the user-facing interface on how the request looks on users' computer. I'm sure some people have been facing these screens before. The wallet is making an epic effort to expose and trust information in a secure environment in a legible manner so the user can consent to execute or not this transaction. We do things like treating intelligence, treat analysis, human review. We have a lot of mode for preventing supply chain attacks. You should check out Kumabi's talk from yesterday. We have phishing detect block list to mitigate phishing attacks. Our bounty program, and more. People who work on security know that this is called elastic security or security index, but this is not enough to enable users to consent and transaction. I will stop and I imagine that some people is questioning why we are talking about consent in a user security talk, and friends, because they are not secure systems without consent. Consent is the radical idea that one person must voluntarily agree to the proposal of desires to another. Thinking about this way of building technology is to give feminists perfective to active consent, to apply it to the social information system that we work with every day. These are not my ideas. These are ideas that came in the backbone from the feminist principles of the internet for open human-centered design processes. Basically, when we talk about consents with technology, we talk about having control over our digital bodies, which of course include our data, and for sure our money. So how a transaction based on consent should be? A few people have been thinking about this, defining a framework on how to approach a consensual way to have an interaction. I really like the five principles defined by folks at Aliette Media. You can check this and more in the website, consentsfullteach.io. Good consent is freely given, it's revocable, it's informative, it's enthusiastic, and it's specific. And what do we mean by all these things? The fact that the consent is freely given puts the person in a position of doing something with another that should be made without pressure, with force, or manipulation. Anyone can change their mind, or what they do at any time. Trust is not forever. This is why transactions should be revocable. People should be able to understand what the tradeoffs are of this decision. People should be able to read what they are going to consent to. People should be able to comprehend what is going on. Consent should be enthusiastic. If someone is not excited or really into it, that is not consent. Consent should be specific. Saying yes to this now, today, here, in Bogota, in October, doesn't mean that I say yes to other things. So we started to question our interfaces and how they could become interfaces that could enable people to give real consent. The use of a security design question that we put over the table with our teams, with designers, with developers, with project managers, with people working on metrics, with people working on communication. If we build a transaction flow grounded in consent, how could it look like? You spoke, and we are listening, we read social media, we read the forums, we read, and we are working hard on improving our confirmation screens. Even when new transactions' methods are being defined right now in other rooms on protocol level without considering how to expose users to a consensual interaction. Let's see the case of approvals. Approving token allowances is like a fundamental pattern of We3 in We3, to allow smart contracts to interoperate tokens and provide a better user experience with interactions with that. In order to perform operations that require interactions with amount contracts like minting, stocking, swapping users are first required to permit the invoker's smart contract to transfer a number of tokens on their behalf. Sometimes that required improving this infinite amount of these tokens. Even if the user trusted up, it could be problematic. This is our current token allowance screen. We have the original mind requesting this transaction. We have the contract explicit who is asking for this interaction, but the point here is we don't have allowances in the first screen of this flow. We have been working on that. We iterated this. This new UI aims to empower users to define an allowance that they want to give to them. We split the flow in two. We now have gas fees in the second screen, which was something that people was looking too much on the first version. And now we have specifically who actors are interacting in this transaction. We allow users to verify contracts. We are making explicit which assets are being transferred. We are adding friction to warn users when the site is requesting the entire collections on a MSD to be transferred. I say that before, can verify contract details and more things. Echoing on what Taylor said this week, we should be responsible of what technology we build. We should build technology that expects people. As developers, as wallet developers, we have the responsibility of critical thinking about how to expose users to give consent to a decision that directly affects the digital bodies. And these allow us to explore opportunities to design the centralized technology that respects people, but practicing open design methodologies. Balancing security and usability is complex. We do a lot of complex things here. It requires inadequate threat modeling, the possibility of including people in your development process, and trying to understand people's mental models too much with the flows that we propose as a facilitator of consensual transactions. We are trying to generate more open spaces to discuss use of all security in the decentralized world. If you are a product, if you are a designer, if you resonate with this, you can find me. I will be happy to talk about this. If you are a security researcher, if you are a hacker, if you want to bunch our services and get money, we have a hacker one program in place, hackerone.com. If you are a developer and you have ideas on how to improve MetaMask, you want to extend it, you want to connect your API to MetaMask.xpi, expose the MetaMask UI, you should check out MetaMask.io. I personally believe that there is a long way to go to rethink how the information systems which we delegate trust interact with consent. This is an open call, and I invite you to think about that with me. Thank you very much, Antonela, and we have several hands up. We are going to start here, but we have a lot of questions, Antonela. Hi, a super presentation, thank you. A quick question, the UI that you presented, is there is a date when they are going to be released? We are working on that later, quarter four, yes. We work in an open environment, we have repositories, so you can check stuff. Next question, we have some one, two and three. Hello, Antonela, thanks for your talk. In your presentation you told that as a security researcher you have to do balance between user experience and security. How do you draw that line of saying the user is supposed to know the thing and I have to teach the user the thing that I have to know. Good question. I don't think we are here to teach users. I think we are here to inform people to make informed decisions. The balance between how much information we show on the screen and how this information resonates with people and also the time that happened between the people make a decision and read, may vary and change. I think that is the most fun part, finding this balance. I think it's super important also to work with users. If you have a product, if you are building a product or whatever, you should have users in your development process, so you can expose users to your product early and you can get feedback and that is so rich because you have people using your product before you go live or whatever, so that answers your question a little bit. There is one, two and three and four. We have time. I see the fifth here. Please. Thanks for a great talk. Part of your definition of consent you discussed revocable. Where does MetaMask or the UX fall with revocability and helping the user know that they can revoke or what they have given consent to in the past? Beautiful. It's a protocol issue. It's not our problem. We should work together on protocol level to make sure that, I mean, to comprehend that we are human and we can make mistakes. I know that revocability is like a hot topic in this space. There are a lot of ideas on how to make transactions revocable. You can do things like, I don't know, having a space of nones in the middle and you have a certain time that you can revoke and stuff. There are smart people thinking of that, but yeah, it's an open question. Hi. Great word using a consent. How do you think it's possible to handle a sign-in message consent, specifically when we sign some structured information on MetaMask, you will see a JSON that is really hard to understand and there's been a lot of hacks lately based on ERC20 tokens able to permit user to sign message in order to allow for transactions. So it's very hard for a user to know if you're approving genosis multi-sign transfer or giving permission to someone to spend your tokens on your behalf. Have you thinking any kind of mitigation for this problem on MetaMask? There are a lot of initiatives that wants to make transactions readable. They are, I mean, I remember five right now, but there's a lot of people working on that. I think it's the next step for big adoption. Should be having transactions in a readable manner. I see companies making their own versions of this. We should aim to have a community level consensus on how we are going to expose these two users. I think it's more powerful if we work all together than if a company says that they are doing clear sign-in or something like that. So yeah, I think it's a work in progress and I hope you are building also a solution for transactions to be readable. Hi, thank you so much for your presentation today. I feel like I learned a lot. So one question I just really want to ask is about MetaMask product design. So as far as I know, initially MetaMask didn't want to launch the swap function and they launched the swap function. I just want to, I just feel like in the current space, the switching network is really a significant problem in improving UX. I just want to ask more about what's the future plan on MetaMask about this interoperability issue and does MetaMask have any plan to solve this network switching problem? Yeah, amazing question. I can open my computer and show you our designs after the talk and we can discuss it. We are working on network abstraction. It's super interesting because super early in the moment right now, the options are infinite. Like I don't think the version we are going to ship first is going to be the best one but I think it's something good that we are going to iterate and we are going to learn also how people is using different networks. We are thinking, we can talk an hour about this. But yes, please find me and we can discuss. How did I solve it? Hi, I actually have two questions if allowed but one is a follow up to the question before last about signing and permissions and how those interact and even where they are readable if there's one particular thing that's being asked for over and over and over and over and over again, the user will get alert fatigue and just be clicking and to avoid that I was seeking to have a permission for that particular thing that gets repeated many times and was here for the hackathon last weekend and wanted to use made a mask snaps to make that easier and was told, oh no, actually made a mask snaps doesn't support working with the permission system to do that. I was wondering if there are plans to allow snaps to work with the permission system in the future to follow up on that. Good question. I think the most powerful thing about snaps, it's like the least affirmation we have available right now is not static. It's something that is going to grow in the future. So I'm not here to say when, but that may be something that is in the pipeline. And the other question was you showed earlier some designs where you were making it clear that like, oh, you can set a limit for how much of a token a particular depth can be authorized for and you have a line in there like, oh, you can raise this limit later, but you aren't telling people that there's a cost to do so. There's like a financial cost of doing so later. And I think that that seems to undermine this idea of consent a little bit because you're not telling people that there are going to be costs if they want to limit things now and then add it later. Do you have any thoughts about why that decision was made to obscure that? We are not exposing future costs of the transaction and maybe something that could be part of some documentation on user-facing education material or something like that, estimating how the thing is going to cost in the future. It's weird, but I don't know. Maybe it's something to explore. Thank you for that question. And the last one. Hello. Yeah, thanks for this great presentation. It's really insightful. So I have a question around the fact of giving consent. You mentioned that it's quite complex because it's either you give too much permission and you fall into like an area where it's dangerous as a user or you give too much restriction and then you hurt the usability of the user because the user then cannot do that much. What's your opinion on that? How do you find the sweet spot of the right balance, like this right area where it's not too risky but on the other side is not too unusable? Great question. It has different parts. First, you should have an interdisciplinary team working on stuff because it's more powerful. You have more views when building something for people. Then there is something very strong happening at Metamask right now and it's the fact that we are building a product for the entire world, put us in a position to hire people from all over the world. So basically we have people working everywhere. And this is powerful because you have people sitting on tables making decisions that have different biases, mental models. This is one part. The other part is talking with users. I think talking with users is so insightful. You are going to discover things that you even imagine in the first, second, three rounds of user testing. So, diverse team, users first and try and iterate. I think finding the balance is the most fun part of being working on this. Thank you very much. We have time for one last question in Spanish. Also, if not, if not, muchas gracias, Antonela.