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

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
It's been over two years since our initial response to Google's Manifest V3 proposal. Manifest V3 is the latest set of changes to the Chrome browser’s rules for browser extensions. Each extensions manifest version update introduces backwards-incompatible changes to ostensibly move the platform forward. In 2018, Manifest V3 was framed as a proposal, with Google repeatedly claiming to be listening to feedback. Let's check in to see where we stand as 2021 wraps up. Since announcing Manifest V3 in 2018, Google has launched Manifest V3 in Chrome, started accepting Manifest V3 extensions in the Chrome Web Store, co-announced joining the W3C WebExtensions Community Group (formed in collaboration with Apple, Microsoft and Mozilla), and, most recently, laid out a timeline for Manifest V2 deprecation. New Manifest V2 extensions will no longer be accepted as of January 2022, and Manifest V2 will no longer function as of January 2023.
According to Google, Manifest V3 will improve privacy, security, and performance. We fundamentally disagree. The changes in Manifest V3 won’t stop malicious extensions, but will hurt innovation, reduce extension capabilities, and harm real world performance. Google is right to ban remotely hosted code (with some exceptions for things like user scripts), but this is a policy change that didn’t need to be bundled with the rest of Manifest V3.

Community response to Manifest V3, whether in the Chromium extensions Google group or the W3C WebExtensions Community Group, has been largely negative. Developers are concerned about Manifest V3 breaking their extensions, confused by the poor documentation, and frustrated by the uncertainty around missing functionality coupled with the Manifest V2 end-of-life deadline. Google has been selectively responsive, filling in some egregious gaps in functionality and increasing their arbitrary limits on declarative blocking rules. However, there are no signs of Google altering course on the most painful parts of Manifest V3. Something similar happened when Chrome announced adding a “puzzle piece” icon to the Chrome toolbar. All extension icons were to be hidden inside the puzzle piece menu (“unpinned”) by default. Despite universally negative feedback, Google went ahead with hiding extensions by default. The Chrome puzzle piece experience continues to confuse users to this day.

The World Wide Web Consortium’s (W3C) WebExtensions Community Group is a welcome development, but it won't address the power imbalance created by Chrome’s overwhelming market share: over two-thirds of all users globally use Chrome as their browser. This supermajority of web users is not likely to migrate away because of a technical squabble about extension APIs. No matter what Google decides to do, extension developers will have to work around it—or lose most of their users. And since developers are unlikely to want to maintain separate codebases for different browsers, other browsers will be heavily incentivized to adopt whatever set of extension APIs that Google ends up implementing.

Instead of working in true collaboration on the next iteration of browser extensions, Google expects Manifest V3 to be treated as a foregone conclusion. Participation in the WebExtensions group gives Google the veneer of collaboration even as it continues to do what it was going to do anyway. In short, Google enters the room as an 800-pound gorilla unwilling to listen or meaningfully work with the community.
Forcing all extensions to be rewritten for Google’s requirements without corresponding benefits to users is a fundamentally user-hostile move by Google. Manifest V3 violates the "user-centered", "compatibility", "performance" and "maintainability" design principles of the WebExtensions group charter. While Google's response to community feedback has been tweaks and fixes around the margins, we have been paying attention to what developers are saying. The shortcomings of Manifest V3 have come into focus.

Requiring service workers for extensions is harmful​

Most browser extensions are built around a background page, a place where all sorts of work happens out of sight as the user browses. With today’s Manifest V2, extensions in Chrome have the choice to opt into using an ephemeral “event”-based background page, or to use a persistent background page. Ephemeral pages get shut down and restarted repeatedly, whenever Chrome decides to do so. Persistent pages continue running as long as the browser is open. In addition to extension APIs, both kinds of extension background pages have access to the standard set of website APIs.

Manifest V3 removes the choice, instead requiring all extensions to be based on “service workers.” Service workers are ephemeral, event-based, and do not have access to the standard set of website APIs. Along with removing the “blocking webRequest” mechanism, which we talk about below, rebasing all extensions on service workers is one of the most damaging changes in Manifest V3.
Service workers are JavaScript scripts that run in the background, independent of the website that launched them. Service workers are meant to enable websites to perform previously hard or impossible tasks that optimize website performance or provide offline functionality. For example, the first time you visit twitter.com, the website installs a service worker in your browser. The service worker will stay installed, and may continue to perform tasks, even if you lose network connectivity or navigate away from twitter.com. Service workers give websites superpowers, giving web apps functionality that is otherwise difficult or impossible. But service workers don’t have the same freedom to execute code that websites do, and there are limits to how long service workers live. Each service worker listens for messages from its website, performs its tasks, and shuts down shortly after. This makes sense, as the website is the main actor that calls upon its service worker for help. But this model doesn’t translate well to browser extensions.

Service workers were designed to work with websites, and they are a standardized part of the Web Platform. But there is no equivalent service worker standard for WebExtensions. Since extensions enhance the browser, applying the same execution limits from website service workers makes no sense, and yet this is exactly what Google has done.
Websites and their service workers are developed by the same teams, and are meant to work in tandem. But browsers and browser extensions are built by different teams with different goals. Extensions are supposed to add new functionality that browser developers didn’t think of or intentionally left out. Sometimes, extensions do things that explicitly act against the intentions of the browser developers, such as when tracker blockers restrict the information flowing out of Chrome. Chrome continues to be the only major browser without meaningful built-in tracking protection. Web extensions need more freedom to operate on their own, which means first-class access to browser APIs and persistent memory.

Take a look at the long list of known use cases harmed by requiring service workers. Seamlessly playing audio, parsing HTML, requesting geolocation, communicating via WebRTC data channels, and the ability to start a separate service worker are all broken under the new paradigm. Under Manifest V2, extensions are treated like first-class applications with their own persistent execution environment. But under V3, they are treated like accessories, given limited privileges and only allowed to execute reactively.
As per feedback from Mozilla engineers, one legitimate benefit of service workers may be getting extensions to gracefully handle early termination on Android. But there are ways of achieving this goal that don’t involve this degree of harm. And if one of Google's aims for Manifest V3 is to help bring extensions to Chrome on Android, Google failed to communicate this information. How can browsers and extensions developers collaborate on moving extensions forward when it appears that Google is unwilling to share all of the reasons behind Manifest V3?

declarativeNetRequest alone is inadequate​

Besides proposing to move extensions to an ill-fitting service worker foundation, Google’s Manifest V3 is changing the way that content-blocking extensions can function. Extensions based on Manifest V2 use webRequest, a flexible API that lets extensions intercept and block or otherwise modify HTTP requests and responses. Manifest V3 drops the blocking and modification capabilities of webRequest in favor of the new declarativeNetRequest API. The interception-only or “observational” webRequest API—which allows extensions to monitor, though not modify, requests—will supposedly remain in Manifest V3, although the API is broken in Manifest V3 at this time, with the relevant bug report open for over two years.
As the name suggests, the new declarativeNetRequest API is declarative. Today, extensions can intercept every request that a web page makes, and decide what to do with each one on the fly. But a declarative API requires developers to define what their extension will do with specific requests ahead of time, choosing from a limited set of rules implemented by the browser. Gone is the ability to run sophisticated functions that decide what to do with each individual request. If your extension needs to process requests in a way that isn’t covered by the existing rules, you just can’t do it.

From this follows the main problem with requiring a declarative API for blocking. Advertising technology evolves rapidly, and privacy extension developers need to be able to change their approaches to it over time. To make matters worse, extension developers can't depend on Google browser engineers to react in any timely manner or at all. Google abandoned extension API development for years before Manifest V3. For example, while extensions have had the ability to “uncloak” CNAME domains in Firefox for over three years now, Chrome still lacks support for CNAME uncloaking. And while this support may come at some point in the future as part of declarativeNetRequest, many years behind Firefox, what about uncloaking CNAMEs elsewhere, such as in observational webRequest?

As we wrote in 2019, “For developers of ad- and tracker-blocking extensions, flexible APIs aren’t just nice to have, they are a requirement. When particular privacy protections gain popularity, ads and trackers evolve to evade them. As a result, the blocking extensions need to evolve too, or risk becoming irrelevant. [...] If Google decides that privacy extensions can only work in one specific way, it will be permanently tipping the scales in favor of ads and trackers.” We have many questions about how the declarative API will interact with other Google projects. Will Google’s Privacy Sandbox technologies be exposed to declarativeNetRequest? If declarativeNetRequest works exclusively on the basis of URL pattern matching, how will extensions block subresources that lack meaningful URLs, facilitated by another Google effort called WebBundles? As more tracking moves to the server, will Manifest V3 extensions be able to keep up? Is Manifest V3 a step down a path where the Google parts of the Web become unblockable by extensions?
We reject declarativeNetRequest as a replacement for blocking webRequest. Instead, Google should let developers choose to use either API. Making both APIs available can still fulfill Google’s stated goals of making extensions safer and more performant. Google could use Chrome Web Store to guide extensions that don’t actually need blocking webRequest towards the declarative API. Google could also provide extension developer tools that would automatically analyze your extension for potential improvements, like the audit tools provided to promote best practices to website developers. In addition, extensions that use webRequest should get flagged for additional review; this should be clearly communicated to extension developers.

Google’s performance claims​

Google has claimed that part of the reason for its Manifest V3 restrictions is to improve performance. If extensions are allowed to have persistent background pages, the argument goes, then those pages will sit idle and waste memory. In addition, Google claims webRequest is an inefficient API because of how it traverses browser internals and extension code, and because it makes it possible for poorly implemented extensions to slow down Chrome. Google has provided no evidence to back these claims. In fact, many of the most popular extensions drastically speed up regular browsing by blocking resource-hogging ads and trackers. On the other hand, the restraints imposed by Manifest V3 will cause broken functionality and degraded performance for common extension tasks.
While a persistent extension background page will continue to use memory as long as your browser is open, try opening Chrome’s Task Manager sometime. Then compare the memory consumed by each and every website you have open to the memory consumed by your (presumably far fewer) extensions. Then, if you are a user of privacy or ad blocking extensions, try disabling them and reloading your websites. This exercise should quickly put the lie to Google’s claims. The memory consumed by your various open websites—especially without the help of privacy and security extensions to block memory-intensive trackers and advertisers—should dwarf the memory consumed by the extensions themselves.

Furthermore, repeatedly starting up and tearing down service worker-based extensions will lead to greater CPU load. For example, an extension using tabs, webNavigation, or observational webRequest APIs will get constantly invoked during browsing until either the user stops browsing or the five-minute time limit is reached. When the user resumes browsing, the service worker will have to get restarted immediately. Imagine how many times such an extension will get restarted during a typical day, and to what end? Any extension that depends on relatively expensive one-time processing on startup (for example, machine learning models or WebAssembly) is an especially poor fit for service workers’ ephemeral nature.
Beyond harming performance, arbitrarily shutting down extension service workers will break functionality. The user may be in the middle of interacting with extension-provided functionality on some web page when the extension's service worker gets shut down. After a service worker restart, the extension may have stale or missing configuration data and won't work properly without the user knowing to reload the page. The additional delay caused by service worker startup will break use cases that depend on speedy messaging between the web page and the extension. For example, an extension that dynamically modifies the right-click menu based on the type of clicked element is no longer able to communicate within itself in time to modify the menu before it opens.

Regressions and bugs​

On top of everything else, Google’s rollout of Manifest V3 has been rushed and buggy. While you will no longer be able to upload new Manifest V2 extensions to the Chrome Web Store as of January 2022 (next month!), entire classes of existing extensions are completely broken in Manifest V3. As previously mentioned, observational webRequest is still broken, and so is native messaging. Manipulating web pages in the background, WebSockets, user script extensions, WebAssembly: all broken. Injecting scripts into page contexts before anything else happens (document_start “main world” injection) is also broken. This is critical functionality for privacy and security extensions. Extension developers have to resort to ugly hacks to accomplish this injection with configuration parameters, but they are all broken in Manifest V3, and the promised Manifest V3 replacement is still not available. Meanwhile, early adopters of Manifest V3 are running into bugs that cause their extensions to stop working when new extension versions are released. Even something as basic as internationalization is broken inside service workers.

Mozilla’s disappointing response​

Mozilla, apparently forced to follow in Google's wake for compatibility reasons, announced it will also be requiring extensions to switch to service workers. While Mozilla will continue to support the blocking capabilities of webRequest, in addition to implementing declarativeNetRequest, it was framed as a temporary reprieve “until there’s a better solution which covers all use cases we consider important.” Recently, in a belated sign of community feedback finally having some effect, a Mozilla engineer proposed a compromise in the form of “limited event pages”. Limited event pages would lessen the pain of Manifest V3 by restoring the standard set of website APIs to extension background pages. An Apple representative expressed support on the part of Safari. Google said no. Instead of following Google into Manifest V3, Mozilla should be fighting tooth and nail against Google’s proposal. It should be absolutely clear that Google acts alone despite overwhelmingly negative community feedback. A proposal cannot become a standard when everyone else stands in opposition. Mozilla’s behavior is obscuring Google’s betrayal of the extensions ecosystem. Moreover, it gives a false sense of competition and consensus when in reality this is one of the prime examples of Google’s market dominance and anti-competitive behavior.

Conclusion​

What is the future of extensions? As we explained in our 2019 response, removing blocking webRequest won’t stop abusive extensions, but will harm privacy and security extensions. If Manifest V3 is merely a step on the way towards a more "safe" (i.e., limited) extensions experience, what will Manifest V4 look like? If the answer is fewer, less-powerful APIs in service of “safety”, users will ultimately suffer. The universe of possible extensions will be limited to what Google explicitly chooses to allow, and creative developers will find they lack the tools to innovate. Meanwhile, extensions that defend user privacy and safety against various threats on the Web will be stuck in the past, unable to adapt as the threats evolve.
The WebExtensions standard is what we all make it to be. If we are to take the WebExtensions Community Group at face value, we should be making extensions more capable together. We should indeed be making it easier to write secure, performant, privacy-respecting extensions, but not at the cost of losing powerful privacy-preserving functionality. We should make it easier to detect abuse, but not at the cost of losing the ability to innovate. We shouldn't rely on browser developers to think of all the needs of the diverse Web, and we don't have to: that's the beauty of extensions.

The next extensions manifest version update should be opening doors to empower all of us, unconstrained by whether you can convince a few browser engineers of the validity of your needs. Google needs to cancel moving to service workers, restore blocking webRequest, and halt Manifest V2 deprecation until all regressions in functionality are addressed. Anything short of that is at best an insincere acknowledgment of developers' shared concerns, and at worst outright hostility to the extensions community at large.
Google’s Manifest V3 Still Hurts Privacy, Security, and Innovation
 
Last edited:

SeriousHoax

Level 49
Verified
Top Poster
Well-known
Mar 16, 2019
3,863
Source:
 

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
Source:
Thanks. I forgot it. Post now edited.

There is also this earlier article referenced above.
 
Last edited:

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
Sweet! Apparently, users won't be the only ones hurt by MV3. Check out this marketing company.
Adtoniq is a high-performance digital advertising platform. We connect premium advertisers with coveted audiences they cannot reach while providing brand new revenue opportunities for publishers using proprietary one-click consent™ technology. We market exclusively to people you can’t otherwise reach: ad block users who permit seeing ads on websites they choose to support.
It doesn't state the publishing date of the below blog post:
 
F

ForgottenSeer 92963

I really enjoyed reading that article :)

AdCouncil said:
Nearly all tracking services such as Google Analytics are blocked by ad blockers. Using advanced techniques, Adtoniq accurately detects and reports when an ad block user has visited a page across desktop/laptop, mobile and network blocking.

The Ad Council has created many of the most iconic campaigns in advertising history. Friends Don’t Let Friends Drive Drunk. Smokey Bear. Love Has No Labels. Its innovative social good campaigns raise awareness, .... including creative for COVID-19 awareness,

Results:

  • 0.38% CTR (652% increase from average Ad Council display campaign )
  • CTRs as high as 1.85% on some websites (3,561% CTR increase from average Ad Council display campaign)
  • Reaching the otherwise unreachable 20-30% of the internet using ad blockers

AdBlocklists which focus on the large advertising networks (like Disconnect, Ghostery, Privacy Badger) and large blocklists with those networks included (like Easylist link and AdGuard link) are likely to block the top 3000 advertising & tracking networks. This means that ad networks with low presence on Alexa 1 million websites have a fair chance of passing the blocklists.

When there is less noise (competing ads fighting for screen space), your ads have greater attention value, when the message serves a social purpose, people will be more willing to read the message (longer span of attention) and when it appeals (like Covid awareness campaign) click on it, achieving higher Click Through Rates than any other campaign.

I am really surprised. :D
 

Gandalf_The_Grey

Level 83
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
7,364
I really enjoyed reading that article :)



AdBlocklists which focus on the large advertising networks (like Disconnect, Ghostery, Privacy Badger) and large blocklists with those networks included (like Easylist link and AdGuard link) are likely to block the top 3000 advertising & tracking networks. This means that ad networks with low presence on Alexa 1 million websites have a fair chance of passing the blocklists.

When there is less noise (competing ads fighting for screen space), your ads have greater attention value, when the message serves a social purpose, people will be more willing to read the message (longer span of attention) and when it appeals (like Covid awareness campaign) click on it, achieving higher Click Through Rates than any other campaign.

I am really surprised. :D
What does that mean for the optimized lists maintained by AdGuard you (and I) are using?
Would it be better to use the large non-optimized lists?
 

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
A new post:

gorhill commented yesterday

An example that the declarativeNetRequest ("DNR") API is an obstacle to innovation in content blockers.
In discussion with filter list maintainers, last year I implemented a new feature, the ability to use "entity" in domain= option.[1] The DNR API does support domain= option, but it does not support "entity", which is the ability to use a wildcard in place of the effective TLD, to avoid to list all domains belonging to an entity.[2]
I can count over 420 filters currently in the default filterset which uses this feature, clearly a benefit to filter list maintainers. These filters would cease to exist in a DNR-based blocker.
The core issue is the lid on innovation, which is key for content blocker to stay reliable. If the DNR API had been designed in 2014 according to the requirements of the time, content blockers would be awfully equipped to deal properly with the current landscape. The DNR API as designed now not only set back content blockers, but condemn content blockers to stagnate innovation-wise.

[1] Static filter syntax · gorhill/uBlock Wiki
[2] #1008 (comment)
Note: Italics are mine.
 

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673

Most of this piece is much like a summary of older info like past articles, etc. There is also this bit at the end:

The Mountain View​

For its part, Google – preferring to be paraphrased rather quoted directly – told The Register that the W3C group was formed in June and so it's premature to judge the impact of discussions. At the same time, the internet giant suggests the group has shined a light on various developer concerns and has led to efforts to look more closely at use cases that require DOM API access in service workers and persistent background processes.

The company maintains that it continues to incorporate developer feedback in the ongoing design of Manifest v3, citing as an example how the declarativeNetRequest API has been adjusted from a limit of 30,000 filtering rules per extension to a minimum of 30,000 rules plus access to a global pool that's shared across all extensions.

Other examples of APIs modified based on feedback include letting devs decide whether the method scripting.executeScript will inject a script in the extension's isolated world or in a page's main world and the introduction of an in-memory storage API called storage.session to preserve data that would otherwise be lost when a service worker shuts down.

To counter the perception that Google has it in for ad blockers, the company pointed to a 2020 blog post containing an endorsement from Sofia Lindberg, tech lead for Eyeo, maker of Adblock Plus: "We’ve been very pleased with the close collaboration established between Google’s Chrome Extensions Team and our own engineering team to ensure that ad-blocking extensions will still be available after Manifest v3 takes effect."

Eyeo's Adblock Plus is not quite the same as the open-source uBlock Origin project. It's made by an advertising company that brokers "acceptable ads." ®
And there is this humorous gem found here
Why should we care? u/MetricVeil is as mad as hell—and they’re not going to take it any more:

“Shop monster”
The internet is now a landscape for corporations to exploit. … When you go out shopping … you would be appalled if, on entering a store, an assistant came up to you, asked for your name and address, what you wanted to buy, where you had just been and where you were going after … and then proceeded to stick a label on you with those details.

By the end of your shopping trip you would look like some hairy, post-it-note covered, shop monster.
:LOL:
 
Last edited:
F

ForgottenSeer 92963

What does that mean for the optimized lists maintained by AdGuard you (and I) are using?
Would it be better to use the large non-optimized lists?
Sorry had not noticed your post, here is my late answer.

It depends on the websites you are visiting. For most websites it is far more efficient (in terms of money, IT-resources and learning curves and availability of digital marketeers to operate those advertising platforms) to use a well-known third-party who also provides open course education (like Google, facebook, Hubspot, etc) and leverage their presence with multi-site serving ad bidding systems.

Only for relatively dedicated customer scenes websites* (e.g. adult websites, dating and cam-services) it might be feasible to use own or dedicated adserving platforms. As far as I known, the adult business has matured also (meaning websites with different content and names have the same owner and therefor can share a propriety publishing and advertising platform. I think that only the adult business is (money wise) big enough to develop their own adserving platform. Ironically adult websites were the driving power behind internet usage and innovation (so it is more likely the systems developed for adult websites, were the basis for the advertising platforms we see now).

As far as I know AdGuard also includes the most used advertising platforms of the adult industry. I have copied LennyFox blocklist (link) dedicated blocklist for adult advertising services in my list. When I checked LennyFox's blocklist (he made for his brother he always told me :) ) against EasyList more than 50 percent of the domains mentioned in his list were not present in EL, for fun I checked his list against Adguard optimized AG-base + EL and noticed that all except three or four were blockd by AG optimized.

So I would say NO, the most efficient largelist approach (in terms of block percentage vs number of rules) IMO still is (by far):
- AG optimized Base +EasyList (link)
- AG optimized TrackingProtection and EasyPrivacy (link)
- AG remove URL tracking parameters (link)
- your country specific EL or AG blocklist

*) dedicated customer scene: meaning most wide audience products/services have no business or do not want to advertise on those websites (e.g. Nespresso probably does not want to advertise on a adult website)
 
Last edited by a moderator:

Gandalf_The_Grey

Level 83
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
7,364
So I would say NO, the most efficient largelist approach (in terms of block percentage vs number of rules) IMO still is (by far):
- AG optimized Base +EasyList (link)
- AG optimized TrackingProtection and EasyPrivacy (link)
- AG remove URL tracking parameters (link)
- your country specific EL or AG blocklist

*) dedicated customer scene: meaning most wide audience products/services have no business or do not want to advertise on those websites (e.g. Nespresso probably does not want to advertise on a adult website)
Thanks Kees (y)

- AG optimized TrackingProtection and EasyPrivacy (link)
- AG remove URL tracking parameters (link)
Those are the same as the already buit-in AdGuard filters under privacy AdGuard Tracking Protection and AdGuard URL Tracking Protection?

Prefer the Dutch AG list over the Dutch EL because the EL gives adblocker detected on ah.nl and looopings.nl but the AG version doesn't have that problem.
 
F

ForgottenSeer 92963

Thanks Kees (y)

- AG optimized TrackingProtection and EasyPrivacy (link)
- AG remove URL tracking parameters (link)
Those are the same as the already buit-in AdGuard filters under privacy AdGuard Tracking Protection and AdGuard URL Tracking Protection?

Prefer the Dutch AG list over the Dutch EL because the EL gives adblocker detected on ah.nl and looopings.nl but the AG version doesn't have that problem.
Yes, just enable optimized filters (y) (I added the links for uBlockOrigin users).
 

Gandalf_The_Grey

Level 83
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 24, 2016
7,364
Why can I not find 'AG optimized TrackingProtection and EasyPrivacy' at FilterLists | Subscriptions for uBlock Origin, Adblock Plus, AdGuard, ...
They were there yesterday (not optimized), but now not anymore. 😢

AdGuard filters have a very easy structure: https://filters.adtidy.org/extension/ublock/filters/14_optimized.txt Annoyances is nr. 14 and for optimized add _optimized

These are the six filter I use:
2 = AdGuard Base filter + EasyList
3 = AdGuard Tracking Protection filter
4 = AdGuard Social Media filter
8 = AdGuard Dutch filter
14 = AdGuard Annoyances filter
17 = AdGuard URL Tracking filter
 

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
Here is a glaring example of the MV3 disaster that has been slowly unwinding:
Will the proposed Manifest V3 changes to Chrome break Privacy Badger? · Issue #2273 · EFForg/privacybadger

sillyjaybird commented 16 hours ago •​

edited​

@ghostwords I'm finding little current info on MV3 generally and wondering if you've learned anything new about it's impact on Privacy Badger? Is any work being done to develop a POC/ MV3-compliant version of the extension?

ghostwords commented 2 hours ago
edited
You can read our latest update on the EFF blog, Google’s Manifest V3 Still Hurts Privacy, Security, and Innovation. While the post doesn't go into Privacy Badger specifically, we talk about what happened around Manifest V3 in the last two years, what's (still) wrong with it, and how it could be better.
I have been participating in the W3C WebExtensions Community Group to advocate for extension developers and to raise awareness of the many problems with Manifest V3.
Privacy Badger in Manifest V3 is blocked by at least one (long-outstanding) bug, Chromium Issue 102421: webRequest listeners not called after service worker stops.
👍1


Sign up for free


ssue 1024211: Manifest V3: webRequest listeners not called after service worker stops​

Reported by kdzwinel@gmail.com on Wed, Nov 13, 2019, 4:54 AM PST
linkCode

Description #1 by kdzwinel@gmail.com (Nov 13, 2019)
Chrome Version : 80.0.3966.0
OS Version: OS X 10.15.1
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari:
Firefox:
IE/Edge:

What steps will reproduce the problem?

1. Install attached extension
2. Navigate to example.com - you should be redirected to https://example.com at DuckDuckGo (correct behavior, extension redirects all top level navigations to duckduckgo.com)
3. Minimize the browser and wait two minutes w/o using it
4. Try navigating to example.com again

What is the expected result?

As in #2, you should be redirected to https://example.com at DuckDuckGo .

What happens instead of that?

You are not redirected and example.com website loads normally.

Please provide any additional information below. Attach a screenshot if
possible.

Extension is using Service Worker based background page (part of the Manifest v3 effort).

chrome.webRequest.*.addListener calls should wake up the stopped service worker (background page). This does not happen.


UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3966.0 Safari/537.36
mv3-sw-fail.zip
17.5 KB
Download
Comment 1 by mmenke@chromium.org on Wed, Nov 13, 2019, 10:02 AM PST Project Member
Components: Platform>Extensions>API Blink>ServiceWorker

Comment 2 by penaganti.ganga@chromium.org on Wed, Nov 13, 2019, 8:14 PM PST Project Member
Labels: Needs-Triage-M80

Comment 3 by vanditha.podduturi@chromium.org on Thu, Nov 14, 2019, 4:47 AM PST Project Member
Cc: vanditha.podduturi@chromium.org
Labels: Triaged-ET Needs-Feedback
Tested the issue on reported chrome version #80.0.3966.0 using Mac OS 10.13.6, by the following steps
Steps:
---------
1. Installed attached extension
2. In "chrome://extensions", it is showing "Errors".
3. Navigate to example.com, clicked on More Information- redirected to "iana.org/domains/reserved"
4. Minimized the browser and waited two minutes.
5. Tried navigating to example.com again, after clicking More Information- redirected to "iana.org/domains/reserved".

Attached screen-cast for the reference.
@Reporter: Could you please review the attached screencast and let us know if we missed anything from our end. Confirm if this is the issue you are pointing to.
Thanks
1024211.mp4
6.8 MB
ViewDownload
Comment 4 by kdzwinel@gmail.com on Thu, Nov 14, 2019, 7:12 AM PST
Hey @vanditha.podduturi thanks for a quick response. It looks like the extension didn't work correctly for you. When you first navigated to example.com it should have redirected you to duckduckgo.com . Please see my screencast below that shows the problem.
mv3-sw-failure.mov.mp4
3.1 MB
ViewDownload
Comment 5 by sheriffbot@chromium.org on Thu, Nov 14, 2019, 7:14 AM PST Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit Sheriffbot: Auto-triage Rules for Bugs - The Chromium Projects - Your friendly Sheriffbot

Comment 6 by karandeepb@chromium.org on Thu, Nov 14, 2019, 11:54 AM PST Project Member
Status: Assigned (was: Unconfirmed)
Owner: lazyboy@chromium.org
Cc: dbertoni@chromium.org
Labels: Pri-2
Assigning to Istiaque since this is related to extension SW.

Comment 7 by lazyboy@chromium.org on Mon, Nov 18, 2019, 1:34 PM PST Project Member
Owner: dbertoni@chromium.org
Dave, can you take a look?
SWs stopping isn't tested much in SWTQ atm, so this sounds like something we want to take a look at sooner rather than later.

Comment 8 by sime...@chromium.org on Wed, Dec 11, 2019, 6:51 PM PST Project Member
Cc: sime...@chromium.org
This may be an instance of a broader set of bugs around waking up service workers; I recall there also being issues with extension service workers waking up in response to extension events like nativeMessaging (1030305) or standard web platform events such as self.addEventListener('message', () => {}) (I'm not sure if this is bugged).

Comment 9 by woxxom@gmail.com on Wed, Dec 11, 2019, 9:30 PM PST
FWIW, this seems like an architectural peculiarity/bug of webRequest API, see bugs 119613, 119614 for more details.

Comment 10 by dbertoni@chromium.org on Thu, Oct 29, 2020, 2:37 PM PDT Project Member
Labels: ExtensionServiceWorker

Comment 11 by eugen...@gmail.com on Wed, Feb 10, 2021, 5:23 AM PST
I encountered the same issue reported by kdzwinel@gmail.com.

Chrome Version: 88.0.4324.150
OS Version: Windows 10 Pro 10.0.19042

Are there any updates?

Comment 12 by swarnasree.mukkala@chromium.org on Sun, Feb 14, 2021, 9:00 PM PST Project Member
Cc: swarnasree.mukkala@chromium.org phanindra.mandapaka@chromium.org
Issue 1177197 has been merged into this issue.

Comment 13 by sime...@chromium.org on Wed, Feb 17, 2021, 2:09 PM PST Project Member
Labels: Pri-1

Comment 14 by wanderview@chromium.org on Mon, Mar 15, 2021, 1:16 PM PDT Project Member
Components: -Blink>ServiceWorker
This seems predominantly an extensions issue so dropping service worker component for now.

Comment 15 by chris...@hiregiraffe.com on Mon, Apr 12, 2021, 11:04 AM PDT
Encountering the same issue here as well where addListener calls do not wake up the stopped service worker for my extension. In this case, the duration before the sw becomes "unresponsive" is ~60 minutes. Has there been progress on the resolution of this issue since last month?

Comment 16 by brows...@gdata.de on Thu, May 6, 2021, 3:04 AM PDT
This prevents us from porting our g data web extension and we will have to stay with MV2 until it is resolved

Due to the missing requests when restarting the extension, malware content can get through once without being checked and consequently the web protection is then dropped for this request. This is currently shown by our tests for the web extension that malware pages or content can no longer be verified if the extension was inactive.
2021-05-06 12-03-42.mp4
458 KB
ViewDownload
Comment 17 by koyno...@gmail.com on Fri, Aug 13, 2021, 1:41 PM PDT
Whoa, this bug is almost 2 years old and still is unresolved.
Comment 18 by rdevl...@chromium.org on Fri, Aug 20, 2021, 10:54 AM PDT Project Member
Owner: karandeepb@chromium.org
Cc: lazyboy@chromium.org

Since this is webRequest related, this might be something karandeepb@ can look at. Karan, mind doing some initial investigation? (Feel free to pass along back to Dave or Istiaque if it's more SW than webRequest)

Comment 19 by eada...@walkme.com on Mon, Aug 30, 2021, 8:39 AM PDT
Any news about this one? This is really preventing us from converting to manifest v3

Comment 20 by pramo...@quillbot.com on Tue, Sep 14, 2021, 5:28 AM PDT
How long is it going to take? We're forced to go back to MV2.

Comment 21 by jvani...@sitespect.com on Tue, Sep 14, 2021, 7:12 AM PDT
This is preventing me from updating an extension to the new manifest. We need webRequest to check requests actively. Not for a short moment. Very strange this has not been picked up while the issue was described 2 years ago..

Comment 22 by karandeepb@chromium.org on Fri, Oct 8, 2021, 4:35 PM PDT Project Member
Owner: lazyboy@chromium.org

Over to Istiaque.

Comment 23 by z.yin...@gmail.com on Sun, Oct 10, 2021, 6:16 PM PDT
I also encountered this issue, with one difference: folks above have mentioned that their sw can stay active for 15 mins or 1 hour, but mine can only stay active for <20 seconds. Maybe it's due to my hardware, or newer chrome version? I use `chrome.webRequest.onSendHeaders` listener, and it stops triggering after ~20 seconds or so, unless I keep the sw devtools open.

Comment 24 by rjk...@gmail.com on Fri, Oct 22, 2021, 11:44 PM PDT
I'm in the exact same boat! My entire service worker file simply consists of a call to chrome.webRequest.onSendHeaders.addListener, and it's not working unless I manually activate the service worker from the dev tools pane, by clicking on "Service Worker (Inactive)." I suppose that my only option for now is to downgrade to Manifest v2? Why even push Manifest v3 if it's not working for such an essential feature?

Comment 25 by jvani...@sitespect.com on Wed, Dec 1, 2021, 11:47 PM PST
Today got the mail about the ending ov manifest V2 support. Any developers of chrome not forgetting this issue exists? It's pretty big for allot of developers. Why is there no response, or any progress??

@lazyboy @Istiaque @karandeepb

This issue has been very clear over 2 years!

Comment 26 by allen...@gmail.com on Sat, Dec 11, 2021, 2:34 PM PST (29 days ago)
Can we get an estimated time frame for how long this will take? I just developed an extension in manifest v3 and am now forced to downgrade to v2. I'm trying to decide if it's worth downgrading or if I should just wait for this issue to be resolved.

Comment 27 by felix...@gmail.com on Tue, Dec 14, 2021, 4:47 PM PST (26 days ago)
Pretty surprised to see such a major flaw in MV3 support when attempting to upgrade from Manifest V2.
Workers not waking up must be a painful issue to debug. Anyone found a workaround to support
chrome.tabs.onUpdated.addListener?

Comment 28 by rdevl...@chromium.org on Thu, Dec 16, 2021, 3:31 PM PST (24 days ago) Project Member
Cc: rdevl...@chromium.org


Comment 29 by adamd...@gmail.com on Sat, Dec 18, 2021, 3:48 AM PST (23 days ago)
Sadly have to downgrade to v2 just because of that. Would love to see the fix asap.

Comment 30 by jen...@gmail.com on Tue, Jan 4, 2022, 11:52 AM PST (6 days ago)
Any update on this?
If I can't keep a persistent chrome.webRequest.onCompleted listener running my extension is simply crippled.
I will rebuild everything in v2, but since v2 is not longer supported in less than a year and half I hope this will not cripple me later. I put a lot of effort in my extension.
 
Last edited:

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
... and today we have just one example of the problems developers are encountering trying to develop POC extensions migrating from MV2 -> MV3. Kind of a fun read if you like building tracks while operating the train! ;):LOL:
 

oldschool

Level 85
Thread author
Verified
Top Poster
Well-known
Mar 29, 2018
7,673
A very thorough explanation of MV3's impact on Ghostery, discussion of alternative implementations and the overall implications for users, adblockers and other developers. I recently found this but have no idea when it was first published.

Interested members may follow discussions of MV3 technical issues here: Issues · w3c/webextensions
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top