 Welcome to What's New in Chrome Extensions. We're here today to give a quick overview of extensions, cover some recent changes we've made, and give a preview of some exciting upcoming features. My name is David Lee. I'm a product manager for Chrome Extensions. And first, I want to give a refresher on extensions in general and what better way to do that than looking at a few of the awesome extensions that can be found in the Chrome Web Store. Let's talk a bit both about how these extensions help users and how they bring traffic and revenue to the developers who make them. First, we have education extensions like Read&Write, which provide reading and writing tools to help students succeed in the classroom. Text help, the company behind it, does licensing deals directly with schools to bring these enhanced experiences to over 10 million users. Second, Honey is a shopping extension from PayPal that helps users save money online by finding coupon codes and offering rewards. They're free to use for the shopper and make money through commissions from merchant partners for successful purchases. Finally, Pinterest Save button made by Pinterest allows users to save images and ideas from across the web to their Pinterest boards. It's also free to use. The Save button augments Pinterest's core offering allowing users to carry Pinterest with them as they browse other sites, improve user experience, and engagement. Many extensions like these have found success in our store and we would like to continue enabling developers and businesses to find similar success. That is why in the last few years, we've been investing heavily in adapting the extension platform to meet the changing state of the web as a whole. To explain what I mean, let's talk about how the web has grown and evolved in the 14 years since the web store launched in 2009. What I want to highlight is not just the sheer number of people online, but also what people are fundamentally using the internet to do. In the last five, six, seven years, individuals and businesses have come to rely on the web and on extensions for increasingly important and personal parts of their lives. People now frequently bank online, look at their medical records online, and seemingly do everything else online. And along with this change, it's clear that user expectations are also changing, especially as it relates to privacy and user data. People know the risks are now higher. So user expectations have also become higher. Therefore, our standards for the ecosystem must likewise be higher. For extension developers, many of the platform changes for these rising standards have been baked into Manifest V3. I'll pass it off now to Ali to speak more about that. Hi, I'm Ali Spivek, lead for Chrome Extension's Developer Relations. And today I'm going to talk about Manifest V3, the next version of the extension's platform. In the early days of web browsers, and even at the launch of Manifest V2 in 2012, it made more sense to open up the browser and watch the data exposed to developers. In 2019, when Google proposed Manifest V3, it acknowledged the need for better protections for sensitive user data being exposed to the browser and extensions. For perspective, the EU put GDPR into effect in 2018, so these kind of changes to better protect user data were top of mind when designing Manifest V3. In addition to addressing issues with how extensions access and use data, Manifest V3 also aims to improve the performance of extensions. 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 cover a few of the major changes and some recent improvements to platform capabilities that came from developer feedback. First, Manifest V3 removed the ability for an extension to use remotely hosted code, which, well, powerful, present security risk 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. Second, extension service workers replace background pages to improve performance and better manage resources. Background pages are independent of any other window or tab 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 by essentially having a full web app running in the background at all times, even if 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 on their own threads and won't compete for attention with other tasks. Service workers are a big change. We received a lot of feedback from developers on improvements and changes needed to support their use cases. Based on that feedback, we've recently made several updates to how extension service workers function. We improved the idle timeout mechanism and made sure activity keeps the service worker alive. We removed the 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. We also released the off-screen documents API in Chrome 109, which allows extensions to open minimal, scoped, and relatively unpermissioned off-screen documents at runtime through a dedicated API, which gives extension-using service workers access to the DOM. 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 the data in a network request to the extension. The extension evaluates it and then tells the browser what to do. This 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 they expect. The blocking version of the web request API is a little different, as it allows extensions to intercept and block network requests programmatically, including altering the content of the page. This is useful for certain types of extensions, such as ad blockers or parental controls, but it also carries a significant risk of malicious code injection and requires these extensions to have access to sensitive user data. The declarative net request API can support many of the same use cases as web request blocking, but allows extensions to block network requests without accessing their content. Since declarative net request does not require access to user data, we're able to avoid requiring explicit user permissions to access site data. The new API helps performance as well. Real-world data from Chrome shows declarative net request is on average 600 times faster. The declarative net request API uses rules to specify how the browser's handles requests. We are actively discussing the current limit of 300,000 shared rules per use, plus 30,000 per extension in the web extensions community group, and we'll continue to evaluate different rule limits, adjusting if necessary, in addition to bringing new capabilities to this API. We don't want to trivialize the impact of these changes on developers and realize there is significant cost in migrating extensions to Manifest V3. Recently, we announced changes to the Manifest V2 deprecation timeline. We remain firmly committed to Manifest V3 while acknowledging there's more work to do on our part. Going forward, we are making the following commitments to developers. Before announcing a new timeline for deprecation, we will finish addressing our prioritized platform gaps and closing critical bugs that are documented on the Manifest V3 status page on developer.chrome.com. We will give developers time to build, guaranteeing at least six months between a timeline announcement and any experiments deprecating Manifest V2 features. We'll enable a better feedback loop and be more responsive. In the coming months, we will add additional support for developer questions and launch focus groups for feedback. We will continue working with other browser vendors in the web extensions community group to define improvements and next generation functionality. That's where we are with the Manifest V3 and the timeline for deprecating Manifest V2. Outside the platform, we're also making a number of changes to Chrome UI and the web store. I'll hand it back to David to give you more information. One point I'd like to emphasize is that Manifest V3 exists as part of a larger picture. It's needed, but not sufficient by itself to ensure a safer, more privacy-preserving ecosystem. Over the past few years, we've also made many changes in other parts of Chrome and Chrome Web Store. We introduced badges for those who have verified their identity and followed best practices. We added privacy disclosures. We've also overhauled our store policies to be easier to understand and have strengthened the language in some cases where we felt the landscape has changed. And now, we're continuing the evolution of our security and privacy story. Unlike with web requests blocking where we believe that declarative net request can function as a privacy-preserving alternative that does not require any user intervention, our approach to the non-blocking version of web request needs to be different. Extensions are tools in a user's toolbox. Some tools need user data to work their best, but the user should be the ones to decide if they want to give them that data. We want to avoid situations where users give up data to extensions without fully understanding what they might be getting in return. So, we want to give end users more clarity and control over what they're sharing with extensions and when. This is why we're launching a new extension menu that better highlights page permissions for extensions and allows users to easily toggle those permissions on or off across the web. This is a continuation of our efforts in recent years to make these controls more visible and powerful. Maybe the user wants to share their data with only certain extensions. Maybe they want to make sure that no extensions can access their data on their banking website, but they're fine with sharing everything else. With this new extension menu, we want to make that easy. We're currently fine-tuning the experience so the details may change from what's on the slide, but expect this new and improved menu very soon. Of course, this privacy control should also be possible at extension install time. That's why we're also 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 what information they're trading for the entirety of their extension journey. Showed here are variations on an idea for how that change may be implemented. We hope to start experiments for this before the end of the year. In summary, because data online is becoming 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 the same. Ensure a bright future for extension developers and the ecosystem, given the increasing user expectations and increasing safety risks that come with the growth and evolution of the web. We believe this added security, privacy, and transparency for Chrome users is a must-have requirement. It's a prerequisite. It's something we must do before we invest heavily in new experiences and introduce APIs and capabilities that allow extensions to further customize the user's browsing experience. Since we've come so far in our security and privacy journey, though, we do have an exciting sneak peek to share with you all. Later this year, we are launching the public beta of a completely redesigned web store with enhancements to search, personalize recommendations, and the broader user journey, your high-quality extensions will be easier to find than ever before. Expect to learn more about this redesign very soon. And that's not all. We're also shipping a very powerful new API, which Oliver will now introduce. Thanks, David. And hi, I'm Oliver Dunk, a developer relations engineer working on extensions. I'd like to show you one API we're bringing to Chrome this summer in direct response to feature requests from many developers over the years, me included. If you've been paying attention to Chrome, you may have noticed the side panel. This is a new UI surface which attaches to the side of your browser window. It's previously been used for features like the reading list and bookmarks, but now we're bringing it to extensions. With a new UI surface, your extension can now show contextual information directly alongside a page, like this dictionary extension, which shows the definition of a selected word. Let's see how it's built. To use the side panel, extensions need to request the side panel permission in their manifest. We also need to add the side panel key and a default path pointing to a page within our extension bundle. Then in our service worker, we'll add a context menu item and register a listener, which broadcasts selected text to the other parts of our extension. We'll also create our side panel.html file, include a script and listen for messages from our service worker. When we're asked to define a word, we'll update DOM. It's worth noting that here you have access to all of the APIs usually available to trusted extension pages. That's a quick overview of the side panel and how to get started incorporating it into your extension. We didn't show it here, but the API also gives you additional flexibility to control how and when the side panel appears. You can get started and learn more about which conversions this API is available in, in our docs. As an extension developer myself, I hope you're as excited about the side panel as I am. Now, back to David. Thank you, Oliver. Our goal is to ensure that the extension ecosystem thrives long term. To achieve this goal, we have taken steps to tighten security and adapt to changing user expectations of privacy. These changes will enable us to introduce more exciting new platform functionalities, such as the side panel API and overall improvements to the Chrome Web Store. We look forward to continuing to deliver new experiences and functionality that will enable you, our developer community, to create and distribute high quality and powerful extensions for your users. We are excited to see what you will create.