 Hi, everyone. My name is Elizabeth Morant. It's not that hard. And I am a product manager on Chrome where I work on security. So today, you've heard about a few new web APIs, like notifications and Bluetooth, that allow you to make amazing web experiences that are more engaging than ever before. And Owen alluded to this example earlier. Beyond the Rack recently implemented push notifications, which resulted in a 20% CTR. So 20% of these notifications users actually click through. And of those users who are visiting beyond the rack through notifications, the site is getting a 26% bump in revenue. This is huge. Notifications and other permissions, and other APIs like it, allow developers to create new levels of engagement. But in order for users to actually take advantage of these features when implemented on your site, they actually have to say yes first. They have to give you permission. So to set a baseline, what do you think is the opt-in rate for geolocation on the web? Now this number is specifically Chrome for Android, 28 days on a certain milestone. It's of every time that we show the Infobar, what percentage say yes? Someone said zero. Well, that is pessimistic. What, 20%? 25? Well, we're pretty close to that three number. Our opt-in rate today is 6%. And so we have a few guesses as to why this opt-in rate is so low. And our biggest bet is it's because sites are asking for this permission at the wrong time. And now this isn't your fault. This isn't the developer's fault. The geolocation API is built in such a way that in order to query whether a site actually has the geolocation permission, the site has to actually request it first. And so there's no way to check without annoying a user with a prompt. And so one of the things I'm going to be talking about today is how to use the permissions API, which is a new standards API that allows developers to ask for permission, not just geolocation, but any permission at the right time. And to round it out, the opt-in rate for notifications is a little bit better at 17%, but still, we can do better. So we've seen examples of runtime permissions models in the wild that work really well. So an example of this is iOS. There are certain apps on iOS that just ask for permission in a really respectful way. So this is a set of screenshots from the iOS Google Photos app. And during the install flow, they show an interstitial saying, get notifications. And they don't just immediately show the system prompt saying, you should opt in to get notifications from your cool photos app. Instead, they give you a reason why. And the reason being, they're going to do some magic in the background with all your photos. And then after a while, at random points in time, they're going to create awesome videos and then let you know when they've presented you with this gift. And so every notification is basically like a present. So I opted in to getting notifications. And so did 88% of users who saw the system prompt to opt into notifications. And now this is smart for another reason too. Not only does it manage user expectation, but it also means if the user doesn't hit Turn On in the app UI at this moment in time, the app still has the ability to ask for this permission again later when it's had time to prove value. And so this is iOS, but we've also seen good examples of this implemented on the web. The Financial Times recently launched a new version of their site where they send you notifications when exciting news happens on topics that you care about. And so the idea is that you switch notifications to on and then you can choose different categories that you want to know more about, like arts and entertainment or world news. And then the Financial Times will send you a notification when something interesting happens in that space. And with this UI, because they explain the value and they act on the promise that they display in this flow, they have a 90% retention rate. So of all the users who opt in to receiving notifications for the Financial Times, only one in 10 end up provoking the permission later on. So we all know, especially now, that not every user is going to say yes to a permission when you request it. So why do we have them at all? Why don't we just let any developer or any app use whatever API they want? Well, this is for two reasons. The first is usability, giving users control over what sites can do and can't do with their data. And the second reason is for security. I'm going to walk through examples demonstrating both. So say that you use Gmail or Twitter on the web. These are good examples of sites that you engage with pretty regularly. Daily, if you're on Twitter during the summit, probably pretty regularly during the day. And for that reason, when you open the site, it's really nice when you have all the content preloaded. And so native apps do this today. You open up Gmail, and all your inbox is refreshed, or you open up Twitter, and your feed is refreshed because they have Background Sync. And Background Sync is an API that we're working on for 2016. And it works great for these two cases. But Background Sync is not a fit for every site that you visit on the web. And as we learned from Darren earlier, people average around 100 different sites a month. So imagine if every single site you visit has access to Background Sync. Well, then your phone would functionally be a brick because you would run out of battery pretty quickly. So that's one reason why we have permission prompts, is that users can have control over what sites can and can't use given APIs. So the second reason, and probably the most significant reason why we have these permission prompts, is for security. So say that these 100 sites that you visit every month all get access to your camera. That's a pretty fast track towards a dystopian future. The movie writes itself. And so it's really important that we give users control to grant camera or other sensitive APIs to those websites that they implicitly trust. And this is also the reason why we're deprecating the support for powerful capabilities over insecure origins. So starting in version 47 of Chrome, sites that are served over HTTP no longer can request a camera or a mic. And likewise, we're planning to impose the same restriction for geolocation later next year. And all new APIs, like notifications and others coming soon, have a strict HTTPS only requirement. And the reason for this is because even if you have the most trustworthy site in the universe, like you are the best arbiter of sensitive data, if you serve your site over HTTP, then you lose all guarantee of security for that user's data, right? Like, I could be accessing your site in a Starbucks. And just because I trust you to handle all the photos I'm sending you over the connection, it doesn't necessarily mean I want everyone in Starbucks to see the photos that I'm sending using camera on your site. And likewise, HTTPS is important, as Emily alluded to earlier, for preserving the integrity of your site. So without HTTPS, there is no guarantee that I know, oh, sorry, I know who I'm talking to. And there's no guarantee that you can prove it to me. So permissions are great, and they're here to stay. So how do you actually build an app that asks for permissions in such a way that users say yes? So for the purpose of this talk, I am working on a demo app. And the premise is simple. If you live in the Bay Area, then you probably know that there are two types of weather. There is sweater weather. And then on the rare occasion, there is t-shirt weather. And because of the rare occasions when you got to wear a t-shirt because it's so hot, every morning you have to wake up and you're like, look out your window or check the weather and just confirm that what you're wearing is fine. So I made an app that eliminates that friction. It's pretty simple. You just go onto the site. It's one page. It tells you whether you should wear a sweater or not. You opt in to giving me a location and whether you want to get notifications. And if you give the site both, then every morning it does a check and it sees if it's above a certain threshold to be t-shirt weather. And on those rare occasions when you want to wear a t-shirt, it will send you a notification. So I mentioned I'm working on the site. So it's worth mentioning that I have all the permission stuff down. The notifications won't actually send, but you should totally opt in anyway, improve our global opt-in rates. But you can play with it and see how to ask for permission. And that's really what the demo is for. And I'm working on finishing it up soon. Second thing to note is that for this app to work, I'm using a couple of features in the Permissions API that haven't actually been fully released yet. And so the Permissions API is an open standards API implemented by Chrome and Opera. And there are just certain features, which I'll call out during the talk, which are only available if you are visiting the site on Canary or Dev and if you have this flag flipped on. So the purpose of this demo is to show you some principles to follow when requesting permissions on your site. So I'm going to walk through five key principles. The first is communicate intent and provide clear value. So when you're requesting notifications, say, it's really important to say exactly what you're going to be bothering the user with. So in my example, I say notify me when it's T-shirt weather. It's very clear that the only time the user is going to get bothered is when I actually have something meaningful to share. And I know that I personally, as a user, I am very stringent with granting notification privileges apps. There are some messaging apps I don't even give permissions to. And so explaining exactly how it's going to be used is super important. And so you can imagine I could have said something like send me notifications, and it would likely get a far fewer user saying yes or tackling it on. And the second subpoint here is images are always going to be better than words. And this is because images localize better. If you're trying to have it, if you have an app and you want it to work cross locale, it's much easier to communicate value through user experience or through images rather than actual text. And so here, for location, I use this location icon that's shared with a number of other location-focused apps like Maps. It's also important because even if your app is in a language that the user speaks, people don't always read the manual. People like to play with things. And so the quicker you can get to communicating intent without actually using words, the more likely a user is going to understand how your app works and whether they should opt in or not. Second principle is ask at the right time. So Owen mentioned this. I mentioned it earlier with geolocation. The absolute worst time to ask for permission is on load. And now you don't have to do that anymore. The permissions API allows you to query for permission state at any time. So let's just stop doing this. Better practice is to ask on user gesture. So if you give the user an affordance and ability to indicate that they actually want to use a permission or use an API, then that's the right time to ask for permission. You can imagine an example of this being like a camera app where you take a photo and then you add some effect to it. A good time to ask for permission in that example would be when the user tries to take a photo because you know they really want your site to have access to the camera. In my example, for notifications, I use the switch of the toggle as that user gesture, the indication that a user wants notifications. So the way I do this is I just add an event listener to detect when the toggle state has changed. So if the toggle is switched on, then I request notifications and when a user toggles it back off, I revoke. Third principle is only ask for what you need. So say you have this amazing camera app. Well, just because you can ask for every permission that's available or every API that's available on the web doesn't necessarily mean you should. Your camera app probably doesn't need Bluetooth. It probably doesn't need notifications unless there is real reason for you to have it. That being said, we do make it pretty easy for you to bundle permissions requests. And so one of the new features of the permissions API is this ability to request all. And so there are some points where it's absolutely appropriate for you to ask for multiple APIs at the same time. So the example I have pictured here is there's a button that says, notify me when I'm near coffee. In this case, it makes sense. You do need to give up your location and the notifications permission so that the app can tell you when you are near your closest Starbucks or whatever. That being said, do not take APIs hostage. So it would not be appropriate for me, in this case, to add Bluetooth as a permission request just for the sake of it. And the reason for this is because I haven't communicated in my app what I'm using Bluetooth for. And it lands users into this weird state of confusion where not only do they not know why you're asking for this third permission, but they also now don't know if you're not being totally honest with what you're using the first two for. So what you request should map what your UI communicates. Fourth principle. Oh, sorry. This is what it looks like. It's pretty simple. You just add the parameters for the permissions you want to request, user request all. That's it. Fourth principle is give users control. So in a world of progressive web apps where users are adding your website to their home screen and they open it up in full screen as a service worker, where do users actually manage permissions with no Chrome UI? Today it's pretty simple. If you have the URL and you hit the overflow menu and you go into permissions, and that's where you do all your management. But in this world, it's not as clear. And so that's why if you have one of these awesome full screen apps, you should give users an ability to manage the permissions in the app itself. And so in my app, I use the toggle and the location icon to allow users not only to indicate that they want a permission, but also indicate when they don't want it anymore. And I do this with revoke, which is another experimental feature. And so this is the code snippet from the first example where I waited until the toggle was checked. And what it does is if the toggle's in the checks position, then it requests notifications. And if it's in the unchecked position, then I just revoke. And last principle is handle failure gracefully. So the absolute worst thing you can do when a user goes in and manually revokes a permission or doesn't give it to you in the first place is to crash. And the second worst thing to do is to not communicate what's happening. And so in my app, what I do is if a user changes a permission state, then the UI updates accordingly to communicate why something might not be working. So in this case, if the idea is that the app would default back to set location, and if this isn't updated to your location, you see that you've declined the location permission, which means that it's not updated to your location, like Minnesota or wherever. So you want to design for resilience, so that when users go in and do wonky things that you're not expecting or you don't want, your site should continue to work and communicate why it might be behaving differently. And so what I do here for the location example is I query for the state of geolocation permission using the permissions API. And then when that state changes, I update the UI and I update the functionality of the app to reflect the new state of the permission. If the geolocation permission is denied, either through the UI or through Chrome Settings, I disable the button and I fall back to default location. Likewise, if a user goes back to the ask defaults, then I enable the button and fall back to default. And then if the state is granted, then I enable the button. It's big and blue and I query for the current location. So taken together, when asking for permission, you should provide clear value, ask at the right time, only ask for what you need, give users control, and handle failure gracefully. And now there's clear incentive for you to do this on your own site. It enables users to know what you're using your given APIs for and it just creates a better experience overall. But I'm going to add two additional incentives for why it's wise to follow these principles. And the first is Chrome is working on a way to moderate the abuse of certain APIs on the web. So we don't have an app store. We can't take down sites. But what we can do is monitor and make sure that they're being used effectively. And so we're still thinking about it. It's still mostly conversation at this point. But we're hoping to create some sort of policy for abuse on the web. And now this isn't the first platform that's thought about this. Facebook actually does a really great job of managing abuse of notifications on their own app platform. And so if you're a developer and you send over 50,000 notifications a week through your Facebook app, then you have to meet a certain minimum threshold of 17% CTR in order to continue having the full functionality of your app. And this is a great example of how platforms are thinking about allowing the use of these powerful features while also managing the risk of abuse and spam. And now the second incentive and the one I want to leave you with is asking for permission at the right time doesn't only help you, but it helps the web ecosystem on the whole. So what you're seeing here is we did an analysis on a small subset of Chrome users to see the effect of seeing multiple geolocation or prompts across the web on their tendency to interact with or accept a given request. And I say this is a subset because the CTR is hovering a little under 20%. And again, the total CTR is 6%. This graph in reality looks like this. So if you are more stringent with when you actually ask for permission, whether it be geolocation or other permissions, then this means that the next site that a user goes to, they're also going to be more likely to say yes there and there. And it perpetuates across a user's experience on the web at the whole. So I hope this was educational. And you're excited to use the permissions API. If you want to get your hands dirty, we have a code lab available. It's at the bottom of the code labs on the CDS site. And I'll also be outside taking questions if you have them after the talk. Thanks.