 4.30 PM, but apparently it is not the last talk of the day, so I hope you guys aren't too excited to go see the show tonight and are excited to talk about web security. I'm Emily Schechter. I am product manager for the Chrome Security team. And today, we're going to talk about protecting users from deception. So let's start with passwords. It's no secret. Passwords aren't enough to protect account security. We took a look through our search index to see if we could quantify the amount of passwords that have been leaked and published out on the web. And what we found was actually pretty disturbing. 3.3 billion unique username and password pairs. And these were not stolen from Google. These were stolen from many other third parties and breaches. Unfortunately, frequently these passwords on these sites do get reused with us. About 17% of the time, users reuse passwords. Luckily, at Google, we've proactively worked to secure 67 million of these accounts. But other web properties might not be as lucky. Now, it's not all bad news. At Google, I'm happy to report that more than 99.9% of the time, even if an automated attacker has your username, password, or perhaps even knows your phone number, we block their attempts to access an account employing our automatic defenses. But that still leaves some accounts. So let's now focus on the case where an attack would still get through these automated defenses. There are three sources that we see stolen passwords coming from. Fishing attacks, where individual users are tricked into giving up their credentials. Keyloggers, where software installed on the device captures credentials. And data breaches, where large amounts of credentials are stolen at once. And we can compare these three sources of stolen passwords and how many passwords are out there from each source. But what's really interesting to look at is what the source of the stolen password means for account hijacking when someone actually takes over the account. Compared to a generally active account, if your credentials were in a data breach, you'll be 10 times more likely to have your account hijacked. If you had a keylogger installed on your device, you'll be 40 times more likely to have your account hijacked. And if you were phished or deceived into giving away your credentials, you'll be 500 times more likely to have your account hijacked. And that's just a lower bound. So phishing hands down creates the largest vulnerability for web users. Over 90% of information security attacks start with phishing. And phishing was used in 80% of attacks on businesses. Phishing scams are becoming increasingly sophisticated to a point where some are impossible for the human eye to detect. So we absolutely must leverage the wide breadth of tools and technology at Google to keep users safe online. In 2016, we even saw phishing overtake exploit-based malware in terms of the number of unsafe sites that Google's safe browsing technology detects. So for all of these reasons, we built Chrome with security in mind from the very beginning. We think that you shouldn't have to be a security expert to feel safe on the web. So Chrome was built to be secure by default and easy to use by everyone. So I'll now talk you through how Chrome protects you from deceptive sites and phishing attacks. And then later, my colleague Christian will talk through what you as a developer can do to help protect users of your service. Google's safe browsing has helped protect Chrome users from phishing attacks for over 10 years. And Sundar actually announced in his keynote just earlier at I.O. that safe browsing now helps protect more than 4 billion devices every day by showing warnings to people before they visit dangerous sites or download dangerous files. Safe browsing protections work across Google products like Search, Ads, Gmail, YouTube, and they power safer browsing experiences across the internet with the Safe Browsing API. Chrome's integration with safe browsing was built from the beginning to be privacy-preserving. So Chrome downloads a continuously updated list of known phishing and malware websites that are generated by an automated analysis of our entire web index. So each page that you visit and each resource, like pictures and scripts, are checked against these lists in a way that doesn't reveal the websites that you visit to Google. And Chrome's Safe Browsing API is free and publicly available, so you can use it to protect users of your service from dangerous and deceptive sites. Safe browsing has always scanned the web for these dangerous sites. But if a phishing site is created and used for attack moments later, even the quickest scanners can't warn people fast enough. So from our years of experience detecting phishing sites, Safe Browsing's insights can now enable us to make predictions about risks in real time. So we use this knowledge to launch new predictive phishing protections in Chrome this past year. So now when you type your Google account password into a suspected phishing page, we'll add additional protections to ensure that your account isn't compromised and we'll help you reset your Google password. And these protections on your account apply even if you use a different browser afterwards. So what this predictive phishing protection is actually doing is basically password reuse detection for your Google password. So when it sees that you've typed your Google password into some site that's not Google, we're asking Safe Browsing for a real time prediction of whether the site is likely phishing. And we built this detection from the start with privacy in mind. It doesn't save keystrokes or send those keystrokes anywhere. Plus we use client-side heuristics to make sure that we're only asking Safe Browsing about sites when it looks suspicious in the first place. So while password phishing is a hugely important problem to protect against, it's not the only way that scammers might try to trick you to make money. So imagine that you're browsing the web on a mobile connection to maybe access a gaming page. And you're presented with this page that asks you for your mobile phone details. So you fill in the blanks. You want to get to your game with your mobile number. You press Continue. You get access to the content. So the next month, your phone bill comes and you see a big charge that you weren't expecting. Was the subscription to the gaming service really that expensive? Did you really agree to pay that specific price for the service? How much did you agree to be charged to access the content? So what actually happened here was that the site is including this tiny notice to tell you that you're being charged. And even if you notice the text and read it carefully, it's still pretty confusing to understand. So every month, millions of Chrome users encounter pages like this with insufficient mobile subscription information. Surprising charges that come from unclear communication are a poor user experience. So that's why starting in Chrome 71, we launched a new warning before these unclear pages so that users can make informed decisions when they're signing up to mobile-based subscription services. Users are offered the choice to proceed to the page or to go back if they were unaware that they were entering a billing page. So I've just talked through some of the ways that we've improved Chrome to better protect users from deception. I've shown you how safe browsing is relied on across both Google products and external apps to protect against known threats and proactively detect new ones. Defense in depth is important. And at the beginning of the talk, I told you that passwords weren't enough to protect users. So as a developer, you need to be looking at what you can do to strengthen your own services to protect your users. So for that, I'd like to invite Christian up on stage to talk about the latest advances in authentication and security keys and how you can implement them today to better protect your users. Hi, folks. I'm Christian. Thanks, Emily, for the previous section here. What I want to do is talk a little bit more about phishing. As we saw in Emily's presentation, if you are a victim of phishing, you are 500 times more likely to suffer an account breach. So what I want to talk about is what you as a developer can do to help us combat that threat online. So we all know what phishing is, right? It's when some deceptive third party steals your username, your password, and other login credentials. Google has run a study a while back. And we found that about 43% of users in this day and age still falls for phishing scams. So about one in two people today, if you present them with a well-crafted, I guess, illegitimate-like website that looks the same as any other that they are suspecting to ask them for credentials, that user will actually fall victim and reveal their credentials to this third party. And I mean, just to kind of reiterate here, three-quarters of account vulnerabilities were due to weak or solid passwords. And we saw that in a Verizon data breach report recently. So phishing, really, big problem. And we need to do something about that. As an industry, we haven't done nothing, right? We came up with something called multi-factor authentication to try and address this problem. Basically, the way that it works, I'm sure all of you know. I have a username, I have a password. What we're doing here is we are adding another factor to the equation when you're trying to log in. With a password, I normally have to give away something that I know. With multi-factor, I'm adding something else. I'm adding something that I have, something that I physically possess. That can be, you know, access to a phone number. So SMS voice is a very standard. We have doing multi-factor authentication. I try to log in. Someone sends me a text to my phone number. Ideas, by virtue of having access to that phone, I can now prove that I am me. So kind of like trying to prove my possession by, you know, having access to a certain phone number. Backup codes, I don't want to talk about that too much. It's another option you have. Print a couple of codes. Keep it in your wallet and use them when you log in. Not use that often. However, Authenticator, Google Authenticator and other OTP-like solutions, a pretty standard way of trying to do or implement multi-factor authentication, again, proving possession of a phone or another device, like a hardware key fob or something like that. Mobile push is very, I guess, popular these days among services. So when you try to sign in at the point in time when you've typed your username and password, you get a push message on your phone. You have to say yes. And at that point, you're signed in. Proving possession, again, of a mobile phone. Problem with all of these factors are, they are all susceptible to phishing, right? If you are a sophisticated attacker and you can trick a user into revealing their username and their password, you can most likely trick them into giving away their OTP. You can most likely trick them into pressing yes on their phone, accidentally signing you as the bad guy and not the correct user's device. And we've seen that many times. There's many services online available, two hackers. One of the most popular ones that you can download and play with yourself is Evil Engine X. A nice little project on GitHub, which you can install. And then you can man in the middle pretty much any site. Of course, the challenge here is these things are not sophisticated. Or sorry, you don't need to be sophisticated to set these things up any longer, right? It's pretty much, you know, run them all, download the source code and the way you go. So what we try to come up with as an industry here is we try to come up with something better than these solutions. We try to come up with something that actually, you know, helps defeat phishing. And the technology here that Google and a bunch of others in industry have worked together since 2012, 2013 is the FIDO security key protocol. How many here have heard of security keys in FIDO before this talk? Oh, great. OK, fantastic. So some of this stuff will be old news to you. But essentially, the FIDO protocol helps the web server understand whether a user is interacting with a legitimate or a non-legitimate website. Basically, the web origin, so where you're actually on your browser, gets encoded into the signature that the key produces and sends back to the website. That's essentially the way that this works. We're not going to get into too much detail on the FIDO security key protocol in this talk. So kind of anything onwards from FIDO security keys, the world that we're entering here is what we call kind of the world of phishing resistance. When users use these technologies, they are able to help us prevent phishing. Google introduced something last year where one of a number of companies producing a hardware device that implements the FIDO protocols. We introduced something called the Titan Security Key. Many vendors make something similar. FIDO is an open protocol. Any vendor can produce keys compatible with the FIDO protocol that adheres to the standard. And a number of websites online have since adopted support for security keys. Google, of course, being one. Facebook, Salesforce, Dropbox, GitHub, a whole bunch of websites have actually said, yes, we want to offer our users additional protection. Problem with all of this is we need our users to carry around yet another device. Certainly for users that are under threat, maybe the trade-off is something that makes sense. But we wanted to do something even better. We wanted to say, well, users already have something in their pocket most of the time, mobile phone. What can we do to implement the same protocol that prevents or help prevent or stop phishing? What can we do to implement that protocol into a device that users already carry around with them wherever they go? And I guess about two and a half weeks ago, we launched something called the security key built into your Android device. So basically, all this does is the same protocol that makes phishing resistance possible in FIDO is now implemented in your phone. Something that you need for phishing resistance to work is you need a local communication channel between your device you're signing in on and the thing that the proof is the sign-in. That's the thing that really what makes a difference between all of the other multi-factor protocols out there and security keys. A security key is something you plug into your USB port or something you tap on the back of your phone using near-field communications or that you communicate over using BLE. What we've done here with the Android phone is we've implemented the same protocols directly in Android. And we used Bluetooth to establish a local communication channel between your laptop or your desktop and your mobile device. So just one more thing that we've kind of came out with to make things easier for our users to keep their account safe. Right now, it only works on Google accounts, but of course, the intent here is since this is part of the standardized FIDO and WebLine protocols, which we'll talk more about, the idea is to open that up to third parties pretty soon as well so you can implement that. Now, with that being said, what is it that we're actually here to talk about that you guys can do today as developers? So I want to talk a little bit about the W3C and FIDO alliance and just for the folks that don't know how these things fit together, just explain that very, very briefly. We have kind of two industry bodies here that's working together to try and address this problem of phishing on the web. We have the FIDO alliance, which is pretty much the alliance where kind of all of this started. A bunch of companies came together, Google, Microsoft, a bunch of others in order to try and solve this phishing problem. That happened in the FIDO alliance. We got to a point where the technology was pretty stable. It was implemented in Chrome and some other browsers. And then we said, well, now we want to make it available to the web at large. So we took the protocols to the W3C, the World Wide Web Consortium. And I'm happy to announce at this point that we have a candidate recommendation, oh, sorry, a post recommendation, of the W3C web open protocols available today that not only Chrome implemented, but also some other browsers out there such as Edge and Firefox. So that's basically a bit of background on the way that these two industry bodies work together. A better, I guess, overview explanation here is you might have heard the term FIDO2. FIDO2 is the name that we used to refer to this kind of set of standards. On the one hand, you have the W3C web open standard. That is the JavaScript communication protocol, essentially, that you use between a web server and the browser. So if you're a web developer, that's pretty much the standard that's important to you here. And we'll look at a little bit of code later to see how easy it is to use that. And then there's the standard that we're working on in the FIDO Alliance, which is less important, I think, for the group here, unless you want to actually get into making USB or Bluetooth key fobs, which certainly you could do. The standard is in the open. But essentially, we've kind of abstracted that away from web developers. So that I need to understand the actual bits and bytes that goes over the wire or over the air on the left-hand side here. Something else that I really want to focus on today is that middle piece there. So yes, you can talk using Web of End to the browser, the client, the computer, or the phone, and then that device can, in turn, flop around and talk to a security key. But you can actually also talk to bolt-in sensors on devices. And pretty much all devices nowadays, especially mobile devices, implement secure key storage and implement some form of biometric sensing. For a long while, that biometric capabilities, as well as the key stores, have not been made available to the web. They were available to native developers, if you want to use the fingerprint scanner in an app. That's cool. You can do it. However, if you're coming from the web, that was simply not available to you. We wanted to solve that problem with Web of End as well. And in a couple of slides here, I'll talk a little bit about how we've done that and how that's now available to US developers to use. So before we talk about that, let's just quickly talk about authentication in general. The way that I think about authentication and the way that I've tried to portray this in the slide deck here is that, typically, there's two separate use cases for authentication. There might be more, but for the purposes of your, there's two main sets. Set number one is when a user goes to a web property or to an app for the very, very first time. At that point in time, the goal of the web server or the application server is to figure out if this is the rightful user amongst everyone else on the web, right? So this is what we call bootstrapping. I need to provide my username. I need to provide my password. I might need to provide a second factor. That's when the website needs to kind of falter out everyone else that could potentially try and get into this user. Maybe it's someone who fished credentials, we don't know, and try to log the user in. So that's normally a pretty heavy process. Then we have a second user journey here, which is I've already logged in successfully to a website at some point in time or to an app. All the app is now trying to do is to figure out on this particular device whether it's the right user coming back to the app. Is it me, or is it my friend, or is it someone that just picked up my phone off the floor somewhere? So problem number one is trying to figure out amongst everyone else in the world if this is the right user trying to log into this app. And problem number two is slightly easier. That one is saying, well, I already have restricted everything down to this one single device. At this point in time, who is the actual user trying to come back to this app or service that I've already authenticated into? Many services don't care about the second part. Mostly Google does not. If you've signed into Google on a machine already, you can come back next week. We'll still allow you to come back to the service, right? Banking websites, financial services, payments, they really care about problem number two, right? If you open up the banking website again that you've logged into yesterday, probably gonna ask you to kind of re-establish your identity. So problem number one is the one that traditionally we have tried to solve using multi-factor. And that's where security keys, of course, make a huge difference in terms of phishing resistance. But problem number two is the one that we've solved so far in the app world with biometrics from a convenience standpoint. And that's where we can also apply WebAlthen. Yes, WebAlthen applies to number one. We all know that. We all know we can use security keys to make kind of protect apps against phishing. But what I wanna talk about today is specifically use case number two. How can we make it easy for returning users to our application or our web service to get back into our service without having to subject them to re-entering passwords, right? That's kind of the old way of doing things. Today, we can move to biometrics. So that's really what I wanna talk a little bit about because WebAlthen really does solve both of these use cases. So before we get into some code samples here, let's talk a little bit about the implementation and how this works on Android. So as you know, on Android today, if you have an app, app has myriad of choices, right? The app can directly talk to Keymaster in terms of key storage. An app can directly talk to biometrics, right? With biometric prompt API, you can do some pretty advanced things with biometrics on the phone. We have introduced one more choice, one more option for applications on Android. That option is called the FIDO module. And of course, not only does an application have access to the FIDO module, the important thing is Chrome also have access to that FIDO module via the WebAlthen APIs. So this finally gives us parity between applications and web services and websites running on the platform because both of these can talk to the FIDO module and do some pretty nifty things. And we'll look at what those mean in a second. So again, as an app, you have the choice to still communicate directly to Keymaster and biometrics. But what I'd like to convince you here, although this session isn't really about Android native app development, is to start thinking about migrating the use of Keymaster and biometrics inside Android apps if you're responsible for an Android app over to the FIDO APIs, because it gives you some unique benefits, which we'll talk about in another couple of slides here. One thing that I just want to note at this point again is remember, at no point in time does Google or the web service or anything other than the device itself ever get access to the biometric templates, right? These are always stored directly on the device. The only thing that your web server, the remote server, get access to is a proof that a certain Key was available on the device. If you think about this and you'll see this in the code samples here in a second, there is a separate registration step and then there's an authentication step. When you register, we're generating a new public-private key pair, we're putting the private key inside Keymaster, and we're kind of protecting the key with the biometric on the phone. So later on, if your web server needs to have a proof that the same user is at the phone, they will touch their fingerprint, that'll unlock a key, sign a certain piece of data, and send the proof back to the web server. So not only is it completely privacy-preserving as it should be, we're also using asymmetric crypto here, which means the stuff that we hear about pretty much every day now about data breaches and things happening on the server side, this doesn't really affect authentication based on the FIDO module that uses asymmetric authentication because the thing that the server has can't ever be used to spoof a user. The server has the public key that can be used to prove a user was there and had a correct private key, but it can't actually be used to authenticate or masquerade as the user, which is also pretty important, but that's just part of the modern authentication-based practices, asymmetricals. So let's shift gears a little bit and talk through a couple of user journeys. What I want to talk about here is we have someone here called Eliza, and Eliza wants to do a couple of things, and I want to show you the first couple of slides here will be very standard stuff that you've seen on the Android platform for a long time, and then we want to see how we can change things slightly to make it easier for our users to do things like real authentication. So let's walk through an easy example here. So Eliza wants to sign into her bank, something that most of us want to do on our mobile phone. She starts on her mobile browser, and the cool thing here is what we can do with Web of Then is she can then roll a fingerprint directly in the mobile browser and use that to get back to that mobile website later on in another example. So let's look at this. This is the standard part. Open up tribank.com, fictitious bank here. Click sign in. We all know this, type in the username, type in the password, pretty straightforward. This is the day zero bootstrapping scenario. The very first time she comes to this website on this particular device. Cool thing here is once she's done that, suddenly tribank presents her with an interstitial, and we'll see how that's possible in a second here. Web of Then has a discovery mechanism whereby you can figure out whether the platform that you're interacting with has these capabilities built in at this point in time. That'll only return true, essentially, if the device is capable of doing biometric authentication at this point in time on the web, and if that happens, you can present a nice interstitial that tells the user about this functionality. So that's what we're doing here. We're saying, hey, mobile banking is not just one touch away. Do you want to enable fingerprint? Of course, Eliza clicks yes. She wants to enable fingerprint. That then talks down to the biometrics creating a new public-private key-keeper, sending the public key to tribank, and they now have that on file. So what's really cool here, if we look at the code, what happened, that super long, I guess, function call there, ease user verifying platform authenticator available is what tribank used on their website to determine whether a biometric capability was present on this phone at this point in time. That'll only return true, by the way, if Eliza actually had her phone set up with a fingerprint and everything beforehand. So you get back true, and then you know, hey, I can render this special experience for my user to opt into this mechanism. And then, way both end, it's very, very straightforward. Really, only two calls you need to be concerned with. The first one is create. That says, make me a new public-private key-keeper and give me back the public key so I can keep it on file. And then later on, we'll look at the other call, which is called get, which is, hey, I now want to authenticate. So basically, all you need to do is create. Of course, you need to pass in a couple of options. What does those look like? Pretty straightforward here. Something called exclude credentials. Don't have to be concerned with that too much. Essentially, that just means if Eliza actually already have her fingerprint and her keys registered on this device, don't register them again. Just let us know if that's the case. So that's what exclude credentials mean. And then we can say a couple of things. What type of authenticator do I want? As I said earlier, for a call, we have multiple use cases for WebOthen. One is using an external security key during bootstrapping. The other one is using a built-in authenticator for reauthentication. Here, we're concerned with the reauthentication and built-in authenticators. So we are explicitly saying, give me a platform. That means built-in authenticator. Don't bother the user with questions about external security keys. They don't want to do that. I just want a biometric that's built into the platform, which is why we say platform. And then lastly, I already kind of said biometric. The last option here is, I need the user to verify their identity before releasing the signature in the future. That means I actually need the user to touch their fingerprint on a sensor, as opposed to just clicking on a prompt saying yes. So I want the user's identity to be confirmed before releasing a signature, which is what the last option there is all about. So now Eliza comes back. That's probably, as we would expect, that's the second part of this journey. She registered her fingerprint at some point in time. Now she comes back to try back. Clicks on sign-in. Don't have to type a username. Don't have to type a password. All she does is presses her fingerprint on the sensor, and she is magically logged in. Now let's look at what happened there. Pretty straightforward. All we had to do here is issue a get call. Get says, hey, get me a signature. Again, you need to pass stuff in. Basically, you pass in a identifier that you got back when you created the credential in the first place. And again, you say, hey, at this time, please verify that the user is there, which basically tells the system to bring up a fingerprint prompt, as opposed to just a simple yes, no. So very, very straightforward. Three calls that we discussed here, right? The first one is user verifying platform authenticator available, or is UVPAA for short. That tells us whether the capability is available. Then we created a credential, and then at the point in time when we want to authenticate, we did the get. And all of this was already available, of course, to native applications. Although you had to kind of bold these capabilities up yourself, right? There's different ways in which you can bind the fingerprint and bind it to a certain key that you've put in key store. Developers had to bold all of that themselves. What we're doing here is we are giving you a standardized way on the web to actually communicate with these key stores and biometric components and give you back standardized signatures that you can use to validate. And of course, the last thing that we're going to look at here is, what about native applications? What if I want to use this great capabilities directly inside a native application? Yes, I can do that already today. But it comes with a little bit of pain, right? It comes with you basically building all of these capabilities yourself. The cool thing about integrating these capabilities into your mobile application as well as, for the first time now, there's context sharing happening between the web and the app. Remember that credential we just created on the web when we said, make this fingerprint credential, make me a new key pair? That same key pair will be accessible to the mobile application when Eliza moved there. How does that work? Well, let's look at that. So Eliza goes to the tri-bank application on the app store because she's tired of using the web experience, clicks Install, opens up the app. At this point, the experience I have depicted here is she clicks Sign In and types her username. At that point, the server can realize, oh yeah, this Eliza person that's trying to log in, I already have a credential for her on this particular mobile device. And suddenly, a fingerprint prompt appears, no password needed, no second factor needed. I just touched my fingerprint because I'm accessing the same credential that I created a while ago on the web component. How does this work? How is this possible? We use something called Asset Links. If you're familiar with some of our other technologies where we can directly get access to credentials and other things, Asset Links is a way to tie and prove ownership between a website and the mobile application. This is all documented later on. There will be some URLs, Asset Links in the process here that you need to follow is all documented on the website, so it's pretty straightforward. But essentially, as a developer, you prove ownership of both the application and the website, and that then allows you to share credentials and state between the two. So no longer do you have to log into the website and to the mobile app. Once you've bootstrapped the one, the other one can kind of just hang off it because the context and the authentication context here is both shared. If we go back to that earlier picture that we had, the key store and the biometric component is shared, the phyto module sits on top, and both the web and the apps can talk to that exact same phyto module and get access to the same underlying credentials, which is very important here. What happened behind the scenes? Of course, this is in JavaScript, but it's very, very similar, right? Again, we're doing here something called get, right? We do get, here it's a get sign intent. Again, we're passing options, exactly the same options. We're passing the credentials, the credential ID, essentially, the handle of the credential we want to use. We got that back when the user tried to log in using a certain username. The server came back with a list of credentials for Eliza, and again, we say, we want to do user verification. We want the fingerprint prompt to actually appear. That's what we passed in there, and at that point, the phyto module took over and sent back a signature that can be validated by the web server at the back end. So, let me quickly highlight two case studies here. We have had this capability out for the last couple of months. We just recently revamped our documentation. So, if you have taken a look at that before, please take a look at it again. Folks, you did a great job at actually making that really easy to understand both on the web and on the mobile side. Yahoo Japan implemented reauthentication using this fingerprint mechanism, and they were able to reduce their time to sign in by 37.5% compared to that of a password. So, certainly a big user experience improvement, just helping users save time, right? Pretty straightforward there. At Google, as maybe you've seen in the web keynote this morning, we have also implemented this on passwords.google.com. We're in the process of rolling that out. We've got a little bit more info on here. We found that 98% of biometric reauth users finish their authentication in 38 seconds versus 98% of users who finish entering passwords in 150 seconds. That's really, really significant if you think about it. Not only that, if you look at the graph down there, what's really interesting here is that essentially the success rate from reauthenticating using a password at 65% bumped up all the way to 89% when you're using biometrics. And it's a very, very straightforward why, right? The big red piece disappeared. What is the red piece? It's users entering the incorrect password. That disappeared when you're moving over to biometrics because there's nothing that you have to remember. And remember, most of the time when users reauthenticate and can't enter the right password, it's not because it's the wrong user at the system. It's just that the user can't remember their password, right? So you're locking out the legitimate user, kind of like making things easier and making it more reliable for the user to get back into the system. So essentially the 23% disappeared, which is why we're almost at 90% success rate. So we think that's very, very important. So with that, I would like to invite Emily back up on stage to do the wrap up for us. All right, so at the beginning of the talk, we told you that passwords aren't enough to protect your account security and that the risk of account hijacking increases by 500 times if you got phished. But now we've showed you how Chrome's built-in phishing protection with safe browsing can help, and we've showed you how security keys can help. In fact, here at Google, there has never been a successful phishing attempt on a Googler since we implemented security keys. Users hate passwords, right? So you owe it to them to implement WebAuthn to enhance security and usability. So when you guys leave I.O. and return to your laptops, here's your checklist to get started. Get a Fido server, implement WebAuthn, create and get. And if you want, link it with your Android app for a seamless login experience. And if you're interested in learning more, you can swing by the web sandbox area or you can come find us outside or up here after the talk, and we'd be happy to answer any questions. Thank you.