Chrome extension manifest v3 proposal

[greghuc]

Description

This issue is a heads-up on the proposed Chrome extension manifest version 3, which will have a significant impact on ad-blockers.

There is a tracking bug at: https://bugs.chromium.org/p/chromium/issues/detail?id=896897

In-progress design doc: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#

Might be worth a review, and giving feedback via the tracking bug.

regarding all dev. on dnr - https://bugs.chromium.org/p/chromium/issues/list?can=2&q=declarative+net+request

"Migrating to Manifest V3" (timeline) - https://developer.chrome.com/extensions/migrating_to_manifest_v3

[baraa272]

@baraa272 That's what I use on desktop. No android version, unfortunately

Sent from my TETRA using FastHub

theres waterfox in play store lol but I wont recommend it Just Use Brave in android its the best

[gorhill]

I am supposed to comment in the Google Groups thread how uBO is affected specifically, so I should spent some time to gather all the details about how the ABP-like matching engine does not cut it for uBO.

But as observed by @joey04 above, the biggest setback is that the API is declarative, all the rules are to be shipped in a JSON file in the extension.

How do you create custom filters? How do you point-and-click to create a rule which override one from a 3rd-party list? Etc.

The declarativeNetRequest API is actually really a replacement for declarativeWebContent (which has been lingering in beta for years). You can't replace a non-declarative API, webRequest, with a declarative one -- this makes no sense. The fact that declarativeNetRequest is presented as a replacement for webRequest tells me I would be just wasting time at this point.

I will keep watching the design doc to see if there is any meaningful change of interest to uBO.

[gorhill]

Can you guys please stop posting off-topic comments? This issue is about "Chrome extension manifest v3 proposal". I am interested only in comments which specifically address the Chrome extension manifest v3 proposal.

[gorhill]

https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/veJy9uAwS00/7Y7jVLTCGgAJ:

Because of this, we are certain that we will need to keep the webRequest API around. We are discussing limiting its capabilities, though these exact limitations are still being discussed (and is the main reason we are gathering feedback about what can/cannot be accomplished today with declarativeNetRequest).

So maybe there is hope, ideally of course would be to keep the webRequest API as is.

[gorhill]

Thomas Greiner makes a good point:

Finally, I'd like to point out that due to the ever-evolving nature of the Web, it's quite tricky to provide specific examples for features that will be required from such a content filtering engine to provide a good enough quality

Example which came to mind is the new csp= option. We couldn't predict that the need for such an option would come up, it's the result of trying to find solutions to what web sites throw at users through their browser.

[mapx-]

S. Noack (ABP / eyeo) https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/veJy9uAwS00/CxEIxy_OGgAJ

[okiehsch]

Adblock/Plus can't be happy with the proposed changes, the 30,000 filters limit would cripple all ad/content-blockers and I really don't understand how nobody responsible for the draft proposal saw that beforehand, even Apple has a 50,000 limit which is bad enough.

[okiehsch]

By the way, Mozilla has also announced that they will transition to manifest v3 in 2019. https://blog.mozilla.org/addons/2018/10/26/firefox-chrome-and-the-future-of-trustworthy-extensions

They obviously do not have to use Chromium's version, but ....

[gwarser]

... they begin to prepare the ground

https://old.reddit.com/r/firefox/comments/aithmh/raymond_hill_creator_of_ublock_origin_ubo_and/eerce78/

[okiehsch]

I would not be surprised, the goal of the migration to a WebExtensions API was to simplify cross-browser development by providing commonly-supported methods and interfaces. Adding a different manifest works against that stated aim.

[gorhill]

they begin to prepare the ground

Excerpt from the comment:

an extension will directly impact the amount of memory required

Pervasive bloated web sites is where the performance issue is. Content blockers are the solution for this. Anybody can see for themselves by loading a web page from most of almost any top site, and see the result with uBO enabled, and the result without uBO enabled. And somehow we are being misled to believe content blockers need fixing, while they are the solution to the rampant bloat (leaving aside the privacy nightmare of those bloated sites and the ubiquitousness of facebook.com, twitter.com, google.com, et al. as 3rd parties)

[gorhill]

More interesting feedback in the discussion thread, which make me realize more issues than just a non-working webRequest API.

Here is another issue raised by others: the replacement of background pages with ServiceWorkers. My immediate understanding of this is that uBO won't be able to use document.createElement in its mani process. uBO uses this API to:

• Create a div element which purpose is to detect whether a cosmetic filter is valid (code)
• Create a script element to create dynamic content script which purpose is to wrap scriplet injection code (code)

The former is not trivially replaceable. Not sure how this would be fixed, if possible at all. The second might be fixable through some proposed dynamic content script API talked about in the design document.

[mapx-]

https://groups.google.com/a/chromium.org/forum/#!msg/chromium-extensions/qNqURIh4Nss/mjJ5npmAHAAJ

You could add your thoughts here @gorhill , for example about the maximum number of rules, dynamic rules etc

[gorhill]

I already did leave feedback in the other official thread.

[gwarser]

https://groups.google.com/a/chromium.org/forum/#!msg/chromium-extensions/veJy9uAwS00/_mP63xBXAwAJ

Hi, Cliqz engineer here. We released a study about content-blockers performance today and found that the performance of the most popular ones is not an issue: https://whotracks.me/blog/adblockers_performance_study.html

TL;DR: they are all very efficient, having median decision times per request anywhere between 7 μs and 1 ms (depending on the extension), which is at least three orders of magnitude less than the requests themselves. Their performance is also continuously evolving thanks to the innovations and hard work of developers, browser improvements, technologies like WebAssembly, etc. and we do not see how this will cause an issue in the future.[...]

[okiehsch]

First "official" response.

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/WcZ42Iqon_M

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.)

[uBlock-user]

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.

So we will still be able to add filters to my Filters in uBO ?

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.

That sounds like modifying the response, no ? HTML Filtering ?

[gorhill]

That sounds like modifying the response, no ? HTML Filtering ?

No, just some response headers, they will pick which ones can be modified.

Still no word on the nature of the matching algorithm -- Easylist-like matching algorithm does not work for uBO's dynamic filtering and uMatrix as a whole.

Strict blocking needs to generate a page on the fly according to what happened filter-wise, this can't happen with a declarative API.

Solution is incredibly simple, just keep the blocking ability of the webRequest API. Nothing of what was said in the post still properly justify removing this ability -- it's really, really hard to not suspect the real reasons are not technical neither altruistic.

The "push-only" nature of filter lists is a sound argument, but that is not a browser issue, this is an issue to be tackled by filter list maintainers and content blocker developers.

And as I already argued, one can use uBO without any filter lists in default-deny mode, but that would go away with an Easylist-like matching algorithm, so such worries can't be genuine when they remove the ability for a content blocker to not rely on any filter list.

With the declarativeNetRequest API, not only the browser gets to decide the limit on how matching algorithm work, but will also be in a position to collect what exact filter triggered a block. Content blockers using a still-working webRequest API would get in the way of this because the browser can only know that something was blocked, not what exactly caused the blocking.

Users are free to install whatever content blocker they wish, and they will be free to install the declarativeNetRequest-based ones if they are convinced by the arguments out there of why it's best for them. The only reason I can see for removing the blocking ability of the webRequest API is that it might interfere with the spread of content blockers relying on the declarativeNetRequest API because the webRequest ones will still give users greater agency.

[gorhill]

As I am looking at what I should work on, I found a typical example of how manifest v3 will be crippling for new content blocking ideas. Consider this feature request. Possible with a proper blocking webRequest API with which no specific matching algorithm is enforced. Not possible with declarativeNetRequest API, where the only matching algorithm available is meant to enforce only EasyList-like filter syntax.

[uBlock-user]

You should let them know about this and other breakages.

[gorhill]

I already said this would break uBO's dynamic filtering and uMatrix as a whole, and nothing of what was said a few days ago addressed this -- it's as if I never mentioned this. The reality is that content blockers on Chromium will have to open issues on Chromium issue tracker and wait (possibly forever) when they want something more than what the declarativeNetRequest API allows. The issue I am giving is just an example of a new feature that might be wanted in some future which is entirely possible with a blocking webRequest API, but not possible with limited declarativeNetRequest.

My view is that I don't think there is a genuine exchange going on with their requests for feedback, the decision of Google-paid developers is made regarding the removal of the blocking ability of the webRequest API. I rather not waste my time being part of a pretend discussion, the declarativeNetRequest API was designed to enforce EasyList-like filtering[1].

[1] I will do my best to not use "ABP-like" as I used to do because people have read more into this expression than they should have, despite that EasyList is completely dedicated to enforce only ABP's filtering syntax.

[gorhill]

I remember there was a Chromium script blocker extension a long while ago (I don't know if it still exists) which I can't remember the name, and it had a feature which I found interesting, and thought it might be worth borrowing the idea at the time (as opt-in).

The script blocker would block all 3rd-party scripts, except those which domain name was close enough to that of the first party site. I don't think it was literally the case but let's say it was using Levenstein distance to determine whether a 3rd-party script should be blocked or not.

The idea was interesting because this was helping in reducing the amount of breakage as a result of blocking 3rd-party scripts -- thus increasing script blocking usability to more people. For example, arstechnica.net is close enough to arstechnica.com, and thus the site wouldn't break with that script blocker.

Whether one agree this is a good idea or not is irrelevant, the point is that its blocking heuristic was original and of course it could be implemented because of the webRequest API. Forget such new ideas with a declarativeNetRequest API.

[gorhill]

Feedback from the ad blocking community on the proposed changes to the webRequest and declarativeNetRequest APIs

[baraa272]

a sight of hope https://www.zdnet.com/article/google-backtracks-on-chrome-modifications-that-would-have-crippled-ad-blockers/

[DavidJCobb]

a sight of hope

That article is misinformed. The only thing Google said after being caught lying about the performance issue, and the only thing quoted in the article, is

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).

and this is the same disingenuous rhetoric that Google has been using the entire time. People's concern is with the removal of specific functions and features in the webRequest category, and Google has consistently been trying to dodge that by saying, "Don't worry, everyone. There will still be a category of functions that happens to be named 'webRequest.'" They blatantly have no intention of backing down from this no matter how many people object to it, and no matter how many times they're caught lying about it.

[jsEveryDay]

I feel like the changes are already happening. Since chrome 72 I feel like uBlock became less effective. A tiny extension that I wrote also broke. Turn's out, you're no longer allowed to drop the Referrer, you can only replace it. Stupid. Also somehow connections to gvt1.com have increased and google is able to make it through even though its blocked on local dns. Version 72.0.3626.119 (Official Build) (64-bit)

Eventually we need to leave chrome behind. Hopefully Microsoft will make us proud this time. Other chromium based browsers are full of social connectors which keep pinging fb and others constantly (Opera, Vivaldi). Firefox is not great either but that might be the next best option.

[vitorgalvao]

Hopefully Microsoft will make us proud this time.

I doubt it. Microsoft dropped the towel. They’ll eat whatever the Chromium teams gives them.

Other chromium based browsers are full of social connectors which keep pinging fb and others constantly (Opera, Vivaldi).

I’ve never heard that claim regarding Vivaldi, and I’ve been researching the browser extensively as of late. Do you have a source for that claim?

[mapx-]

Vivaldi is open on privacy: https://www.ghacks.net/2018/01/30/vivaldi-browser-privacy/

[jsEveryDay]

@vitorgalvao Just listen on the requests you'll see. It's been awhile since I checked it but I did follow up with it and I remember them mentioning it was due to funding/sponsorship.

[gorhill]

Firefox is not great

Why is this? uBO works best in Firefox.

[vitorgalvao]

Why is this? uBO works best in Firefox

I think @jsEveryDay is making a commentary on browser policy (“Opera and Vivaldi do some shady things and Firefox isn’t that far behind on its practices”), not on browser technology.

[jsEveryDay]

@vitorgalvao I'm only seeking alternatives and asking where the community is headed.

[uBlock-user]

Community is not headed anywhere specifically and is waiting for the final draft to see how it all ends up.

[ghost]

Will Declarative Net Request API be able to modify request and response headers to bypass CORS and access remote content that extension has permission to access ?

We have developed and used various automation tools that heavily rely on modifying request and response headers to send automated web requests to web servers.

Therefore I am hoping that Declarative Net Request API will support

• modifying request and response headers.
• adding new request or response headers.
• removing request or response headers.

There are countless web automation tools deployed on the web that rely on modifying request and response headers.

Apart from automation tools, there are many other legitimate use cases for modifying request or response headers, for example: chrome extension to change user agent.

At the moment there are millions of users that make use of web automation tools.

If Declarative Net Request API fails to add support for modifying headers and webRequest API is phased out then many web automation tools will stop working.

[gorhill]

@drbcode I have nothing to do with Chromium development, this is not the place to ask questions about manifest v3. Follow the links in the opening comment for where to provide feedback to Chromium development.

[ghost]

@gorhill , yes the comment is off-topic. But understand the severity of this issue.

U-block will also not be able to modify sensitive headers such as origin or cookies which means it is going to affect U-block and thousand other chrome extension that rely on correctness of origin header to make automation tools.

For example, some extension might have functionality to not let malicious sites access sensitive headers such as cookies, this functionality will cease to exist.

I'm just trying to create enough buzz to let everyone know what is coming!

[uBlock-user]

I'm just trying to create enough buzz to let everyone know what is coming!

That's already done when the thread was created what you're creating is notifications to all the people who replied here which in turn causes annoyances as there's no new development regarding this only your speculations along with others.

[uBlock-user]

Update from Simeon Vincent - https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!topic/chromium-extensions/veJy9uAwS00%5B101-125%5D

Hey extensions developers, I'd like to respond to some of the feedback we’ve gotten on the proposed changes in Manifest V3. A number of issues raised by the community were captured in the Privacy Badger team's April 19th post in this thread. Rather than address specific points line by line as I often do on the group, I'll be responding to the broader issues they and others have raised. I'd like to extend my thanks to the EFF and others for taking the time to share their feedback with the community. Writeups like these are truly invaluable as they help us understand not only your concerns, but also the context in which those concerns are rooted. Our goal is to create the best extensions platform we can for our mutual users. **Manifest V3 Design Doc and Development** Like most other Chromium design docs, the Manifest V3 doc is the starting point from which implementation work begins. These docs capture the context, motivations, and high-level technical notes on what the feature team plans to implement. They're generally targeted at other Chromium contributors and meant to help clarify what the team will be working on. Chromium design documents are not a final specification of what will be implemented, nor an API contract that downstream developers can rely on. Additionally, Chromium design documents are not typically updated as designs are polished, features are implemented, and details change. I mention this because I want to emphasize that the Manifest V3 design document is not exhaustive or immutable. The extensions team is pursuing the goals outlined in this design document and iterating on design and implementation details. The best way for developers to really understand the changes is to experiment with the Manifest V3 platform. To enable this, the extensions team is currently working on a Developer Preview of Manifest V3. Our goal with this preview is to give developers a way to start experimenting with some of the most significant changes to the platform in order to provide targeted feedback. We're hoping to land this in Canary in the next few months. We'll share more details about the preview in the Chromium Extensions Google Group once we get closer to launch. **Permissions** The Privacy Badger team touched on a number of permissions-related issues. Before we get into those issues, I want to address a slight misunderstanding. Chrome is not deprecating in Manifest V3, but we are changing how it works. Our primary motivation here is to give end-users more control over where extensions can inject themselves. The current extension installation flow allows developers to declare that they require access to a given set of hosts and the user must choose whether to grant all required permissions or cancel the installation. We are planning to modify the install flow so the user will be able to choose whether or not they want to grant the extension the ambient host permissions it requested. We're still iterating on the updated UI and will share additional details once this lands in Canary. Our view, informed by data from the field, is that host permissions are powerful enough that we should work to ensure that users clearly understand when they are making that specific grant. While there are legitimate reasons for extensions to use this power well, we know that other extensions have abused the same power. It is our goal to reduce the risk of abuse while still enabling users to make use of good powerful extensions. We believe Manifest v3 and the permission-granting UX strike a better balance. We recognize that this kind of functionality is core to some extensions, so we provide the tools necessary to programmatically request host permissions if the user does not opt in at install time. Developers can retrieve the extension's current permissions grants using chrome.permissions.getAll() and can request host permissions or optional permissions declared in the extension's manifest using chrome.permissions.request(). We should all want users to think hard about granting broad permissions that can compromise user security and to be able to retake control for any reason. If the user doesn't want to grant an extension a given capability, it's the extension developer's responsibility to explain why those capabilities are critical and to earn the user’s trust. **Observation** Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments). Extensions with appropriate permissions can still observe network requests using the webRequest API. The webRequest API's ability to observe requests is foundational for extensions that modify their behavior based on the patterns they observe at runtime. **Improvements to the declarativeNetRequest API** Since the community started sharing feedback on the Manifest V3 design document, the extensions team has listened to developer concerns and made improvements to the declarativeNetRequest (DNR) API. We're still actively gathering feedback, designing, and expanding the DNR API. Please continue to share your concerns and use cases in order to help us make DNR the best it can be. **General Improvements** The first and IMO largest change is that Chrome now has support for dynamic modification of DNR rules via the getDynamicRules(), addDynamicRules(), and removeDynamicRules() methods. DNR has two groups of rules: static rules declared in JSON files and dynamic rules set at runtime. Each of these groups has their own distinct maximum number of allowed rules. These current placeholder max values are specified in the DNR properties documentation. We are planning to raise these values but we won't have updated numbers until we can run performance tests to find a good upper bound that will work across all supported devices. Developers have clearly shown that they need metrics on rule matching in order to effectively maintain their rulesets. In order to facilitate this use case, the extensions team is also planning to add reporting to the DNR API. We're still working on the design of this feature and hope to share more in the coming months. **Header Modification** The extensions team recently added support for a new DNR action called removeHeaders which can remove allowlisted headers from requests. This allowlist currently includes Referer, Cookie, and Set-Cookie headers. We welcome feedback from developers on other headers that should be removable. Removing headers from a request should neither reduce the security of sites (e.g. CSP) nor expose user data. The extensions team is also planning to add support for static header additions and replacements. Additions would add new headers or extend existing headers. For example, an extension could add additional restrictions to CSP rules or add a new Set-Cookie header. Replacements would behave similar to the removeHeaders action, but rather than removing matching header(s) it would replace the header(s) with the header(s) specified in the rule's action. Again, we welcome developer feedback on this plan. As for setting Do Not Track headers, Chrome already allows users to set DNT values via their preferences. Rather than modify the DNT header directly, the team is currently leaning towards exposing an extension function to modify this user preference. This approach allows Chrome to avoid situations where multiple extensions replace the request's current DNT header with DNT: 1. **URL Parameter Modification** While we don't currently have actions for removing or replacing query parameters, the extensions team is planning to add support for both of these. I'm a little confused by the suggestion that "declarativeNetRequest should allow the modification and deletion of POST parameters as well as GET parameters." It's not clear to me whether the Privacy Badger team is asking to modify the body of POST requests or the query parameters of POST requests. Query parameters of POST requests should be modifiable like any other request type. Body modification is not currently supported by webRequest and as such the team does not currently plan to implement it for DNR. If this is something you'd like to see supported, please share more information about your use cases. The extensions team is also interested in hearing more about request parameter transformation use cases. **Contextual redirects** We are currently examining our options for redirect URL transformations. If/when transformation lands, it should be possible to convert https://www.google.com/url?q=https://example.com into https://example.com by matching the q parameter in the original request and using that as the new URL value. Yegor's example in the Google Group post is trickier because it requires additional processing to generate a usable value. Situations like this are currently out of scope. That said, we'd love to hear more about use cases and what support might look like. Thank you all for working with us on the Manifest V3 effort. We're looking forward to continuing to collaborate with the community to build a safer, more secure extensions platform.

[gorhill]

Update from Simeon Vincent

Summary

The blocking ability of the webRequest API is still deprecated, and Google Chrome's limited matching algorithm will be the only one possible, and with limits dictated by Google employees.

It's annoying that they keep saying "the webRequest API is not deprecated" as if developers have been worried about this -- and as if they want to drown the real issue in a fabricated one nobody made.

until we can run performance tests

Web pages load slow because of bloat, not because of the blocking ability of the webRequest API -- at least for well crafted extensions. Furthermore, if performance concerns due to the blocking nature of the webRequest API was their real motive, they would just adopt Firefox's approach and give the ability to return a Promise on just the three methods which can be used in a blocking manner.

Personal view on this

What we see are the public statements, for public consumption, they are designed to "sell" the changes to the wider public. What we do not see is what is being said in private meetings by officers who get to decide how to optimize the business. So we have to judge not by what is said for public consumption purpose, but by what in effect is being done, or what they plan to do.

This is how personally I see the deprecation of the blocking ability of the webRequest API in manifest v3:

Excerpts from Google's 2018 10K filing (my emphasis):

ITEM 1. | BUSINESS

Google's core products and platforms such as Android, Chrome, Gmail, Google Drive, Google Maps, Google Play, Search, and YouTube each have over one billion monthly active users.

[...]

How we make money

The goal of our advertising business is to deliver relevant ads at just the right time and to give people useful commercial information, regardless of the device they’re using. We also provide advertisers with tools that help them better attribute and measure their advertising campaigns across screens. Our advertising solutions help millions of companies grow their businesses, and we offer a wide range of products across screens and formats. We generate revenues primarily by delivering both performance advertising and brand advertising.

[...]

ITEM 1A. RISK FACTORS

[...]

Technologies have been developed to make customizable ads more difficult or to block the display of ads altogether and some providers of online services have integrated technologies that could potentially impair the core functionality of third-party digital advertising. Most of our Google revenues are derived from fees paid to us in connection with the display of ads online. As a result, such technologies and tools could adversely affect our operating results.

In order for Google Chrome to reach its current user base, it had to support content blockers -- these are the top most popular extensions for any browser. Google strategy has been to find the optimal point between the two goals of growing the user base of Google Chrome and preventing content blockers from harming its business.

The blocking ability of the webRequest API caused Google to yield control of content blocking to content blockers. Now that Google Chrome is the dominant browser, it is in a better position to shift the optimal point between the two goals which benefits Google's primary business.

The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further now instrument and report how web pages are filtered since now the exact filters which are applied to web page is information which will be collectable by Google Chrome.

Side note:

eyeo GmbH (owner of Adblock Plus) is a business partner of Google (through its "Acceptable Ads" business plan), and its business share some the same key characteristics as the Google's ones above:

• It gets revenues from the displaying of ads with those with which it has a contract (Google, Taboola, etc.)
• It expressly names uBlock Origin as a risk factor to its business^[1]

The "Acceptable Ads" plan, aside being the main revenues stream of eyeo GmbH, is also a good way for Google to mitigate against the expressed concerns in its 10K filing regarding content blockers.

---

[1] In its 2016 annual report filed on https://www.unternehmensregister.de/ureg/.

[gorhill]

Google relents slightly on blocking ad-blockers – for paid-up enterprise Chrome users, everyone else not so much

Google could just adopt Firefox's approach which uses a technique called Promises to return a non-blocking/asynchronous response.

Regarding my comment re. "Promise": Given that each extension runs in its own process, the use of Promises does not look like something that would make a difference. But this would open the door to load the filters in stages, for example a blocker could load the most likely to be hit filters at launch, and load chunks of filters least likely to be hit in an on-demand manner. The way I see it, increasing abilities of content blockers help with efficiency in the big picture. An example of this is that in order to deal with Instart Logic, an extra extension is required with Chromium, while it can be dealt with no extra extension with Firefox. Still, I just don't buy the performance argument to justify deprecating the blocking ability of the webRequest API.

[joaojeronimo]

Great news for Firefox :)

[the8472]

Regarding my comment re. "Promise": Given that each extension runs in its own process, the use of Promises does not look like something that would make a difference.

Promise based blocking APIs are more powerful and potentially but not necessarily faster because they allow the concurrent processing of multiple requests while shoving the actual work into workers, thus not blocking the JS event loop, or retrieving additional information from other contexts via messaging.

[jgkawell]

I've got a question: Do we know if this will be a part of the Chromium version of Edge or just Chrome? This is being done to Chromium but has Microsoft said whether they're going to include it in Edge?

[patrickdrd]

I don't think that Microsoft has anything to do with it, edge is chromium based so it has no choice but to follow chromium code, so, whatever changes in chromium it is applied to edge too, there is no other way around

[zesterer]

@patrickdrd If Microsoft has the motivation (and it does, because it doesn't share Google's revenue stream but wants to provide a better experience for its users) then it could easily just maintain downstream patches that enable ad-blocking technology.

[patrickdrd]

yeah, right, that's why they dumped their own browser in the first place?

[joeldrapper]

We all knew this was coming when we signed up to use a browser built by a surveillance / advertising company.

Great news for Firefox :)

Not really. Mozilla has taken over a billion dollars in donations from Google. If Google can pay Mozilla to make them the default search engine, they can pay them to stop supporting ad blockers. Let's not make the same mistake twice.

[0xadada]

If Google can pay Mozilla to make them the default search engine, they can pay them to stop supporting ad blockers.

I dont think Mozilla will accept any amount of money to undermine their core business strategy.

[bughit]

@gorhill Do you know what they mean by "enterprise deployments"?

though blocking will still be available to enterprise deployments

My understanding is that the enterprise chrome bundle is just the the normal chrome offline installer wrapped in an msi, bundled with group policy templates.

Which suggests there will be a policy that enables webRequest blocking. Although they do have an ability to limit policies to domain joined machines (on windows).

[SW1FT]

So Google wants to gimp/remove (ad)-blockers instead of clearing up the quality/quantity of the ads being served through their own service? Cool, I guess we know how this will end.