 He's a software engineer on the Mozilla Identity Team, the guys who do Persona, Browser ID, and he fights for the open web by building alternatives to centralized proprietary silos. A long-time deviant developer, Francois has been involved in open source for over 10 years now and regularly contributes to several projects. He also volunteers for the FSF, that's the Free Software Foundation, and he leads the development of LibraVatar.org. His talk today is about killing passwords with JavaScript, where we'll understand why asking users for passwords is a bad idea, and then we'll learn the basics of the Browser ID protocol slash Persona, so that you can take advantage of Persona on their own sites or web apps. With that, take it away, Francois. Thank you. Can everybody hear me in the back? Yep. Excellent. Now, if you've been following the tech press recently, you will have noticed a number of companies apologizing publicly after getting their passwords leaked to hackers, right, waking up one day, finding all of their passwords in some basement on the internet. Now, I could make fun of these companies for not following best practices and things like that, but the reality is that doing this is really hard. Keeping passwords secure is a hard problem, because you have to do a whole bunch of things. You have to use a secure hash algorithm, i.e., not MD5. You need to use per user cell values. You have to have a site secret that's outside of the database. Then you need to have password and lockout policies to prevent brute force attacks. And of course, the recovery mechanism that you use for when your users forget their passwords, that has to be just as secure as the rest, otherwise the rest may as well not exist. But what's the biggest problem with this list now? The biggest problem is that these are the 2013 password guidelines. I can guarantee you that in five years, there's going to be even more stuff that you need to do to protect your passwords, because this is an arms race between you, the site owner, and the attackers trying to get at your passwords. Not a good position to be in. So for you, as a site owner, passwords are really a liability. It would be really nice to be able to just get rid of them, right? I don't recommend that you do this right now. But it would be nice, right? So second problem with passwords is that they're really hard to remember. That's a big deal for users. Now you may think, well, users could just harden up and use a password manager, right? There's one every web browser. There's a couple of products that do a really nice job, syncing across devices, all of that stuff. But the reality is that when we ask users what kind of password managers they use, they said, it's one of these. Not exactly the kind that we like people to use. So instead of using password managers, what do users do? They employ this strategy. They just pick a really easy password. That way, it's not a big deal to remember that password, because it's really easy. This is the top 500 passwords, by the way. You may be able to spot a couple of weak ones. The other thing that a lot of users do is this. They just use the same password everywhere. If you've only got one password, it's much easier to remember all of them, because there's only one of them. Now, of course, this means that your security, well, basically you're just as secure as the worst site that you use this password on. Because if that site gets owned, then basically all of your passwords are leaked. So an attacker can just access all of your accounts. So there's lots of problems with this. The other thing, of course, is that passwords will be forgotten, so users have to reset them. You need to provide some kind of mechanism for that to happen. And typically, it looks like this. You type in a username, email address, and then you will receive an email. You click a link, and then you set a new password. The usual password reset flow that every one of us has seen before. Now, what this means, though, is that if you control someone's email account, you essentially control all of their accounts through this reset flow. Now, I'm not saying that's necessarily a bad thing, because if you have a strong password and you use two factor authentication, for example, with Gmail, then that password is very strong. And it's not a big deal. But I'm just saying that's the current state of things today. Now, this is an alternative to passwords. One that's quite popular with a lot of sites. And I'm not saying that it's always a bad thing to do this. There are lots of good reasons to go that way, which is outsourcing your passwords to a big for-profit company. But there are big disadvantages as well. And one of them, of course, is what do you do with users that don't have one of these accounts? Nobody is going to create a Facebook account just to log into your site. They're going to use Facebook login. They'll already have a Facebook login, maybe, but they're not going to create a Facebook login for it. So there's a bunch of users that you're going to lose if you don't have another mechanism for logging into your site. But the other thing is that there's an awful lot of users that will not want to sign in with Facebook into your website the first time. Because at that point, they don't have a relationship with your site. They don't trust you yet. And they know that Facebook shares a lot of information with your site. So there's about 10%, 15% of users, sometimes more, that have a Facebook account and won't use it to sign into your website. So you're losing quite a few users, actually. The one that don't have a Facebook account and the ones that don't want to use it. So it's something to think about. Now what about OpenID? OpenID is really interesting because it brought back the idea of decentralization to the idea of web login. Now decentralization is good because it allows users to choose who they trust. When you choose an identity provider, you're basically choosing someone that has the ability to impersonate you on a whole bunch of websites on the internet. So you better choose someone that you trust. And unfortunately, when we don't have a decentralized system, you're forced into trusting someone that a site has selected for you. That's a problem. Now the biggest problem with OpenID, though, is this. This is one OpenID looks like. It's a URL. Now URLs work for all of us because we know what they are. In fact, many of us probably have a vanity domain that we use, so we have very short and nice URLs. But it doesn't work for the average web user. They're confusing, and they don't associate URLs with themselves. So what did sites do? The sites that are using OpenID. Well, a lot of them said, screw this URL stuff. It doesn't work. Just going to pick the most popular 10, 12, whatever OpenID providers, and then users can just click on the one they have, or choose one of these to log in. But notice what happened here. We just lost the ability for users to choose who they trust. Now they have to choose someone from this list that has been pre-selected by the site. And in fact, that didn't even work because there's far too many choices. It's confusing for users, so a lot of sites said, oh, well, just pick a top two, or whatever it is. So it made OpenID usable at the cost of decentralization. But this is the real reason why we can get behind OpenID as Mozilla. And the best way to understand the privacy problem with OpenID is to think of this analogy. Imagine that the next time you want to check into a hotel when they ask you for a piece of ID to make sure that the name matches the one on the reservation. What if the hotel were to phone up the government that you showed that ID to check that it's actually valid? It would be a little bit creepy because all of a sudden, that government department would have a trail of every hotel you've ever checked into. But furthermore, they would have the ability, based on other information they have, such as, I don't know, maybe you haven't student loan that you haven't fully repaid yet, they would have the ability to say no to your hotel stay. They could say, well, you still have debts. You shouldn't be going to these luxury hotels. Pay your debts first. It's a bit of a stretch, I admit. But unfortunately, these are exactly the kinds of powers that we give to an OpenID identity provider. Also, the Twitter, Facebook, and the centralize authorities. But this is the deal with privacy. So all of this to say that the existing login systems on the web are not good enough. That's why we're still stuck with so many passwords. So if we're thinking about the ideal web-wide identity system, what would that look like? Well, the first thing is that just like OpenID, it would be decentralized. It's important to give users the ability to choose who they trust, to change identity providers, and to run their own if they want to. OpenID did this. We should do this. The next thing is it has to be simple. If the user experience is not great, then users are not going to want to use your site. Then you lose a whole bunch of potential customers. Or if they really have to use your site, like it's an internal site and they need to use it to get paid, then they're going to fail, and then they will drive up your support costs. So it has to be simple to actually work. But it also has to be simple for developers. Because if it's not simple for developers, there's no chance it will ever be secure. And finally, we're no longer in 2003. Internet Explorer no longer has 95% market share. We need a system that works on more than one browser. It needs to work on all of the browsers that people use on all of the devices that they use. Otherwise, it's useless. If I was standing here and telling you about a login system that only works in Firefox, you'd be right in not being interested. So what if this were a standard part of a web? What if it came with your web browser, this login system? Well, that's exactly what we're building with Persona. Now let me show you how it works. First thing to know is that Persona is based on the concept of a verified email address. This is my email, or one of my emails. If I can prove to you that I own this email, then when I come to your site, you can create an account for me that's tied to that email address. Next time I come along, I will show you the same proof, and then you can let me in. No password needed. That's the idea. So verified email address. And so I'm going to invite Nigel and Rakesh to join me for a little demo of the browser ID protocol. That's the protocol behind Persona. So I'm going to be the browser. Nigel here is going to be Wikipedia. So I'm going to try to log into Wikipedia using browser ID or Persona. And Rakesh is going to be Gmail, my identity provider, because I've got a Gmail address. So the first thing I'm going to do is, I'm the browser. I'm going to generate a public and private key for that identity. And I'm going to call that a certificate with that email address. So I've got a little certificate here with my email address. And now I need to get it signed, because it needs to be a verified email address. So I'm going to go to Mr. Gmail. Hello, Mr. Gmail. Oh, you don't have a mic. I will bring a mic for you. Let's try again. Hello, Mr. Gmail. Could I get you to sign my certificate, please? Sure. What's your password? Good point. I actually need to authenticate before Gmail agrees to sign my certificate. So. Thank you. That's great, that's great, that's great. So I'm locking this now with my private key. Excellent. Thank you. You can keep your private key. I don't need it. Although that said, it would be really handy next time I need a new certificate. So now here, I've got this certificate that is signed by Gmail. So what I need to do now is I need to create an assertion. Now if I were to use this directly to sign into Wikipedia here, the problem is that Wikipedia might be able to just turn around and then impersonate me on another website, because it would have my certificate. So instead what we do is we don't use certificates directly, we use assertions. Assertions are this little cryptographic bundle that contains three things. It contains, of course, a certificate, but it also contains an audience and an expiry. The audience is just the URL of the site you're trying to log into. So in this case, that's wikipedia.org. The expiry, I'll say expires in two minutes. That will give me enough times, enough time to sign in and then the assertion becomes useless. So there you go. I'm going to seal my assertion, my certificate in it. And now I'm going to take it to Wikipedia to log in. Hello Wikipedia, log in please. Well, let me check your assertion. The audience is Wikipedia. Oh, that's me. And the expiry is in two minutes. OK, this is the right time. I'm going to look at your certificate. OK, so you have your provider is Gmail. So I'm going to get a key from Gmail. Hello Gmail, can I have your public key? Sure, here you go. Thank you. So notice here that when Nigel went over to Rakesh to request his public key, he left my certificate in here. He didn't actually need to reveal to Gmail who was trying to log into Wikipedia because it's the same public key for everyone. So that's where we get the little progress in there. OK, so I'm going to try and unlock this with Gmail's key. Oh, it works. Welcome to Wikipedia. Thank you. Thank you, Rakesh. Excellent, so that's a browser ID protocol for you. Now, I'm going to show you a little demo of what it looks like on the web. And I'm not going to use the Wi-Fi. Instead, I've got this little screencast here. So this is Vos, a site that uses Persona. It uses Persona and Facebook. And the Vos guy tells us that there's about 60% of users that prefer Persona to Facebook. So let's just sign in with Persona, since it's the most popular option. And here we're using an id.me email address. id.me is a domain that has native support for Persona. So what's happening now is that we're being bounced over to id.me to get a signature on our certificate. id.me is asking for a password, because that's the email password for id.me. That's what they use as a login mechanism. So we provide that. id.me says yes, signs the certificate, it's returned to the browser, used to create an assertion that is then sent to Vos to login. And there you go, as you can see in the corner, I'm logged in. Now because I have the certificate on my browser already, I can use it to sign in to another site that uses Persona for Login. So this is DebugX. As you can see here, I've got my email address already in the dialog. So two clicks to sign in, second click is for User Consent. And there you go, signed into DebugX. So the point of this demo here is that Persona is today a decentralized system. id.me has native support for Persona, and that's where we went to get the signature on the certificate. It was their sign-in page that we saw, but the Mozilla was not involved in that part of the transaction. Now the fact that it's decentralized means that everybody's free to innovate on the login mechanisms that they use to sign in with Persona. We've seen someone that uses PIN codes sent by SNS. There's an identity provider that does that. There's another one that uses Jabber, Ubiquiz, LDAP, that's the one that we use internally at Mozilla, and then even client certificates is a guy that works with C8 that has written one of these. And there's also a slightly crazy person that decided to put, that he didn't want to back end for his identity provider. So he put the public key and a private key in full view of everyone, but he encrypted the private key with a password, so everything happens in the browser. Pretty cool. Not sure we'd recommend it to everyone. But the main thing I want to make here is that we want decentralization. It's a good thing, but it's not a product adoption strategy. And by that, I mean that you can't just wait for all browsers to support Persona before you get started. What we want, where we want to get, is there. We want new functions directly in the DOM. We want functions that are available to all browsers. But how do we get there? Well, one way to get there would be to create an add on or Chrome extension. But then that would require users to install these things before they can use Persona. Not a very good thing. Sites are not going to be interested if only 15% of their users can use it. Next thing we could do is we could build it into Firefox. And in fact, we are doing this. But the problem with this is that we can't rely on this because this is what, a desk, a quarter, a third of the browser market? It's not enough. There's not a site that will be interested in this. Well, we could also build it in Chromio. That's the open source project behind the Chrome web browser. But still, we're looking at, what, like half of the browser market? Three quarters, if we're lucky? I don't know. It's still not enough. We need to have a system that works everywhere. So this is what we decided to do instead. JavaScript. We wrote a temporary JavaScript shim that makes it work in all browsers. And this pattern that I'm going to show you is called lift, or locally isolated feature domain. Now what this means is that if you want trusted code running in the browser, which we do because it's dealing with people's private keys and things like that, the first thing that you're going to do is you're going to get a domain. The domain, in our case, is login.persona.org, this one. And then you're going to use local storage. Now local storage is interesting because everything that will be stored in local storage using the code that's on that domain will be tied to that domain. So if the code on login.persona.org generates a public key and a private key, stores it in local storage, then only that code can access the keys. Which means that another website, Wikipedia, can't actually go and touch the keys. The last piece of the puzzle is post-message. This is what allows us to do cross-domain communications. So the whole thing looks like this. You've got Wikipedia on one side that's talking over a post-message channel to the shim that's running on login.persona.org. And that's the piece that has access to the keys. And over there, it can decide what restricted API to offer to all the sites that use Persona. Make sure that they can use the system. They can't actually have access to the keys. And what this means is that we work on all modern browsers, both on desktop and mobile today. The second part of this, though, is that we can't wait for all domains to add support for Persona before we get started because we're going to wait for a really long time. There's an awful lot of domains on the internet. And so what we built here is a temporary centralized fallback. Now, I say temporary because as soon as a domain gets native support for Persona, the fallback automatically goes away. It's only there for domains that don't support Persona. So let me show you how that works. So this is a slow blog. It's a site that uses only Persona for logins. I'm going to click Sign In. And this time, I'm going to use an aol.com email address. Yes, they still exist. So now what's happening is that it's asking me to pick a password with the fallback identity provider. So when a domain does not support Persona natively, that's where the fallback identity provider kicks in. And this one asks us to set a password that's not specifically the site for all Persona sites, but just to make sure that we don't have to confirm our email all the time. Next thing is that it sends us an email with a unique link to click on. That's to make sure that we're actually the owner of that email address. Before the fallback identity provider is willing to sign certificates on behalf of AOL, it will check that we're actually the rightful owner of that email address. And so there we go. We're all done. We confirmed the email address, and now generated assertion with the sign certificate, and we're logged into Solon. So the point of this demo was to show you that Persona works today with all email domains, either through the fallback or through native support. But we can do better than this. There's a feature called Identity Bridging. And what that is is that if you look at a couple of email providers, they already have an API that people can use to authenticate against them. For example, Yahoo has OpenID. So what we built is a bridge that talks OpenID to Yahoo and BrowserID to your browser. So let's see what that bridge looks like. So this is another Persona-only site called ReasonWell. And I'm going to sign into this one using a yahoo.com email address. And what you're going to see here is that the bridge is going to kick in. And the bridge will then bounce us over to the real yahoo login page. So we don't have to set a new password. We're just using our existing yahoo password. And yahoo will then confirm to the bridge that yes, it's the right person because they authenticated successfully. And then the bridge will be able to sign certificates on behalf of yahoo without having to have an email confirmation step for that user. And so there you go. Certificate is signed. And we're logged in. It's as easy as that. So it works today with yahoo, as you just saw. And it also works with Gmail. So we have a bridge that speaks all of the Gmail and then BrowserID to the browser, which means that today all of these users have a neonated experience with persona. So persona works everywhere. Before I go, though, I want to share with you a couple of quick lessons that we learned in our project. And the first one is that user testing is really important. This is what we use to recommend to people. Just put this button when you want to add persona to your website. Unfortunately, it doesn't work. A lot of people don't know what the hell a persona is and they don't think they have one. So they didn't click on that button. Even worse was this one. Now, a couple of people use this because they had on Facebook, Twitter, and then they just added a third thing that was Mozilla persona. Unfortunately, this was even worse because a number of people were like, oh, well, I use Chrome. I can't click on this because it obviously requires Firefox. It says Mozilla. So don't use this either. What we found is that this one works a lot better. Sign in with your email. Everybody has an email. Just click the button and use it to sign in to this website. Second thing is nobody wants to be first. This is not a surprise, but this is a very popular question that we get. How many users does persona have? It's really annoying when you're trying to start a new project, when you're trying to start a new identity system. The answer is initially zero. But what we did is with this bridging I've just shown you, now we're able to say that we have 700 million users that are ready to go with persona. They don't need a new password. They don't need to click an email link to get started. So that's a big deal for us. And finally, if a problem has been around for a while, like password problem on the web, it's probably a hard problem. See if you can solve parts of it. For example, with persona, we're not going to solve this problem. You're not going to use persona to sign into your server via SSH. You're also not going to be able to use persona to log into your Windows desktop. And that's OK, because persona is designed as a simple login system for the web. That's what we're focusing on. That's the problem we're trying to solve. Now, how simple is it for developers to add to their websites? Well, the answer is it's really just four steps, four pretty easy steps. And you can find them in that URL, which will be at the end of the presentation as well. But just to give you a flavor, the first thing you have to do is to load this JavaScript file. So this is the ship. This is a temporary JavaScript ship that works out in the fact that browsers don't have native support yet. Then what you do is you call a setup function. You pass in two callbacks, the one for when it's time to log your user in, what do you do? And the next one is when it's time to log your user out, what do you do? The third one is you have to hook your login and logout buttons to the right things. So login would call navigator.id.request. No parameters needed. And logout would call logout. Finally, you need to verify the assertion, like Nigel did, server site. It's important because you can't trust a client to not lie about it. And for that, we provide a bunch of libraries. Usually it's just two lines of code, and you're done. And the best part is that you don't need an API key for this. None of this bullshit. You don't have to ask for permission before you use persona. Now, I want to leave you with one small request. And that is stop making the problem worse. Stop making the password problem worse on the web. And by that specifically, I mean, if you're building a new website, default to persona. Now, I'm not saying you should always use persona. There's lots of good reasons to use something else sometimes. But don't start with a default of asking users to pick another password. Just start with persona. And if it turns out it's not the right system for you, choose something else. But don't start with passwords. If you have an existing site, please add persona to it. As you've seen with foos, you can easily have persona next to Facebook. And in their experience, it actually works better than Facebook, but for their particular site. But there's no problem in using persona alongside other things. What you might want to get rid of, though, is any sort of fallback mechanism you have, other than the Facebook and Twitter things, if users don't want to use stuff. If you're asking for an email and password, for example, you can replace that with persona. Here's a concrete example. This is how you sign up to Pinterest. This is what they have currently. And this is what I'm suggesting they do instead. Can you see the difference? The difference, of course, is the click handler on that button right here. You change that to use persona. Then you can get rid of that ugly form and that ugly column as well. Thank you very much. I have a question. There's one there. So obviously you need a browser for this to work, right? So what if I want to access an API that's exposed by a website that's behind a persona thing? I'm writing a thick line, a desktop line to invoke an API. I won't be able to use persona there, right? So the question is basically if you're using another application that wants to talk to an application, you'll be a REST API, how to use persona, that kind of stuff. What we have to distinguish is authorization and authentication. Persona is authentication. So what you would do in that case is use a different technology for the authorization part. So for example, say you have a thick client on a Windows desktop or whatever that needs to authenticate with your app. What you would do is you would show a web form initially to the user so that they log in. And at that point, they log into your website. And some kind of token is exchanged. The app keeps the token. And the token can be revoked later. But basically after that, when the app needs to talk to your REST API, then it would just exchange a token. It wouldn't use persona for that part. We only use persona for the initial setup phase. Thank you. We're not trying to replace all of these things that people do. We're trying to get rid of passwords, basically. I'm Kostav. I just want to add something to what you said about the setup part, is that there are plugins available for Drupal, for WordPress. And for Drupal, it's the breeze to setup persona. You just install the Drupal module, and the module does everything on its own. Yeah, there's lots of that URL here, libraries and plugins. There's lots of libraries available for various languages, lots of plugins available for open source software frameworks, things like that. So thank you very much. That's a good point. All right, Francis. In the second video, in the fallback mechanism, when the email comes to the user's inbox, the look and feel of that email was not off the website that he was trying to log in, that could be a really jarring user experience, in my opinion. I'm glad that you pointed that out, because we have a new feature coming in, it will be coming in the next couple of weeks. It's actually committed to the repo. It just needs to go through QA that actually adds branding to the email. So there will be an ability, I believe, to put the logo of the site and then the background color for that site. Just like in the case of Vos, I don't know if you noticed, but Vos actually had a logo on the right-hand side. So in the Persona dialog, you can customize the background color, the logo, as well as the name of the site. So you can actually brand the right half, they can be all branded for your site. The left half is, obviously, asking for the email stuff that's persona-specific. One more question I have is that in Persona, all that information that I get about the user is just his email address, right? So as opposed to if I was using Facebook login, I would get all of his profile and friends and relationship status, and I don't know what it's possible. In your experience, has this been a concern from the website developers? So we've talked to a couple of people that use Persona, like the Debug X guy, for example. We talked to him, the Vos guy. And a couple of them, I want to say all of them, but at least most of them, said, please keep it just the email. We like the simple. And it's a simple story for users as well. Like if you log in, I'm going to get your email and that's it. They really like that, because a lot of people that click on there definitely don't want to click on Facebook for that exact reason. So I think we're probably going to keep it that way. Hello? In the fallback mechanism, you said that the secret key will be stored in the local storage. But I doubt the local storage is not a full-fruits mechanism since any cross-scripting attack, any hacker or any security breacher, if he does a cross-scripting attack on your website, then he will be able to grab those things from the local storage. So how it is secured? So the question was about the security boundary for local storage. If the JavaScript of the shim is compromised, then you're right, then basically that's the JavaScript that has access to the key. They can just take the keys and post them somewhere else. If you're talking about the JavaScript for the site that's compromised or something like that, something that's not on the login.personal.org domain, then that JavaScript doesn't have access to that part of the local storage. So for an attacker to actually get to your keys, they need to actually inject code on our servers on the login.personal.org domain. And that will also go away when we have native support in the browser. So in the native version of persona in Firefox that we're working on, the keys will not be stored in local storage, and the code that's accessing it will not be downloaded through the internet either. But still today, it's safe from a typical cross-site scripting attack. So like what he said, I just wanted to know, now that we have packaged applications using Firefox or Chrome. So suppose I'm building an offline application that I need to run on a user's desktop. And I want the support of persona over there too. Even when internet is not there. So what is the support for that? So that comes down to pretty much the same question that this guy had. You use persona for the initial login to exchange some kind of token, and then you use that token for the authorization kind of aspect, for the everyday kind of request to REST API or whatever. You just present a web view the first time. And so there's people using it successfully on mobile and other things like that, and that's kind of the approach that they use. The last thing you want is to show the password prompt every single time someone signs into your app, of course. Hi, how safe do you think would it be to use persona on a shared computer or a shared browser, maybe? So what happens when, say, you're in internet cafe or something like this? What I didn't show in the demos is that the first time we assume that you are on a shared computer. So we make the certificates valid for a very short amount of time, and they basically go away when you close the browser. Now in most internet cafes, the between users, like the cookies will get cleared, and local storage is actually clear at the same time as cookies. So it's not usually a problem, but we still use short-lived certificates, short-lived sessions, the first time you use persona. The second time we ask you whether or not it's your computer, if it is your computer, then we extend the length of the certificates. If you say that it's a shared computer, then we keep really, really short. So there's a small window of opportunity if you go away and you leave the computer without clearing the cookies and stuff, that otherwise it's fine. Question from Gmail here. Yeah, question from Gmail. Do you have any suggestions to help sites transition from their current, other than, of course, alter table drop column? Any other suggestions in terms of UX to smooth the transition from their current database-based login system to persona? So what I would recommend there is that first of all, you start in your application to make sure that email addresses are unique for users. So it has to be unique. Then you can add persona support without removing the existing thing that you have. Basically, if someone wants to log in with persona, you just do an email lookup in your database. You find the account that matches that email, and then you sign a person in. The other thing that I would, and so you can keep the two systems for a while while people get used to it. One thing you can do as well is you can be sneaky. And I forgot my password page. You can say, hey, if you were to use persona, you wouldn't need to reset your password. So you can do stuff like that. And then when you're ready, then you can go ahead and get rid of the form and delete your password column. There's a couple of things. If you go on to MDN, the quick setup, at the very last step, step number five is more information about persona. And that's where you can find things on how to make sure everything is secure and also advice like what you just asked for transitioning. Things like having more than one email, changing your email, all sorts of things. So we've got a few things on this. One last question, yeah? So for my understanding, tell me if I'm wrong. Can I think of this as open ID? But instead of URL, we're using email addresses. It's an interesting way. So you can sort of think of it as open ID with emails. But I think what you mean there is open ID because it's decentralized, and it's pretty much the only widespread system that was decentralized. I think it's still different for open ID for three reasons, like usability, of course, as you mentioned, it's not URLs. Also, security. We want to build it into the browser so that it can no longer be fishable, because with open ID, you can just fake someone's ID logging page and grab their password. You can do the same thing currently with persona, because it's all happening in the browser. But in the content window of the browser, but once we pull it out into the browser UI, then it's not going to be possible anymore. And the last thing is privacy. I think it's a really big difference with open ID. With persona, it's a little bit like how you use these things, these passports, to travel to international countries. The first thing you do when you want to go to another country is that you go get a new passport from the passport office, and at that point you don't have to tell them which country you're going to visit. You just get a passport that works for all of them. And then when you go to the other country, you present your passport, and they let you in. But the step of getting a credential and using a credential, those things are separate. They're not in the open ID world. So that's a big difference. That's how we can get the big privacy advantage for persona. So anyways, that was the last question. But I'm going to be here all evening and tomorrow. So also feel free to approach me or other Muslim people if you have any more questions. Thank you very much. One big round of applause, guys. The Mozilla guys are just superstars. Keep going up to their booth and bugging them. They will be, this is their job. They love answering questions and telling people how to do it right. Thank you, Francois. One more round of applause. That was pretty cool, man. Come on.