Iterating on Manifest V3
Devlin Cronin
Hi folks,
Thank you very much for the feedback and constructive thoughts on the current Manifest V3 draft. These discussions have been very valuable in highlighting gaps in capabilities and pain points. This is one of the many advantages of being able to develop these changes publicly as an open source project, and Chrome is a better browser because of it.
The extensions ecosystem on Chrome is vibrant and varied, and enables myriad use cases that would otherwise be impossible. We are committed to preserving that ecosystem and ensuring that users can continue to customize the Chrome browser to meet their needs. This includes continuing to support extensions, including content blockers, developer tools, accessibility features, and many others. It is not, nor has it ever been, our goal to prevent or break content blocking.
Background for Manifest v3
Extensions have evolved from a power user feature to a core aspect of Chrome, with close to half of desktop users using them. Paired with that increase in usage, we’ve seen abuse on the platform increase dramatically. While we have a strict review process in place and we continue to invest heavily there, no review system is perfect. An extension may comply with policies while still acting contrary to the user’s desires, if the user is unaware of what the extension is doing and why. We have relied on install-time warnings to inform users of what extensions are capable of, but both user research and real-world abuse have shown that this is insufficient. Users need to have greater control over the data their extensions can access.
One of the goals of Manifest V3 is to move the platform forward to a state where abuse is harder and extensions are more transparent, but we continue to have the incredible ecosystem and solve the same use cases we do today. This requires thinking of new solutions to problems, including ways that extensions can perform the same functionality (such as content blocking) without requiring access to all of a user’s data. We need to support these use cases while giving users much better transparency and control.
This is also the right time to modernize the platform and address long-running performance issues. Extensions had historically been a “proving ground” for bringing functionality to the Web, supporting things like USB and Bluetooth long before they were available as APIs on the open web. Similarly, background pages were a major inspiration for ServiceWorkers. Completing this cycle involves moving the extensions platform to use the open web alternatives when they exist. Maintaining separate APIs has very real cost for the Chromium project (through ongoing maintenance), for developers (through confusion between similar-but-different APIs), and for users (through increased resource consumption and binary size).
Moving towards the open web allows the extension system to move forward as the web moves forward, and moving away from a long-running persistent process with a full DOM can have very real impact on resource usage. We understand that, for some scenarios, these gains are less critical - with a powerful machine, the extra resource cost is not always noticeable. However, we feel that Chrome should provide a great browsing experience to all users, including those on less powerful machines (such as old hardware and the growing market of entry-level laptops), where these resource drains are incredibly impactful. Good performance on low-end devices is critical.
Clarifications on the Proposal
I’d like to reiterate that all of these changes are still in the draft and design stage, as explicitly called out in the document and the tracking bug. The declarativeNetRequest API is still being expanded and is under active development, and the exact changes that will be implemented as part of Manifest V3 are not finalized. Feedback during this time is crucial, and we absolutely want to hear your comments and concerns.
Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3. In particular, there are currently no planned changes to the observational capabilities of webRequest (i.e., anything that does not modify the request). We are also continually listening to and evaluating the feedback we’re receiving, and we are still narrowing down proposed changes to the webRequest API.
Moving Forward
We are currently evaluating all the feedback that has been offered, much of which has been centered on the declarativeNetRequest API. There are a number of additions and changes we plan on making to the declarativeNetRequest API as a result of the concerns raised. These include:
Dynamic Rule Support: We agree that this is valuable in creating sophisticated content blocking extensions, and will be adding support for declarative rules that can be added or removed at runtime to the declarativeNetRequest API.
Increased Ruleset Size: We will raise the rule limit from the draft 30K value. However, an upper limit is still necessary to ensure performance for users. Block lists have tended to be “push-only”, where new rules are added but obsolete rules are rarely, if ever, removed (external research has shown that 90% of EasyList blocking rules provided no benefit in common blocking scenarios). Having this list continue to grow unbounded is problematic.
Additional Actions and Conditions: We plan to add support for matching based on more conditions, such as resource size, and will provide actions to modify parts of a request instead of just blocking it, such as stripping cookies. We are also investigating other conditions and actions that may make sense to add, such as matching based on top-level domain. (One additional note: While we are investigating adding support for CSP modifications, adding a CSP header to disable JavaScript was frequently mentioned as a use-case; this is already possible through the contentSettings API. If this is insufficient, please let us know why.)
We are also evaluating the concerns around other aspects of the Manifest V3 draft, including pain points of using ServiceWorkers instead of persistent background pages (such as expensive data fetching or decryption and DOM parsing). We will keep you updated with developments as they evolve.
Once again, we are committed to supporting extensions in Chrome. We will continue to work with developers. We won’t launch Manifest V3 until it is ready, and there will be a migration period in which we can continue to address feedback and issues. We will not remove support for Manifest V2 until we are confident in the platform.
Please continue sharing your feedback with us (preferably in specific threads, to make tracking easier). We are especially interested in hearing about specific capabilities and use cases that are not possible with the latest Manifest V3 design proposal. While we understand that the pivotal changes we’ve proposed inspire passionate responses, posts without actionable content only slow down our ability to evaluate and iterate on the feedback shared here.
Thank you for your feedback and for your continued passion for the Chrome Extensions platform.
- Devlin