 Good morning, everyone. So I lead a Chrome team whose mission is to help developers better understand and control the web platform. So we've been working on feature policy and reporting API, which we think can really make your lives easier as web developers. Maybe we won't save you from speeding tickets, like Nicole said, but we'll see what we can do. So we know there's many benefits to being on the web, but as a development platform, it's far from perfect. On the Chrome team, we regularly provide web consults to help people address issues with their site. Now, these consults bring together developer relations, engineering, and other folks to help people deep dive into questions or issues with their site. Now, the goal is to provide actionable recommendations to improve things. Now, as a result, we've identified common mistakes that happen over and over again. And spoiler alert, performance is a common theme here. And the two big performance problems we see are too much script and too many image bytes being sent over the network. So you know there's a right way to do things, but it's adventure to find that sometimes. And even if you find the right way, there's bumps, or you might slip off the path. So as we've seen in other talks, there's a long list of things to keep track of and get right. Now, this is hard enough if you're an expert developer, but imagine you have a dev team with junior developers and you need to keep everyone on the same page. So we need help. What if we could make web development easier with guardrails? So if you imagine guardrails along a path, if you hit a rail, you know you're doing something wrong. And the rails stop you from leaving the path. Now, this isn't necessarily a new idea, but looking at repeated mistakes in our web consults, we're thinking about different ways to apply this. Concretely, how could we help you put guardrails in place for development? So AMP gives us examples, an example of guardrails and web development. AMP gives guarantees you're not going to veer off course by making it nearly impossible to do things wrong. Now, AMP started by providing building blocks, tightly constrained to ensure great performance in UX. So this is an opinionated approach to carve off good parts of the web platform. Now, not everyone can or wants to use AMP. So learning from AMP, we thought about a more configurable approach. And that's feature policy. So we're really excited about it. We think it's going to be great to help guide you towards the well-lit path of web development. Now, with feature policy, you opt into a set of policies for the browser to enforce throughout your site. These policies restrict which features the site can access or modify the browser's default behavior for certain features. So let's talk through some of the common problems we've seen. So images often have extra quality or metadata that take up space, but isn't required. Now, as we've seen in other talks, again, there's many tools to optimize images. We have to remember to use them. Or you have to integrate them into your build pipeline. Now, ideally, your page should never serve images that are larger than the version that's rendered on screen. Anything larger just results in wasted bytes and slows down page load time. So a common example might be sending a desktop-sized hero image to a mobile device. We've designed policies to catch common mistakes of unoptimized or oversized images. So we researched the impact that we think these policies can have on 10,000 most popular sites. Our analysis shows that 10% of sites can save over 500 kilobytes on average. Now, that can reduce load time by up to three seconds, sorry, 10 seconds, on a 3G network. So let's take a quick look. So this shows the policies being applied to a site. Now, on the left, policy for unoptimized images is turned off. And you can see the image is loaded normal. On the right, we've turned on the policy. And it's blocked one of the images. So we compute a compression ratio of bytes to pixels. And if that ratio is greater than 0.5, we'll block the image and we'll show a placeholder. So the idea is to point out the images that need to be corrected. So this site might look familiar. You know, at Google, we're big believers in dog fooding. So we went and applied all the policies we could to the site. Lo and behold, we found out we made a few mistakes. So the unoptimized images, sorry, we applied a bunch of policies. But it was actually the oversized images policy that caught that we were sending some really images that were too big. So oops, just shows that even the experts, like a developer relations team, can make mistakes. And so we really need better tooling to help catch these kind of things. So another common problem is images without explicit sizes. Now, as we see on the left, this can cause a user experience to jump around as a browser loads in new images and resizes a page. Now, on the right, we've applied a policy to catch this. So the browser can set these images to a fixed size, and it'll keep your user experience stable. So how does this all work? Policies, like I said before, are a contract between developer and browser. We use them to inform the browser about our intent for our site. It's a set of rules for how each page should behave. Now, the browser helps keep us honest when our page tries to veer off the path by validating that it's behaving according to its stated rules. So if a page or embedded third-party content attempts to violate any of the rules, the browser will identify or block the behavior. And in some cases, it may override the behavior to provide a better user experience. All right, let's take a look at how you configure policies. Now, each policy refers to a single feature and then defines a list of origins that are allowed to use the feature. Now, with each page response, you can add this feature policy HTTP header. So in this example here, this will catch all oversized images. And this is the one that saved our bacon on the CDS site. Now, here the nine keyword means that no origin is allowed to use the feature of oversized images, disabling it entirely for your site. Now, looking at that example, you might wonder why we would say oversized images are a feature. Now, we have policies for helping you enforce best practices to ensure good performance and user experience. And the way these often work is we'll define a known bad practice as a feature, and then you use the policy to prevent it. Now, we do this for web-compatible reasons. We don't want to go ahead and break the internet by all of a sudden turning off oversized images for everyone. So we'll allow that behavior by default, and then you opt in to turn it off. Now, this header applies a policy that catches any images that are not optimized. Now, here we're making an explicit exception for our photo CDN. Now, in this case, it might be because our users expect really high-detail glossy pictures, and those don't compress well. Now, in this case, there's only one origin listed, and all origins will not be allowed. So here's an example that puts them all together. So first, we have a policy that ensures every image has explicit dimensions. So we saw this earlier preventing your user experience from jumping around. Now, second, we have a policy to selectively enable the geolocation feature. So now, we're applying this to our own origin and to our trusted maps provider. The self keyword here means the origin of the top level page. So by combining this with explicit origins, you have full control over who's allowed to use a feature. And then finally, we're allowing any origin to use autoplay. And here you see an asterisk keyword. That means essentially everyone. So by default, Chrome will only allow autoplay on same origin iframes. With this policy, we can allow cross origin iframes to play as well. So in that last example, we saw features in the more traditional sense. Well-known APIs that are exposed to the web, like geolocation, camera, full screen, autoplay. So before, we saw policies about enforcing best practices. So now, we have policies that give you granular control over the features you use. So we've probably all seen this example. You go to a site, and before you interact with the site at all, you get a pop-up to use, location, or microphone, or something like that. So with feature policy, you can lock this down to either prevent the use of the feature at all or really just dole it out to specific origins you trust. So we've talked through some examples of an HTTP header. You can also use an allow attribute to control feature policy on iframes. So now, why might you want to do this? Well, as we talked about, you can be really selective. So maybe you have one frame on your site that shows a map. You could use the allow attribute to grant the geolocation usage to that frame and on no other frames. Now, in the example we see here, this allow attribute is changing the default for the autoplay feature. Well, you'll notice if you go to generate an embed on YouTube, they're already using this in production today. So we've seen a lot of flexibility in how you can configure feature policy. So we've built in some rules to make sure they're being applied correctly. So Malty and the keynote talk rather enthusiastically about not using SyncxHR. And yes, we do have a policy for that. And AMP is using that in production. So the way the rules apply is first, policies are inherited. So scripts will inherit the policy of their containing frame. So this means that for your top level scripts, they'll inherit the policies of the main document. So this means you can apply the policies at the top and they cascade down to all nested subframes. So in AMP's case, they can set the policy to disable SyncxHR and know that it will be applied to all subframes regardless of how far they might be nested. And this applies to the allow attribute as well. So if you have an allow attribute and you have a header, the stricter of the poo policies wins. Now on the other hand, we have this one-way toggle. So disabling a feature turns it off permanently. So that means again, in AMP's case, they've turned off the feature with the SyncxHR policy and that means no frame nested or otherwise can turn it back on. Now for policies supporting best practices, it might not be feasible for the browser to actually block the bad practice before it occurs. It can only detect the problem in some cases and then break your page in an obvious way or notify you. The goal in that case is really to let you know there's a problem to fix. Now we saw this in the policy for an optimized images and oversized images. Now in other cases, the browser can actually block the bad practice so your site continues to behave well. The policy for unsized media works this way. So it'll apply a fixed size to images to prevent, excuse me, the user experience from jumping around. So we have DevTools and Lighthouse to give you great insight into the behavior of your site. So where's feature policy fit into your development workflow? Feature policy lets you set the policies up front and then catch problems early during development before anyone writes a lot of code. Now you can build policies as defaults for new sites or new pages and this way you can enforce standards across your Dev team. Policies are served with each page and validated at runtime so you can choose to turn them on for some users and not others. You can also turn them on for some pages in your site and not others as you incrementally improve your site, for example. So at a minimum, we recommend enabling the policies on your staging server. This can let you catch problems that you didn't see during development. For example, you might have your images come from a content management system and they're not available as you're developing a site. So this can catch problems with that. In addition to staging, you can also apply policies and production. You can have your Dev team, your managers all the way up to your CEO, use your site with policies enabled so that you can find real issues in the wild. For regular production users, you likely won't enable the policies if violations will break the user experience. So for example, with the image policies, loading unoptimized images more slowly is probably a better experience than having them missing altogether. You still wanna know about all these violations so you can correct them. So we've designed report only mode to give you the best of both worlds. So you can configure policies similar to the examples we saw before, but you mark them as report only. So you see here, internal users, they have the policies enabled, right? They'll break things, we'll see problems with images that need to get corrected. For production users, we have them report only mode, so the production users get the normal experience, but then you can get reports about what's gone wrong. So speaking of reporting, feature policy violations are really just the start. There's lots of other info from the wild that would be really valuable. So for example, browser interventions. Sometimes a browser needs to intervene to improve the experience for the end user. So an example of such an intervention is blocking document.write on like 2G connections. So there, we've discovered that doing a document.write on a really slow connection can really impair the user experience. So to protect that, we've just blocked it. But that happens in the wild, you don't know about it. You really wanna find out about it so you can correct it. Now what else? So just taking a look at this, there's lots of things going on in the wild on your site that you'd really love to know about. Now a problem, some of these are just console messages which you can't collect. Now there's other things that have a bespoke API like window.onair, so you kinda have to remember to go hook up something there to get some errors. And then there's things like crashes and network errors that just aren't possible to capture from script. So the solution here is the reporting API. This gives you one place to collect all sorts of information from the wild. So one stop shot, it exposes information that wasn't available before. We've talked about network errors, crashes, now that's coming soon, feature policy violations, deprecations, interventions, and network errors. You can get those today for the reporting API. There's two ways to use the reporting. We have the reporting observer which lets you collect reports client side with a JS API. Now you can filter by report type. Here we've said we just care about deprecations and feature policy violations. And then you can use the callback to funnel these reports to your own analytics provider or however you'd like to capture them. Now because it's client side, the available types are limited, but the key feature here is it buffers results so you can set up your reporting observer later and still get reports that happened earlier in page load. So every report has some common fields. So we can see here the type of the report and the URL where the report happened. And then for each report type, there's a specific body. Now for feature policy violations, we see it's telling you the feature that you're using and it tells you where in your code the violation occurred. Now the second way to use reporting is with the report to response header. So this lets you configure out of band delivery of reports. The browser will queue up reports and send them to the location you're choosing separate from the execution of your page. And so here you can get all of the report types that we saw earlier. So you'll see a couple fields here. So first there's group and that just lets you name this particular set of endpoints. And then you can refer to that group name in other parts of your configuration. Now max age says how long this configuration is valid for after that we'll throw away this configuration. So this lets you change endpoints over time and gradually switch to new ones. And finally endpoints is an array of URLs. So you can configure multiple URLs for fallback. So if the browser can't reach one endpoint, it'll try another. And so talking about one place to configure reporting, CSP content security policy now integrates with the reporting API. So whereas before you'd specify a report URI and you'd give it an URL to where you wanted your reports to go. Now you can use report to directive and you just point it at one of the endpoints you'd previously configured. So if we go back to the previous example, you'd send a report to header and you define a group called CSP endpoint. You can have all the URLs you need there, the age, and then you just refer back to it here. So where can you use this stuff? So both a feature policy framework and the reporting API are shipped in Chrome. Firefox is implementing feature policy and Safari has support for the iframe allow attribute. Now what's really great is you can benefit from using these policies now, even though there isn't broad support across browsers. If you do some of your local testing in Chrome with flags enabled, you can apply all these policies and catch problems before they reach other environments. So I've talked a lot about a few policies. You know, walk through the examples, explain why you might want to use them, but that's really just the start. So here's a list of all the ones we have available today. Most of the ones around granular control, like turning on and off features like geolocation, microphone, those kind of things, those are already shipped, so you can use those now. And we saw that with the YouTube example and with AMP. A lot of the best practice policies, those are behind the flag and we're also working on a bunch more. Now seeing that long list, you go, man, how am I gonna set up policies? How am I gonna try them all out? Well, we have a handy DevTools extension. So this lets you really easily toggle a policy on and off and see the effect on your page. So you don't have to configure to set up headers or modify your code to allow attributes. You can just try it and see what'll happen. So here we've seen an example of using the extension to turn off the geolocation feature. Now this extension uses a JavaScript API. So the advantage there is you can feature detect which policies are even supported and you can go one step further and you can query to see which policies are enabled or disabled. So this can allow you to code defensively. So for example, if you have content that's embedded, you can respond differently if you know the feature isn't available to you. So we really love to hear if these policies are useful for you. The ones we're really interested in are some around some of the images and even sync X-ray chart. So we've kind of made it easy for you to hopefully copy and paste and get a header sent real quick. Now if you have ideas for new policies or if you have feedback on the existing ones, we'd love to hear from you on our GitHub repo. And finally, you can head over to featurepolicy.rocks and you'll get more information about feature policy, about code samples and live demos. Thanks a lot.