 Welcome to the CER Technical Community Hour. Today we'll be talking about Chrome extensions and Manifest version 3. My name is Rich and I'll be your host for today's presentation. Joining me today, we have our main speaker, Allie Spivek, who is a developer relations lead for Chrome extensions. For today's agenda, I'll start with a quick introduction of the CER Technical Community Hour program. After that, I'll hand it over to Allie and she'll cover today's topic and the call to action for our CER partners. Today's Chrome Technical Community Hour is brought to you by the Chrome Enterprise Recommended Program. This program is Google's partner program for third-party solutions that are optimized for Chrome OS or integrated with Chrome browser. The Technical Community Hour is one of the benefits of CER. This webinar brings you the opportunity to engage with our team about new features and updates, enterprise development best practices, and our enterprise strategy. Now, without further ado, I'll pass it over to Allie and she'll kick us off. Allie? Thanks, Rich. I've mentioned before, I'm Allie Spivek and I've led the Chrome extension developer, Chrome extensions developer relations team since August of 2022. Prior to that, I spent eight years working at Mozilla, mostly on MDN, which is the documentation for the web platform. So I have a fair bit of experience working on the web and in browsers. I also previously worked at Okta and Cisco, and I started my career out as a web developer. Today, I'll be giving you a quick overview of extensions, covering updates to the extensions platform, and giving you a preview of a few things you can expect later on this year, as we move towards Manifest V2 deprecation. Also give details on additional ways you can share feedback with the Google extensions team. Extensions are built using web technologies, HTML, CSS, and JavaScript, and browser APIs. In Chrome, the browser APIs are built into Chromium, which powers Chrome and other browsers. Extensions help make your browser more fun, help you shop, increase your productivity, or manage the content you access. They provide customized browser features, integrations tools, and content modification or filtering, among many other things. By enhancing the experience of users, extensions can bring traffic and revenue to developers who make them. I love extensions because, in my opinion, they closely adhere to the original vision of the web, because users have control of their experience. Outside of web browsers, this level of customization is pretty rare, but in the browser, we built it right into the code. Over the last few years, Google has been adapting our extension platform to meet this changing state of the web as a whole. What this means, think about how the web has grown and evolved, not just in the 14 years since the web started launched in 2009, but overall, in general, the sheer number of people has grown, but also what they use the internet to do. Individuals and businesses all increasingly rely on the web for increasingly important and personal parts of their lives. People bank online, access their medical records, and have their personal and professional lives closely tied to their online presence. This makes risks to users higher, and therefore our standards for privacy and security also need to be higher. For extension developers, many of the platform changes we're using to raise these standards have been baked into Manifest v3. And Manifest is a few things. It is a JSON file that defines an extension and must be in the extension's root directory. The Manifest version being used is called out in this Manifest file. The Manifest version contains an allowed set of supported web and browser APIs and features that decide to find what the extension platform is. When we talk about Manifest v3, version 3, this is what we mean. Manifest v3 was launched in Chrome 88, and all new extensions are required to use it. Eventually, we plan to deprecate Manifest v2, and at that point, v2 extensions will no longer be allowed in the Chrome Web Store. It's important to note that Manifest v2 launched way back in 2012, and at that time, it made much more sense to open up the browser and the data it exposed to developers. In 2019, when Google proposed Manifest v3, it acknowledged the need for better protection for sensitive user data that is exposed to the browser and extensions. To get some perspective, the EU put GDPR into effect in 2018, so this kind of changes and legislation to protect user data were top of mind when Manifest v3 was designed. In addition to addressing access and user data, Manifest v3 also aims to improve extension performance. Manifest v3 is currently supported by Chrome, Edge, Firefox, and Safari, and we're working with other browser vendors in the W3C Web Extensions Community Group to ensure greater convergence and predictability of extension APIs in the future. So what exactly is changing in Manifest v3? I'll talk a bit about major changes, some recent improvements to our platform capabilities, most of which were driven by developer feedback, and some additional things that are coming soon. First, Manifest v3 removes the ability for an extension to use remotely hosted code. While powerful, this presents security risks when unreviewed code is executed in extensions. With this change, an extension can only execute JavaScript that's included within its package and subject to review by the Chrome Web Store. Some best practices for adjusting this change include loading a remote configuration, such as a JSON file at runtime, and cache the configuration locally. The extension then uses this cache configuration to decide what features to enable. Application logic can move to a remote web service that your extension can call, basically as a form of message passive. This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting it to the Chrome Web Store. And if you're using a framework, like React or Bootstrap, you can download the minified files, add them to your project, and import them locally. Second, extension service workers replace background pages to improve performance and better manage resources. Background pages have been part of extensions from the very beginning. They're independent of other Windows or tabs are persistent and allow extensions to take action in response to events. However, they have a few characteristics that impact performance, such as creating a consistent drain on resources because you essentially have a full web app running in the background at all times, even when it's not being used. Unlike background pages, service workers are formal by design, are stopped when not in use, and restart when needed. Similar to web workers, all the work they do occurs in their own thread and doesn't compete for attention with other tasks. Service workers are a big change. We've received a lot of feedback from developers on improvements and changes we need to make to support their use cases. Based on all that feedback, we've recently made several updates to how extension service workers function. We improved the idle timeout mechanism, and major activity keeps the service worker alive. We removed a mandatory five-minute timeout. We made changes so some APIs will always keep a service worker alive during critical operations, such as native messaging, and are working on more intuitive lifetime rules for other APIs, such as messaging and web sockets, so they're not shut down while continuing to do work. To help support this change, in the coming months, we're publishing a new set of service worker documentation and samples, including a tutorial and detailed explainers. Since service workers don't provide support for the same APIs and mechanisms that full document-based pages do, and using content scripts to access DOM APIs on web pages leaves the extension at mercy of different content security support policies on a page-to-page basis. In Chrome 109, we released off-screen documents API. This API allows extensions to open minimal, scoped, and relatively unpermissioned off-screen documents at runtime through a dedicated API, which gives extensions using service workers access to the DOM. In off-screen documents, lifetime and permissions are separate from the service worker, so the extension permissions carry over. To learn more, you can check out the documentation and samples on developer.chrome.com. Third, declarative net request replaces the blocking version of web request. To understand this decision, it's helpful to know that between January of 2018 and June of 2019, during the design of Manifest v3, 42% of malicious extensions caught by the Chrome Web Store review were abusing the web request API. This informed the approach to both this API and the blocking version. In the web request API, the browser sends all data in a network request to the extension the extension evaluates it and then tells the browser what to do. This API requires host permissions and each network request is evaluated in the main extension process which can impact performance. Web request gives developers great flexibility but also allows extensions to read everything a user does on the web. At the bare minimum, we believe users need more information and control over this functionality at install or runtime to give them the privacy that they expect and need. The blocking version of the web request API is a little different. It allows extensions to intercept and block network requests programmatically including altering the content of the page. This is useful for certain kinds of extensions such as ad blockers or parental controls but also carries a significant risk of malicious code injection and requires extensions to have access to sensitive user data. Declarative network request API can support many of the same use cases as web request blocking but it allows extensions to block network requests without accessing their content. Since declarative net request does not require access to user data, we are able to avoid requiring explicit user permission. The new API also helps performance. In real-world data from Chrome, we see declarative net request is on average 600 times faster. Declarative net request API uses rules to specify how the browser handles requests. Collections of rules called rule sets may be bundled and distributed with a specific version of an extension. These rule sets are updated when a new version of the extension is installed. We're actively discussing a current limit of 300,000 shared rules per use plus 30,000 per extension in the web extensions community group and will continue to evaluate different rule limits adjusting when necessary in addition to bringing new capabilities to this API. We also have recently updated the documentation and added a new set of samples for declarative net request to developer.chrome.com so you can check that out if you have some questions. So those are three major changes included in Manifest v3. We also have made some consequential but smaller changes. This includes browser action and page action APIs being unified into a single action API. We've released new scripting and fathicon APIs and added support for promises. Starting in Chrome 112, the quota for storage session property has been increased to approximately 10 megabytes. The file handle API will be available for experimentation on Chrome OS and Canary for versions 112 and 113. We're also working in the web extensions community group to design and implement a new user script API which should be available later this year. We don't want to trivialize the impact of these changes and we realize their significant cost in migrating extensions to Manifest v3. While we remain firmly committed to Manifest v3, the knowledge is still a lot more work for us to do on our part. As part of that acknowledgement, on March 29th, we sent an update stating we still do not have a firm deprecation date for Manifest v2. Over the last few months, we've made progress on a number of improvements that came from feedback from developer community and we plan to continue gathering feedback while we're closing bugs and improving our documentation. So we're still working on the timeline of the Manifest v2 phase out which is dependent on us closing key platform gaps and bugs. We're planning another update soon and we'll have a technical session at Google I.O. on May 10th. One important point to note is we are committed to providing at least six months of heads up to developers before we begin any deprecation of Manifest v2 features or API. For managed extensions, we'll likely extend this timeline even farther. We're committed to rolling out NV3 to improve security, privacy and performance. We also want to make sure that we phase out Manifest v2 in a timely manner and continue to make sure we're prioritizing key issues called out by developers. To help us do that, we're launching focus groups specifically designed to talk to extension developers and make sure the updates that we are making truly meet your needs. Stay tuned for more details in the coming months as we roll this program out. So that's where we are with Manifest v3 and the timeline for deprecating Manifest v2. I'd also like to give you a preview of some other things that we're working on. I mentioned earlier we believe the WebRequest API needs, at the bare minimum, to give users more information and control it install a runtime so they get the privacy they expect and need for what they do on the web. Unlike WebRequest blocking where we believe declared net request can function as a privacy preserving alternatives that does not require user intervention, a report to the non-blocking version of WebRequest relies on user grant and permission. Extension is powerful and they certainly require some user data to work their best. However, users should be able to decide if and when they give that data. We want to avoid situations where users don't fully understand what data they're sending or what they're getting in return. To that end, we want to give users more clarity and control over what and when they're sharing data with extensions. That's why we're going to be launching a new extension menu that better highlights page permissions for extensions and allows users to easily toggle those permissions on or off. This is a continuation of efforts in recent years to make controls more visible and powerful. Maybe users only want to share their data with certain extensions. Maybe they want to make sure no extensions can access data on their banking website but are fine with it anywhere else. With a new menu we want to make it easy for them to have that kind of level of control. We're currently fine-tuning the experience so details may change from what is on the slide. You can expect a new and improved menu very soon. Of course, privacy control should also be possible at install. That's why we're exploring how to give end users easier ways of toggling host permissions at install. Our goal is to make sure the user feels informed and in control of the information they're trading for the entirety of their extension journey. Shown here are some variations on an idea for how that change could be implemented. We hope we'll start experimenting with this before the end of the year. In summary, because what we do online is increasingly sensitive it's important to raise the bar for data access. Our approach for the blocking and non-blocking versions of web requests are a bit different but the end goal is still the same. Ensure extensions are designed to mitigate safety risks that come with a growth of evolution of what users are doing on the web. Our goal is to ensure extensions thrive long-term while making sure we have security and privacy for our users. You can keep up with changes to the platform on what's new in Chrome extensions page on Chrome developer.chrome.com And when we wrap up we'll ask you for some thoughts on manifestv3 and extensions development. Thank you and I'll give this back to Rich.