 In theory, the URL bar that's shown at the top of a web browser is your unambiguous clue to website identity. If the URL bar says Google.com, you're at the real Google. But in practice, it's not always so easy to tell site identity from a domain. In a study that we did with over 1,000 participants, we showed users a browser window where the website looked like a Google login page, but the address bar said tinyurl.com. When asked to identify this website, over 85% of participants said the website was Google. We're approaching this problem from a few angles. First, we're actively combating sophisticated spoofing techniques that abuse URLs to create unusually deceptive attacks. Second, we're trying to draw people's attention to the information in URLs that's most relevant for making security decisions. And finally, we're building specialized tools to support expert use cases so that we can help make URLs better security tools without interfering with experts' workflows. People should be able to browse the web without worrying that someone is collecting a dossier on them for what they're doing, and developers should be able to build sites without worrying that their infrastructure is compromising their users' interests. Third parties may want to answer some very natural and non-personal questions, things like how many different people saw my ad, or how often do the people who click on these ads actually buy something? Answering all these questions today relies on a really powerful capability, global cross-site identity. And this is what can also be used to knit your browsing behavior together into a user profile. So once we've invented new ways for the web to flourish, ways that don't rely on tracking, recognizing users across sites has historically been based on third-party cookies. But as browsers have restricted access to those cookies, we've seen them replaced with other mechanisms, covert browser storage, device fingerprinting. Those covert tracking techniques are a real problem. If the web platform forces you to use high entropy fingerprinting surfaces to perform mundane tasks like checking for emoji support, that's a problem that we need to fix. And then we want Chrome to notice it and stop it when a website is abusing a bunch of unrelated high entropy content APIs as a way to fingerprint you. Our privacy budget explainer describes the multi-step process that we're working on. Starting in Chrome M80, that's three months from now, if you set a cookie the way you've probably been doing it since the dawn of the web, that cookie will be available only in a first-party context. If you want that cookie when you're a third-party, you need to do something new. If you want a cookie available when you're a third-party, you will need to explicitly set it with the attributes same site equals none and secure. And there are a lot of online services that heavily rely on phone numbers, especially as a way to send SMS text messages. These services are using SMS to let users sign up, help users recover their accounts, increase user security with two-step verification, or confirm payments. That's why we are proposing a new API called SMS receiver API. Web developers can use the SMS receiver API to let the browser receive the SMS message, extract the OTP, and enter the OTP on behalf of the user. Before the website can receive an SMS, you have to know the user's phone number so that you can send a message. If you are using an input tag, my recommendation is to use auto-complete equal tell. That way, the browser can help the user outfill their phone number. When an SMS is received and meets all the conditions, a bottom sheet appears in the browser, and the user can grant the browser permission to access the text message. This permission is required for every receipt of a new message. This means the browser won't be able to read SMS messages without the user's explicit permission. To learn more about the SMS receiver API, please go to Google slash SMS receiver API. In the previous session, Emily showed you how Chrome tries to ensure that user is on the genuine site. Web often allows you to provide an extra layer of safety for users because the keeper is bound to the website's origin. Even if a user ends up on a phishing website, that phishing website will not be able to make the user generate a valid signature. Now, I would like to talk about two primary user experiences using web often. There are two factor authentication and reauthentication. So how effective are second factors? Here's a comparison between SMS ODP as a second factor and security key as a second factor. As you can see, SMS ODP is not perfect against targeted attacks while security key protect users completely. Platform authenticators are more consumer-friendly than roaming authenticator or security keys because you don't have to purchase a separate device. You don't have to worry about carrying it around and they are a part of device you use every day.