 Hi, my name is Simeon Vincent and I'm a developer advocate for Chrome Extensions. In this session, I'll be talking about some of the changes coming to our extension platform and how you can adapt your extensions for this new world. As we mentioned in the keynote, we're reimagining the Chrome extension experience in order to ensure that our users are safe and secure as they browse the web. This is no small undertaking. We're reassessing some of the basic assumptions that the extension platform is built on in order to address foundational issues with its design. At the same time, we're modernizing some of our core technologies to better align the extension's development experience with that of the open web. But before we get into how the extension experience is changing, we need to first talk about why. After all, extensions are great. They allow you to customize Chrome and change it from a web browser into your web browser. We're huge fans of the vibrant array of extensions that developers have created. But we're also aware that malicious actors use the same capabilities to trick, abuse and exploit users. In order to improve the end user experience and foster trust in the broader extension ecosystem, we've been rethinking how Chrome extensions work. We started looking at what capabilities we'd need to add to the extension platform, how to adapt Chrome's user experience, and ways that the Chrome Web Store could better inform users and policy updates to support these efforts. On the Chrome team, we think of these four items as how you build, run, discover and distribute extensions, and all of them together as the experience that we provide. So when I say that we're rethinking the extension's experience, I don't mean tweaking some APIs. I mean that we're trying to use all of the tools at our disposal to make our users safer. When we look at the ways that malicious actors exploit users, the key capability they take advantage of is persistent access to site data. More specifically, they capitalize on the broad data access that persistent host permissions grant extensions and the fact that many users don't understand the risks these permissions pose. Host permissions are a special type of permission that grant access to websites. When an extension has a host permission, it can view and modify data for that host through a variety of APIs. But perhaps the most important and dangerous capability it gains is the power to run JavaScript on pages served by that host. This is important because JavaScript access essentially means that the extension can see, change, and otherwise do whatever it likes with those websites. While good actors use this power responsibly, there are a lot of people that use it to take advantage of others. But the problem isn't just that this capability is dangerous. That overly broad host permissions are extremely common in the ecosystem. If we want to protect users, we need to change how both users and developers think about these capabilities. And the first step we took in this direction was giving users more control. Chrome 70 introduces site access restrictions for extensions. This feature allows users to change when and where an extension can run. Rather than be forced to give an extension access to every site on the web, users can now specify which specific sites the extension can access or limit the extension to only run when explicitly invoked. And critically, the introduction of this feature did not require authors to update their extensions. Next, we introduced the extensions menu earlier this year. This menu makes it easier to find the site access controls, while also helping end users see which extensions can access the current page. These changes are a step in the right direction, but we believe we can do more to help users. There are a couple of drawbacks to a reactive approach to site access controls. First, users have to discover the feature, figure out how it works, and remember to use it. Second, it breaks some basic assumptions about how extensions work for both developers and users. In order for all Chrome users to get the improvements that we're after, we need to take a step back and reimagine how the extension experience would work if all host permissions were optional. To show you what I mean, let's take a look at an existing extension install flow and see how it will change. Here, we have a simplified extension manifest that declares content scripts, permissions, and optional permissions. These are the three ways that an extension can get access to hosts. This is the prompt that would appear today if a user tried to install the extension. Note that the hosts declared in the permissions list and the content scripts matches fields appear here, but the optional permission one does not. That's because the extension can access these hosts immediately after installation, but the host in optional permissions is, well, optional. In order to access these hosts, the extension has to request them at runtime. In a future release, Chrome will no longer grant declared host permissions at installation time by default. We're still iterating on the design for the updated installation prompt, but to get a sense of what it might look like, let's take a look at a napkin sketch. This installation prompt is basically the same, but it has a new control that lets the user choose whether the extension can access sites only when invoked or everywhere it wishes to. The key difference is that by default, the extension will not be granted access to the hosts that it declares unless the user expressly chooses to grant it. This is essentially the opposite of today's behavior, where an extension can access all sites at requests, but users can choose to limit that access after installation. As such, for testing purposes, you can approximate this new experience by installing your extension and immediately switching it to run on click in the extension details page. And as a reminder, this 30-second sketch is purely for illustration purposes. We're still iterating on designs, but even after we ship it to stable, we'll be listening to feedback and continuing to improve the experience. While we don't have a firm timeline for when you can try this out, it will first start appearing in Chrome Canary during development well before it lands in stable. Finally, I also want to highlight that the example we're looking at is a Manifest V2 extension. The site access restrictions will apply to all extensions, regardless of manifest version. While Manifest V3 has some new capabilities, with more on the way, to help extensions adapt to a world of optional host permissions, the security benefits that this change provides are too important to give MV2 a pass. So given that this new world will empower users to take control of their security and privacy, you might be wondering what you should do to adapt. Over the rest of this talk, we'll be looking at some patterns that embrace this user control, and that will help you align with our longer-term vision for Chrome's extension platform. The first pattern that I'd like you to consider adopting is a runtime permission model. That is, rather than expect that you will receive all of the permissions that you request, embrace the idea that you will gain and lose permissions at runtime based on the user's choices. With respect to host permissions, the active tab permission provides an interesting and compelling alternative to requiring a static set of host permissions. Active tab is a special permission that grants temporary host access when the extension is invoked by the user. This permission represents a fundamentally different way of thinking about extension design that keeps the user in control of their experience. Now, there are a number of ways that a user can invoke an extension, but the three most common ones are clicking the action button, triggering a keyboard shortcut, or selecting an extension's context menu entry. Each of these actions gives Chrome a clear signal that the user is choosing to run your extension on the current page, and therefore, Chrome should grant temporary access. Later, I'll touch on a couple of other ideas that we're exploring to enable more use cases. Let's take a look at an extension to see how we might adapt it to embrace active tab style permissions. Here's a simple extension called Inverter that inverts the page's colors on click. In the next few slides, we'll migrate this extension from its original implementation based on static content scripts to active tab. On the left, we have the content script-based version of Inverter's Manifest. As we can see from the wildcard match patterns in the content scripts matches field, it requests access to all sites immediately upon installation. Besides requesting broader access than necessary, this can also lead to unexpected behavior if the user denies the extension access to certain pages or chooses to only run the extension on click. On the right, we have a revised version of the same manifest based on active tab. Rather than forcing the user to grant the extension access to all sites, this version instead uses active tab to receive temporary access to the current page when the user clicks the browser action button. Next, let's look at the respective background scripts for each of these approaches. In the top code block, the content script version of the extension listens for the action buttons click event. When clicked, the extension sends a message to the content script injected on the currently focused page, which in turn reacts by inverting the current page's color. In the bottom code block, we take a different approach. Our background script still registers an event listener to detect when the user clicks the action button, but now instead of sending a message on a click, our callback will react by injecting a content script into the current page to invert the page's color. With this change, the extension works just as before, but no longer requires persistent host access. While the scenario may seem a little contrived and admittedly it is, I see extensions like this somewhat regularly in the wild. I mostly wanted to highlight this case in order to encourage you to think about different ways to enhance a user's experience that don't require passive access to sensitive data. Of course, active tab style host permissions aren't perfect for all situations. Sometimes you want your extension to run right away without the user having to invoke it. That brings us to the next pattern I'd like to talk about. Ways to politely request more permissions for your extension. In this section, we'll be focusing on how to request permissions in context while respecting the user's choice. Going back to inverter for a moment, let's say that the user repeatedly uses this extension on example.com. We could interpret this pattern to mean that the user likes running our extension on this site and would have a better experience if it ran there automatically. We can use the data exposed by invoking active tab to set to this pattern and Chrome's permissions API to request persistent host access so the extension can run automatically. The moment of invocation is a good time to prompt the user for more permissions. Here's one idea of what that might look like. In this example, the prompt asks the user if they'd like to automatically run our extension on this site. There are a few important parts of this UI that I want to call out. First, it's presented contextually immediately after the user invoked the extension. This helps the user clearly associate that prompt that they just saw with the action that they just took. Second, the prompt explains what it's asking for and just as importantly, why. In this case, inverter has been used several times on example.com. This makes it clear to the user that the extension is actively trying to help them. Finally, it preserves user choice. It's up to the user whether they want to grant access to this new permission. While I didn't include this in the mockup, you may also want to give users a way to disable these prompts in case they don't find them helpful. If the user clicks the always run on this site option, the extension can use Chrome's permissions API to request persistent access to the current host. Once the extension has this permission, it can register a content script to run automatically on this site. User interaction no longer required. Let's take a high level look at how we might implement this in our extension. Just as before, our extension has an on-click listener registered for the action button in order to respond when the user invokes the extension. Now though, we're also tracking a small amount of metadata about the request to determine if this is a site that the user has run the extension on many times before. If it is, we use that as a signal to request access to this host. We just looked at a way to ask the user for more permissions in response to a repeated invocation, but runtime permission requests can also work just as well in other parts of the UI. This functionality can easily be implemented in other UI surfaces like your extension's options page. Here's one such page where an extension allows the user to directly modify their permission grants. It's worth noting that while we've been focusing on host permission so far, this pattern applies equally well to other types of permissions, like the notifications permission at the top of this page. The final pattern that I'd like to go over today is user onboarding. In some cases, there may be a permission that your extension absolutely requires and cannot function without, or maybe there's a permission that you think would make the user experience materially better and you want to make sure that the user knows how to get the most out of your extension. Even in these cases, we recommend embracing the runtime permission model in order to keep users in control of their data and experience. One way you might do this is by providing a post-install onboarding flow. Here, we have a mock-up showing off a page that opens immediately after installing that really good extension. In order to help the user make an informed decision, we explain what permissions we're requesting and why. In this example, I also wanted to go the extra mile and tell the user what happens if they don't grant permission. If you'd like to embrace this kind of transparency that are worried about information overload, this could be hidden behind a Learn More button or moved to a support article on your website. When the user clicks the grant access to example.com button, Chrome will display a confirmation prompt for the new capability request. If the user cancels at this point, the capability will not be granted but you can still request it again in the future. Now, let's take a look at how we can set this up. This is pretty straightforward to implement. All we need to do is add an uninstalled listener to the extension's background context. Here, we wait for the extension to be newly installed and then create a new tab for the onboarding page included in our extension. In a JavaScript file referenced by onboarding.html, we set up a listener for when the user clicks the grant access to example.com button. In response to that click, we request permissions for that host. Now that we've seen how to implement this, let's take a step back. You may be wondering if we're showing this onboarding in response to the extension being installed. Is that really better than directly requesting the permissions at install time? In short, yeah, it is for a couple of reasons. First, we can provide the user with much more context and detail here. We can make it clear not only what permissions we're requesting but also why we're requesting them and let them know what the consequences of not granting them are. This type of detail isn't something that can be included in the extension install dialog, which makes it much more challenging for the user to make an informed decision. Secondly, even though we, the extension developer, believe that this is an important permission, we're choosing to lean into user choice. The dialog gives the user an ultimatum. They can either install the extension and give it the requested permissions or not install the extension at all. With this flow, the user can still use the extension. Even if they didn't grant all of the requested permissions, they'll just have a slightly different experience, one that they may prefer. Preserving this user choice and keeping the user in control of their data is the primary focus of this pattern and Chrome's broader permissions changes. We've talked about a few different patterns that you can use directly in your extension to adapt to a more runtime-based permission model, but the platform itself is also changing. We're working to provide you with more tools and capabilities that will enable you to build rich experiences without requiring a bunch of permissions. While there's not enough time to dive into all of the different ways that the extension platform is evolving, I'd like to touch on a few of the major ones that we've recently added or are currently investigating. I won't be going into too much depth for these, but there are links in the description below where you can go to learn more. Chrome 84 was the first stable release of Chrome to support the declarative net request API, which allows you to block or modify network requests without needing access to site data. This is critical as it allows content blockers to continue functioning out of the box without having to give them access to all of the sites that you visit. We're also adding more flexibility to content scripts and script injection through a dynamic content script API. This will allow for greater flexibility of script injection on defined hosts, enabling you to run when and where the user wants. Another area that we're exploring is providing new contextual entry points for users to interact with your extension while preserving the user's privacy. This will make active tab style in-context invocation of extensions easier and more seamless. For example, one of the areas that we're investigating is a form of declarative badging, allowing extensions to badge content on a site with an icon to let the user know that they can use your extension. These are just a few of the areas that we're looking at. In the coming months, there will be much more functionality coming to Manifest V3 that both make it easier to build extensions in this new runtime permission world and that enable exciting new use cases in the future. And with that, let's start wrapping things up. In this session, I've covered how the Chrome team is thinking about protecting users, how host permissions are changing in parallel with Manifest V3, several privacy-preserving patterns that keep users in control of their experience and some new capabilities that we're currently exploring. We're aiming to make Chrome 88 the first stable version with support for Manifest V3. You can preview these changes today by downloading Chrome beta. And we're planning to have the Chrome Web Store start accepting Manifest V3 submissions in January 2021. Links to our MV3 documentation, code samples and transition timeline are in the description below. This is a really exciting time for Chrome extensions. Since their introduction, extensions have been a critical part of the Chrome experience. We constantly hear from users that they love how extensions let them customize, tweak and enhance their favorite browser. The creativity and ingenuity of developers like you make the web better for everyone. I cannot wait to continue exploring how Chrome can keep pushing the boundaries of what's possible with privacy-preserving APIs and enabling extension developers to surprise and delight users. By working together, we can build a safer, more secure extensions ecosystem. I look forward to taking this journey with all of you. Thank you for watching.