Old Manifest V2 Chrome extensions will be disabled in 2024

• Chrome
• extensions
• v2
• v3
• Dev
• Canary
• Beta
• permalink

 Facebook |  X/Twitter |  LinkedIn |  Reddit |  Email |  Link

With Manifest V3, Google wants to make extensions safer by prioritizing privacy, but was initially criticized for the impact to ad blockers. The Chrome team has since added new features in response and is ready to disable old Manifest V2 extensions in 2024.

Google will begin automatically disabling Manifest V2 extensions in Chrome Dev, Canary, and Beta as early as June 2024 (Chrome 127+). Similarly, Chrome Web Store installs will no longer be possible. Developers are encouraged to update and migrate before then. 

This will gradually roll out, with Google taking into account user feedback and data to “make sure Chrome users understand the change and what actions they can take to find alternative, up-to-date extensions.” 

We expect it will take at least a month to observe and stabilize the changes in pre-stable before expanding the rollout to stable channel Chrome, where it will also gradually roll out over time. The exact timing may vary depending on the data collected, and during this time, we will keep you informed about our progress.

This was originally scheduled to take place in 2023, but Google spent this year closing the functionality gap between Manifest V2 and V3 with:

• Introducing Offscreen Documents, which provide DOM access for extensions to use in a variety of scenarios like audio playback
  
• Providing easier control over service worker lifetimes for extensions performing actions like receiving events over a longer period of time
  
• Adding a new User Scripts API, which allows userscript manager extensions to more safely allow users to run their scripts
  
• Improving content filtering support by providing more generous limits in the declarativeNetRequest API for static rulesets and dynamic rules

The latter specifically applies to ad blockers, with Google noting how “extension developers provided convincing evidence” that led the team to increase a previously imposed limit and relax other safety-derived restrictions. 

We are committed to continuing to invest in the declarativeNetRequest API so we can support as many use cases as possible, and look forward to continuing to work with the community. In particular, we’d like to thank members of the WECG for their engagement, including AdGuard for sharing a significant amount of the data that drove this work, and all browser vendors who have all been a major part of designing this API.

Comments: