New Update Google’s Manifest V3 Still Hurts Privacy, Security, and Innovation

[oldschool]

It has now a disable per site switch with the current uBO Minus (MV3) 0.1.22.9086 :

View attachment 269231

I just discovered it earlier today.

 

[oldschool]

Personally I find AdGuard Browser Extension v3 0.3.11 better than uBO Minus (MV3) 0.1.22.9086.

AdGuard blocks YouTube adds here and uBO does not:

Yes, because it needs more permissions and so has more features. gorhill seems committed to the permission-less approach.

 

[Gandalf_The_Grey]

Yes, because it needs more permissions and so has more features. gorhill seems committed to the permission-less approach.

That is noble, but not very efficient...

 

[Back3]

I have installed AdGuard V3 and It's good. I see annoying cookie warnings for some sites, but they last about 1 sec before disappearing.

 

[Nightwalker]

Despite the best efforts from AdGuard team and Gorhill unfortunately manifest v3 extesions are bound to be lackluster, it is flawed design after all.

There are some viable alternatives for now:

1- Brave with its native adblocker based on Rust.

2 - Firefox

3 - AdGuard for desktop

4 - Manifest v3 + some DNS adblocker like NextDNS, AdGuard DNS and Control D.

 

[Back3]

Despite the best efforts from AdGuard team and Gorhill unfortunately manifest v3 extesions are bound to be lackluster, it is flawed design after all.

There are some viable alternatives for now:

1- Brave with its native adblocker based on Rust.

2 - Firefox

3 - AdGuard for desktop

4 - Manifest v3 + some DNS adblocker like NextDNS, AdGuard DNS and Control D.

AdGuard v3 and Next DNS complement each other on my PC. In the last 2 days…. With Chrome….

 

[silversurfer]

Google continues extensions Manifest v3 push even though some APIs are not ready yet - gHacks Tech News

Some Chrome extensions may not be ported to Manifest v3 yet because of missing APIs. All that with the January 2023 deadline looming.

www.ghacks.net

 

[oldschool]

Google continues extensions Manifest v3 push even though some APIs are not ready yet - gHacks Tech News

Some Chrome extensions may not be ported to Manifest v3 yet because of missing APIs. All that with the January 2023 deadline looming.

www.ghacks.net

No surprise there from the research I've been doing.

Here's just one example from 4 months ago:

Securing Decrypted Secrets

With browser wallet extensions, one critical security challenge is where to safely keep the decrypted secrets when the wallet is unlocked. In Manifest V2 extensions, background pages are used to store secret values in variables in memory, such that they can be persisted (at least as long as the browser is running), but are not stored to disk. None of this is possible with service workers, which are short-lived event handlers that typically do not maintain state. The only way to persist data between handled events in Manifest V3 using existing methods is by utilizing IndexedDB, Caches, or the chrome.storage API. However, all of these resources require that secret data is written to disk, thus creating a different set of security challenges.
A proposal was made to add the chrome.storage.session API to the chrome.storage API, which enables extensions to store variables in memory so that service workers and other parts of the extension can access these values as long as the session is active. Although the chrome.storage.session API is enabled in the newest chromium versions (starting from version 100 and higher), it has not been formally announced and, at the time of writing, is listed as pending in the chrome extension documentation. This modification to the API is not battle tested, and the impact that the usage of this API has on the security of browser extensions wallets is not yet known.

Unsupported Encryption and Key Derivation Packages

Another challenge caused by the switch to Manifest V3 is that encryption and key derivation packages that are considered to be secure, such as argon2 and libsodium-js, are currently not supported in Manifest V3 because of their usage of WebAssembly, which is disallowed for extensions in the new manifest version. For libsodium, this could be a bug in the code used to switch between wasm and asm, whereas argon2 is currently compiled only to wasm. Our team has previously discussed the common usage of insufficiently secure key derivation algorithms and weak encryption algorithms and we intend to publish a blog on this subject in the near future. The incompatibility of argon2 and libsodium-js with Manifest V3 currently limits the options for secure key derivation and encryption methods. It seems likely that WebAssembly will be supported for extensions in Chrome in the future, but the fix is not in production yet.

Conclusion​

In Manifest V3, in order for secret data to be stored securely, the chrome.storage.session API must be used, even though it has neither been officially launched nor sufficiently tested and audited as a secure medium for persisting secret data. In addition, encryption key derivation and encryption packages that are known to be secure are currently incompatible with Manifest V3, which limits the options available for the implementation of sufficiently secure cryptography.

We encourage community members and stakeholders to closely monitor developments in chromium based browser extension security.

Manifest V2 to V3: Challenges and Security Considerations. - Least Authority

 

[oldschool]

And these:
How to bypass Google Manifest v3 to publish malicious extensions on Chrome Web Store
Content blockers and Chrome's Manifest V3

 

[Gandalf_The_Grey]

Google to test disabling Chrome Manifest V2 extensions in June 2023

Google has announced more details regarding turning off support for the Google Chrome Manifest V2 extension as the company pushes more developers to transition to Manifest V3.

An update from the Chrome team says that they will proceed in careful, experimental steps, ensuring a smooth end-user experience during the phase-out of Manifest V2 in June 2023.

During that time, Google will support extension developers with guidance and information on the new protocol and how they can best roll out versions that support it without their users experiencing hiccups.

Today's update provides more granular information on the roll-out of Manifest V3 (and phase-out of Manifest V2), adding the following milestones:

• In January 2023, with the release of Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels.
• In June 2023, with the release of Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including Stable channel.

Based on this update, the deadline for lifting Manifest V2 support has been pushed back by five months, from January to June 2023.

Google to test disabling Chrome Manifest V2 extensions in June 2023

Developers of extensions for Google Chrome can keep their hopes up that the transition from Manifest V2 to V3 will be as gradual as possible, helping to minimize the negative impact on the community of users.

www.bleepingcomputer.com

 

[Pixel_]

More details on the transition to Manifest V3 - Chrome Developers

New details about the plan to move extensions to Manifest V3

developer.chrome.com

 

[oldschool]

This was last updated November 2023. Resuming the transition to Manifest V3 | Blog | Chrome for Developers

Resuming the transition to Manifest V3​

David Li


In December of last year, we paused the planned deprecation of Manifest V2 in order to address developer feedback and deliver better solutions to migration issues. As a result of this feedback, we’ve made a number of changes to Manifest V3 to close these gaps, including:

• Introducing Offscreen Documents, which provide DOM access for extensions to use in a variety of scenarios like audio playback
• Providing better control over service worker lifetimes for extensions calling extension APIs or 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

In addition to closing gaps, we’ve also added new features to the platform, such as the Side Panel API, which shipped earlier this year, and the Reading List API, currently in Beta. We discussed many of these changes recently at the Ad-Filtering Dev Summit, and shared more context on the changes and improvements we’ve made based on feedback.
With these changes in place, we’ve seen support for Manifest V3 increase significantly among the extension developer community. Specifically, we are encouraged by our ongoing dialogue with the developers of content blocking extensions, who initially felt Manifest V3 could impact their ability to provide users with the features they’ve come to expect.

"With Manifest V3, we've observed the immense effort that browser teams (Chrome in particular, but also other browsers) are putting into working on a unified platform, and I see how they are listening to the feedback from extension developers. As always, migrating to a new platform is a large undertaking, but we're very hopeful that the new unified platform will bring substantial benefits to the entire browser extensions ecosystem, and that ad blockers like us will be able to continue being up to the task and further improve.” - Andrey Meshkov, CTO AdGuard

Having addressed these migration concerns from our developer community, we are ready to continue moving towards Manifest V3 and the higher security and privacy guarantees it provides. As a result, we are resuming the deprecation timeline.

The phase-out timeline​

We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary, and Beta) as early as June 2024, in Chrome 127 and later. Users impacted by the rollout will see Manifest V2 extensions automatically disabled in their browser and will no longer be able to install Manifest V2 extensions from the Chrome Web Store. Also in June 2024, Manifest V2 extensions will lose their Featured badge in the Chrome Web Store if they currently have one.
We will gradually roll out this change, gathering user feedback and collecting data to make sure Chrome users understand the change and what actions they can take to find alternative, up-to-date extensions.
We will communicate with developers throughout the rollout, and we will continue to closely monitor feedback during this process. 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.
Enterprises using the ExtensionManifestV2Availability policy to ensure the continued functioning of Manifest V2 extensions in their organization will have one additional year - until June 2025 - to migrate the Manifest V2 extensions in their organization. Browsers with the policy enabled will not be impacted by the rollout of the deprecation until that time.

Next steps for extension publishers​

For extensions publishers who still publish Manifest V2 extensions, we highly recommend completing migration to Manifest V3 before June 2024. We’ve published a migration guide covering everything you need to know to successfully migrate. For a summary of some of the recent improvements to the Extensions platform, check out our quarterly updates from July and October. If you have any questions or trouble during the migration, please reach out via our support channels.
In the meantime, we’ll be continuing to release new features and functionality to improve the overall extension development experience.
Thank you to everyone who gave feedback. This has been invaluable in our work to evolve the platform in pursuit of a safer, more performant, and more privacy-preserving extensions ecosystem.

 

[oldschool]

This related blog post was also updated November 2023. Improving content filtering in Manifest V3 | Blog | Chrome for Developers

Improving content filtering in Manifest V3​

Oliver Dunk

Over the past year, we have been actively involved in discussions with the vendors behind several content blocking extensions around ways to improve the MV3 extensions platform. Based on these discussions, many of which took place in the WebExtensions Community Group (WECG) in collaboration with other browsers, we have been able to ship significant improvements.

More static rulesets​

Sets of filter rules are usually grouped into lists. For example, a more generic list could contain rules applicable to all users while a more specific list may hide location-specific content that only some users wish to block. Until recently, we allowed each extension to offer users a choice of 50 lists (or “static rulesets”), and for 10 of these to be enabled simultaneously. In discussions with the community, extension developers provided convincing evidence showing this was too low for certain use cases. After looking at the performance of the API in Chrome with these discussions in mind, we are now allowing up to 50 to be enabled simultaneously. (Notably, this is significantly higher than the limit of 20 requested in the WECG.) We also allow for 100 rulesets in total. This is shipping in Chrome 120 and increasing the limits is supported by both Firefox and Safari who both provided early input on this proposal.

More dynamic rules​

Most rules are “static” and ship with each update to an extension. However, to support more frequent updates and user-defined rules, extensions can add rules dynamically too, without their developers having to upload a new version of the extension to the Chrome Web Store.
When an extension can dynamically modify requests in ways that were not checked during Chrome Web Store review, this exposes users to risks of phishing or data theft. For example a redirect rule could be misused to inject affiliate links without consent.
Consequently, we only allowed extensions to add up to 5,000 rules which encouraged using this functionality sparingly and made it easier for us to detect abuse.
However, developers from extensions including AdGuard and Adblock Plus performed their own analysis and shared data that a higher limit would allow for more up to date rules and for users with a higher number of custom lists to migrate to Manifest V3. In fact, AdGuard reported that more than 2600 changes are made to popular lists each week, and of the five percent of users using custom filter lists, one in four of those users have a combined total of more than 5,000 dynamic rules across them (source). AdGuard noted this as a significant challenge for migrating their extension to Manifest V3 and we heard similar feedback from other content blockers.
We determined that some filter rules, such as those with an action of block or allow, are much safer and are less likely to be abused. They also happen to make up the large majority of ad block filter rules. Based on this, I drafted and shared a proposal in the Web Extensions Community Group to define a set of rules that we consider lower risk and allow up to 30,000 of these. We still keep an upper limit to avoid performance regressions.
This proposal was supported in the Web Extensions Community Group so we implemented it. Starting with Chrome 121, the higher limit of 30,000 rules applies to safe DNR rules, which we are defining as rules with an action of block, allow, allowAllRequests or upgradeScheme.
Based on the data shared by AdGuard, between 98 and 99 percent of their rules should benefit from this higher limit. Any remaining rules are still supported and can be added within the existing limit.
This is available in Chrome as the MAX_NUMBER_OF_DYNAMIC_RULES constant. The rule limit for all other dynamic net request rules stays at 5,000.

Reduced ruleset size​

In Chrome 118, we changed the default value for the isUrlFilterCaseSensitive field to false based on feedback from the community. This field controls if a rule that filters by URL is case sensitive, and we learned that most developers had a different default in their extension. Consequently, the value had to be set many times over. By making this change developers are able to achieve significant size reductions on their rulesets.

What’s next?​

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.
We will continue to review the limits we have in place to make adjustments where needed. To support this, we plan to share some of the data we collected as part of this work in the near future. Additionally, we are working on adding additional capabilities like the ability to match against response headers, which is a common request we’ve seen from PDF viewer extensions. In all cases, we’ll continue to communicate our work, and use the Web Extensions Community Group regularly as a place to discuss ideas and align on what we’d like to look at next.

 

[silversurfer]

Manifest V2 phase-out begins​

Thursday, May 30, 2024

In November 2023, we shared a timeline for the phasing out of Manifest V2 extensions in Chrome. Based on the progress and feedback we’ve seen from the community, we’re now ready to roll out these changes as scheduled.

Starting on June 3 on the Chrome Beta, Dev and Canary channels, if users still have Manifest V2 extensions installed, some will start to see a warning banner when visiting their extension management page - chrome://extensions - informing them that some (Manifest V2) extensions they have installed will soon no longer be supported. At the same time, extensions with the Featured badge that are still using Manifest V2 will lose their badge.

This will be followed gradually in the coming months by the disabling of those extensions. Users will be directed to the Chrome Web Store, where they will be recommended Manifest V3 alternatives for their disabled extension. For a short time after the extensions are disabled, users will still be able to turn their Manifest V2 extensions back on, but over time, this toggle will go away as well.

Manifest V2 phase-out begins

Update (10/10/2024): We’ve started disabling extensions still using Manifest V2 in Chrome stable. Read more details in the MV2 support ...

blog.chromium.org