Manifest V3: Web Request Changes

[Ivan Koldaev]

Concerns regarding webRequest API were raised in comments of https://bugs.chromium.org/p/chromium/issues/detail?id=896897 .
In particular, developers of ad-blocking extensions concerned that declarativeNetRequest limits amount of rules to be 30k, which is insufficient to replicate current functionality.

I recommend Google Chrome developers to look into adding a limited virtual machine for filters like eBPF[1] with constrained execution time and resources.

This will address valid problem of browser extensions holding a request for indefinite amount of time, at the same time it will give extensions a flexibility to make filtering by any criteria imaginable.

[1] - https://opensource.com/article/17/9/intro-ebpf

[Ryan Brooks]

I'm copying over my comment from the Chromium.org thread, as requested by Devlin.

I'd like to add a vote to the "don't break uBlock Origin or other ad blocking extensions" camp.  I believe very, very strongly in maintaining my ability to use ad blocking software on my browser, and I will switch myself to another browser to maintain that capability if required.
I will also switch everyone I support on a technical basis, and begin blocking Google's ads on a DNS level for not only my personal network but also the networks I manage at work.  Up until now we've mostly turned a blind eye to ads, since it wasn't worth convincing executives that they should greenlight DNS filtering and it helps to pay for the products we all use in our personal time, but if Chromium and Google begin actively working to subvert user choice in this manner, my team will be much more incentivized to figure out a less-targeted solution than an ad blocker.
I urge the Chromium team to reconsider.  I know many of the developers working on this team are interested in building a better browser and providing a better user experience; this, however, will not further those goals.

I've had a few hours to reflect on this since posting, and I still think this is a very bad idea for Google.  I don't think anyone I know doesn't use an adblocker, and most of them use uBlock on my recommendation.  All of them have expressed astonishment at how much faster pages load when they have an adblocker installed, and I don't believe that any one of them will be happy to have that taken away.  I was talking about this with a non-technical friend this evening, and her immediate reaction was "so, should I switch to something else?" because she didn't want to be without her adblocker.  I think that the backlash from users if this change is carried out will be significant-- it won't kill Chrome, since it's so entrenched in the market, but it will definitely hurt it.  I've used Chrome since it was released, and the same for Chromebooks; I actually was sent one of the original CR-48 test hardware Chromebooks, and used it until it died a couple years later, and I am generally a pretty big Google fan.

That said, if anything could push me away from Chrome and the broader Google ecosystem, crippling adblockers in the way that has been suggested here is certainly on that short list.  I hope that won't happen, and that Google hasn't lost its way as it's increased in size and value.  I hope that it's still a place where sometimes things are done because they're good for the internet as a whole, and not just because it can add a small amount to the balance sheet.

[Fightin Filipino]

I agree entirely with this. This change isn't just about ad blocking, it's about entirely removing user control over a key aspect of the web browser: being able to granularly filter web content. For example, I use uMatrix not just for ad blocking, but also to combat malicious scripts and annoyances. I appreciate that Chrome/Chromium permits such user control. Locking this down is expressly anti-user. 

We all know why this is happening: Google wants to be able to be the ones controlling what ads get whitelisted. I sincerely hope the EU keeps levying fines. If you go through with this change, I will be moving to a different browser and will encourage friends and family to do the same.

[Robert Headley]

I do not primarily use Ublock Origin to block ads. I do, but only because I have to to also block malicious scripts. I have been infected by going to legitimate websites that had compromised add networks. Until it is impossible to get a virus on the internet, I need to be able to filter out malicious or unwanted scripts from the sites that I visit.

On Tuesday, January 22, 2019 at 7:30:31 PM UTC-6, Ivan Koldaev wrote:

[Jason Pascucci]

The nature of the recent post to the Chromium Blog combined with the proposal to intentionally add defects to the webRequest API do not actually serve the goals of "trustworthy chrome extensions by default": indeed, they serve the opposite, subverting the trust of the core project.

I would like to republish here the coda to the original note karandeepb in the extension issues thread for 1896897: "With such a limited declarativeNetRequest API and the deprecation of blocking ability of the webRequest API, I am skeptical "user agent" will still be a proper category to classify Chromium."

Is a browser something fundamentally under the user's control, or is it something fundamentally under the corporate entity's control?

Asked in a poignant way, is Chrome my agent, or is it really just an agent of Google?

By directing my browser to someone's website, am I necessarily giving up all permission to a (well-placed) cabal to take over my computer and do with it as they collectively wish? After all, detecting of ad blockers or objectionable behaviors done via extensions remains perfectly feasible: if you don't want to show me your content under my configured extension regime, you aren't forced to.

We've already seen the path this change would take from the history of issue #104058. One could argue that stuff like this has already hampered several avenues of useful extension development.

Next, unlike 104058, with these proposed changes (as I understand them), I think you open yourself up to issues with disabling extant or potential assistive systems and software capabilities: by removing certain capabilities from webRequest API going in this direction too, it seems to me that extensions that utilize it or would want to utilize it, will fail to work now or in the future, with no reasonable recourse on this platform (except, of course, forking).

Finally - there is a delicate balance of power here. In navigating and utilizing websites, in addition to them executing code on their computers to serve a request, I am permitting them to run certain code on my computer. It is not just that they permit me to run their code on their servers, it's my computer that they are using. If they gave me a computer, were paying for my half of the internet connection, and all the kWH used, sure it would be reasonable for you to control the content my device displays. Until that happens, it's mine to do with what I please, freely, not yours. Put another way, neither I, nor my computer, are your slaves. This is the fundamental issue with DRM and why it's dead, dead, dead,

On the flip side, it's the fundamental issue why streaming services can live (even at the exorbitant overhead compared to something better), it's the fundamental reason why software architecture is moving to service delivery instead of software delivery: in order to retain rights to something, you have to do it on your own stuff and not expect to do it on mine, you can't have to stop relying on ascii as the mode of transmission. If, for instance, you render your webpage to something that just streams output via RTSP, H.264, &c, then the servers would have control again: my options at that point would be to display it or not, make a copy of the stream or not, turn it from images back to text using my own ghz. Until that happens, I retain the power to run or not run what I want.

[Daniel Glazman]

> Le 23 janv. 2019 à 06:21, Fightin Filipino <fightin...@gmail.com> a écrit :
>
> I agree entirely with this. This change isn't just about ad blocking, it's about entirely removing user control over a key aspect of the web browser: being able to granularly filter web content. For example, I use uMatrix not just for ad blocking, but also to combat malicious scripts and annoyances. I appreciate that Chrome/Chromium permits such user control. Locking this down is expressly anti-user.

My company, Privowny, would like to add its +1. The webRequest/declarativeNetRequest API proposed changes will drastically impact our Chrome extension and our business and they do not seem to fully address not only OUR needs, but also users' needs. I am really surprised that a change of that magnitude is not discussed with direct users (hear extensions and apps implementors like us) BEFORE accepting the roadmap; this seems to me like a major hiccup in the product management. We are very deeply concerned by the proposed change, and it will most probably have a very bad impact on our tracker blocker that is an important part of our extension.

The proposed value for chrome.declarativeNetRequest.MAX_NUMBER_OF_RULES is also a DEEP concern to us and honestly, I don't see any valid reason why in 2018 such an API would be hard-limited. It really sounds like the old Internet Explorer's hard limit on the number of CSS rules or declarations per rule.

</Daniel>
--
Privowny, Co-CTO & Vice-President Engineering

[Giorgio Maone]

The author of NoScript here.

I'm in the final stages of a project in the making for more than one year and lots of research / resources now: porting the NoScript Security Suite add-on to Chromium.

Removing the webRequest API (which on Chromium is already severely limiting because it lacks the asynchronous mode offered by Firefox) would jeopardize the entire effort, because it would make very difficult if not impossible reliable script blocking and other features, implemented by adding CSP headers and other fine-grained manipulation of the requests.

What I do propose is keeping both the APIs (possibly making webRequest asynchronous like in Firefox, which could also mitigate some of the perceived performance concerns and allow for more flexibility) but advertise the performance and potential privacy trade-off, if any, on installation through the permissions system.

[Daniel Glazman]

> Le 23 janv. 2019 à 08:29, Giorgio Maone <giorgi...@gmail.com> a écrit :
>
> The author of NoScript here.
> I'm in the final stages of a project in the making for more than one year and lots of research / resources now: porting the NoScript Security Suite add-on to Chromium.
> Removing the webRequest API (which on Chromium is already severely limiting because it lacks the asynchronous mode offered by Firefox) would jeopardize the entire effort, because it would make very difficult if not impossible reliable script blocking and other features, implemented by adding CSP headers and other fine-grained manipulation of the requests.
> What I do propose is keeping both the APIs (possibly making webRequest asynchronous like in Firefox, which could also mitigate some of the perceived performance concerns and allow for more flexibility) but advertise the performance and potential privacy trade-off, if any, on installation through the permissions system.

Let me follow up on one point that was almost not discussed before: WebExtensions are in 2018 a cross-browser API. We, extension authors, heavily rely on the fact it's more or less implemented in the same way in both Chrome and Firefox. The v3 proposed changes are clearly going to make WebExtension support in Chrome and Firefox diverge quite deeply, and that's a VERY bad signal sent to extension authors and to the Open Web:

1. background pages replaced by ServiceWorkers (holy cow, that alone would imply months of work for us)
2. restrictions on <all_urls>
3. webRequest changes
4. browserAction and pageAction merge (while Firefox preserves both and allows both in the same extension)
5. deprecated but heavily used API that will be removed
6. i18n.getMessage would be changed or removed

Seriously guys, have you really evaluated/studied the impact on us implementors?!?

Furthermore, the WebExtension API is not managed like a Web Standard. The standardization effort initiated by Microsoft in a W3C Community Group ended up miserably and almost everything that makes the Open Web Platform stable and reliable is absent from WebExtensions:

- a Web Standard
- API stability
- frozen API
- open upgrade process discussed between browser vendors and implementors
- API reaching a Standard level when there are TWO interoperable shipped implementations
- prospective approach of the impact of ANY change on implementors based on usage metrics
- lack of API giving controlled access to the device ("à la" FirefoxOS)

In the recent years, Mozilla severely harmed its addons ecosystem that triggered its massive adoption back in 2003-2007 and the result is immediately visible: less powerful addons, tightened ecosystem, less innovation. In the recent years, Safari moved away from extensions based on Web standards too; the result was immediate too: an anemic (I could say dying) addons ecosystem, implementors moving away from Safari. Is Google seriously going to follow that path too, harming hundreds of third-party implementors that are an important part of the richness of its browser environment?

I urge Google to resurrect a real and active Standardization effort around WebExtensions. This is the *only* part of the Browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementors any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view.

[Peter Dolding]

On Wednesday, January 23, 2019 at 5:52:26 PM UTC+10, Daniel Glazman wrote:

I urge Google to resurrect a real and active Standardization effort around WebExtensions. This is the *only* part of the Browser space that is not handled that way, and we clearly see today with the v3 proposal that it is not workable for third-party implementors any more. We just cannot cope with deep changes of high magnitude in a timely manner. The financial impact of the proposed changed on extension vendors is vastly underestimated (if estimated at all), and that alone should be a showstopper signal from a strategic point of view.

</Daniel>
--
Privowny, Co-CTO & Vice-President Engineering

I read this and ask a different question.   Is the idea of Web-extensions itself wrong.    Javascript is not the best programming langauge and does at times leak memory badly.   We have the socks proxy for internet proxying.   We don't have content filtering proxies.

Before we had web-extensions and browser based extensions we had to get by with items like https://en.wikipedia.org/wiki/Privoxy as a proxy.

Yes its lighter to go in browser and avoid the double ssl layer that modern internet causes.    For site modification I would think the ablity to place a proxy of some form on top of content and redirect it to executable/python/what ever filtering engine outside the browser would be a good thing.   Yes if browser get means to redirect content into a filter they could also show users a diff between want they are seeing and what the site provided.

Daniel we need to think from security as well.

The current content modification is bad.   How can a user if they wish without turning the filtering off see exactly what extensions are doing the content?  They cannot right.   The way extentions have been altering displayed content does need to go back to the drawing board.

1) accountability if page delay is happening due to filter users need to see that.

2) security users should be provided with method to see what extensions have changed..

I would not have large problem making web extensions read only on websites if ability to plug in filtering was included.

Advertisement blocking is not enough.  I do need javascript and css blocking on some sites due to be badly coded and those being basically lets stall browser and eat all ram.

The current form breaking all the extentions would cripple my experience yes.  But the extensions also hinder my experience due to they way they integrate..

[Korte, Jouni]

Hi

I would also like to raise a concern regarding this. In addition to ad blocking this seems to affect
also security software that rely on extension capabilities of dynamically blocking https traffic that is
rated as malicious or otherwise harmful for user. This includes pages spreading mal/spy/whateverware,
but also for example parental control type of functions, i.e. protecting (child) user from content categorized
as harmful/unwanted for him/her.


Jouni Korte
Senior Software Engineer, Security Products
F-Secure Corporation

[Stefano Traverso]

+1 from my company, Ermes Cyber Security.

I would like to remark that content-blocking APIs have a number of applications which go far beyond ad blocking. We use them for security purposes, e.g., to prevent the browser contact URLs associated to phishing activity or used to deliver malware.

We are particularly worried about two points:

1) the 30K rule limit is utterly small. Indeed, some anti-phishing list alone may include millions of entries.

2) the impossibility to update content-blocking list in real time introduces delays which are intolerable in nowadays security standards. New rules must be delivered to extensions as soon as they're defined.

Finally, I would ask to argument in detail how users would benefit from this change in terms of security. Above hard limits seem dictated by performance motivations, which as we all know, do not combine well with security policies.

Stefano

--

Chief Technical Officer @ Ermes Cyber Security

[Claudio Guarnieri]

On Wednesday, January 23, 2019 at 10:42:27 AM UTC+1, Jouni Korte wrote:

Hi

I would also like to raise a concern regarding this. In addition to ad blocking this seems to affect
also security software that rely on extension capabilities of dynamically blocking https traffic that is
rated as malicious or otherwise harmful for user. This includes pages spreading mal/spy/whateverware,
but also for example parental control type of functions, i.e. protecting (child) user from content categorized
as harmful/unwanted for him/her.

I would also like to echo what Jouni just said. I believe these changes will prevent numerous security extensions from functioning correctly. We, at Amnesty International, have also been working on browser extension to support at-risk communities in protecting from targeted attacks.

In addition to this, I echo also the concerns expressed by Daniel Glazman, particularly the potential damage to the progress made on cross-browser compatibility.

Claudio Guarnieri

Amnesty International

[K Kovács]

Hi, we are the developer of a child-protection add-on, which strives to make the Internet safer for minors. This change would cripple our efforts on Chrome.

On Wednesday, January 23, 2019 at 2:30:31 AM UTC+1, Ivan Koldaev wrote:

[ublockuser]

On Wednesday, 23 January 2019 15:48:27 UTC+5:30, Stefano Traverso wrote:

1) the 30K rule limit is utterly small. Indeed, some anti-phishing list alone may include millions of entries.

There shouldn't be any LIMIT in the first place and currently there isn't, so why put a limit now ? 

[INL Owner]

As a user of uBlock and a developer working on a all in one filtering solution, I must say this does not raise my hopes for my future with Chrome. After this, and no extensions supported on Android (at 2x RAM), I may focus on Firefox instead

[INL Owner]

I really don't know what better way to do dynamic content filtering. As in most cases, a little common sense goes a long way with security concerns here

[wOxxOm]

I'd like to highlight an easily provable fact that uBlock Origin already makes popular web pages load several times faster and consume several times less memory by reducing the amount of ad iframes and such. Nothing implemented by Chromium natively can come even close to that so all the performance improvements the new API will bring are marginal in this particular use case, although most likely helpful in other generic use cases.

My take is that Chrome/Chromium engineers may inherently disregard extensions like uBlock Origin even if they are aware of the abovementioned benefits (hard to believe they are though), probably because their primary goal is to be a transparent window into the web herewith putting trust into the author's intent. I guess ideally they would prefer to make the browser so fast and reliable that there would be no need for uBlock Origin. While I can sympathize, it's not realistic. Moreover ad-blocking is not the only use case as the other comments point out.

A proper approach that respects the demands of real users as opposed to a gut feeling of a few Chromium engineers would be to embrace the need for advanced webRequest blocking, which is currently used by such extensions, and try to optimize the way it's handled - for example, by implementing something similar to Houdini (examples: one, two, three) - simple "worklets" that can extend the built-in logic of the browser such as CSS or even Layout engine via JavaScript snippets. If I understand correctly, these snippets can run in parallel. Applied to our use case, it would allow the browser to make lots of requests in parallel as it usually does without lining them up through the bottleneck of one complex extension script at a time.

Maybe the reason they can't implement the proper approach is that the extensions API team is apparently just one man - Devlin Cronin. There are other knowledgeable developers in this area, but they haven't been working actively on the extensions API judging by the commit history over the last few years with the exception for the notorious declarativeNetRequest implemented by Karan Bhatia. The extensions API seems to be essentially frozen for the last five years or so with no noteworthy additions, mostly bug fixes and trivial changes. The only notable technical improvement I know of is the rewrite of the underlying "bindings system" in native C++ performed by Devlin Cronin, which reduced the time to set up the JavaScript environment for extensions considerably (IIRC from 100ms for several content scripts to a portion of that). However they didn't even implement the modern Promise-based interface, which is technically not really an insurmountable challenge as evidenced by Mozilla's WebExtension polyfill that does exactly that. Meanwhile Firefox has been actively improving on the API they've inherited from Chrome so now their API has become much more attractive for an extension developer, and it constantly evolves.

[Brandon Dixon]

I maintain Blockade.io, a Chrome Extension that prevents such targeted attacks as Claudio mentions in his post. If these changes are published, the extension will cease to function. The current proposal to use "declarativeNetRequest" in place of a blocking webRequest API is not sufficient for two reasons––1) There is a 30K rule limit imposed which is not enough to handle our ruleset (~250K) and 2) Rules force us to explicitly outline the resource to block which is not possible with Blockade as we hash the resources in order to avoid leaking indicator data to anyone who installs the extension. 

Users of Blockade are usually those within civil society who may lack the funds or security resources needed to combat targeted phishing, drive-by attacks or compromised web pages. While solutions like Google Safe Browsing (GSB) help protect millions of users every day, it's not perfect and will not always catch the targeted campaigns going after those who need protection the most. Blockade was developed in order to provide these vulnerable organizations and individuals with a solution that could be maintained by the security community and stop attacks the second we saw them in the wild. 

Proposed changes in the manifest will remove our ability to serve vulnerable communities at scale. Please reconsider the changes to the webRequest blocking capabilities. 

[addisons...@gmail.com]

Does anyone outside of the chromium developer circle actually support this? Is there a particular instance where this functionality has been a problem, where neutering the API would prevent such an issue? There are tons of use-cases for blocking using the existing API, but I've yet to see any issues with security that don't involve a user deliberately installing a malicious plug-in or userscripts (I discount these cases because you can't design a safety feature that prevents a user from putting your gun to their head)..

[Devlin Cronin]

First off, I'd like to reiterate a few points:

- The webRequest API is not going to go away in its entirety.  It will be affected, but the exact changes are still in discussion.

- This design is still in a draft state, and will likely change.

- Our goal is not to break extensions.  We are working with extension developers to strive to keep this breakage to a minimum, while still advancing the platform to enhance security, privacy, and performance for all users.

Transparency and openness is core to the Chromium project, and we welcome feedback because we think having technical discussions in the open is valuable.  However, these discussions should be kept productive, and should always follow our code of conduct.

For feedback specific to details of the declarativeNetRequest API, such as the 30k rule limit, should be raised on the thread that was sent out in November soliciting feedback on that API.

I certainly understand that there are a number of concerns around limiting the power of the webRequest API in favor of a declarative API - it is much more restrictive, and doesn't offer the flexibility the webRequest API does.  The most helpful feedback for us is the exact cases that this would impact, their importance, and the reasons they are impossible through either the declarative API or through other extension APIs.  A number of these were raised in comment #23 on the bug, including:

- increased flexibility for specificity/overrides of rules

- blocking elements of certain sizes

- disabling JS execution through injection of CSP directives

- removal of outgoing cookie headers

Another issue that has been raised here a number of times is the ability to dynamically and instantly update the ruleset.

Having a list of the use cases that aren't feasible is incredibly useful for us in moving forward.

Please also try to keep discussions on-topic.  This is not the right thread for discussions around other aspects of potential Manifest V3 changes, the WebExtensions standardization effort, or non-technical discussions.

Cheers,

- Devlin

[INL Owner]

Wow, I can tell you don't use adblocking

This almost certainly will completely break them

---

From: Devlin Cronin <rdevlin...@chromium.org>
Sent: Wednesday, January 23, 2019 11:57:05 AM
To: Chromium Extensions
Cc: rdevlin...@chromium.org
Subject: [crx] Re: Manifest V3: Web Request Changes

 

--
You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/veJy9uAwS00/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d89758a9-cc4e-41a6-8803-6981848d1eb3%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Andrew Meyer]

It's really unfortunate how many people seem to be commenting here without understanding what the proposed changes even are.

To be clear:

1. This change _IS NOT INTENDED TO GIMP AD BLOCKERS_. Rather, it is designed to make them faster and more secure. (Yes, even despite the limitations that might impact uBlock.)

2. The new proposed content blocking API _is not final_ and can/will be changed.

3. Threatening to switching to Firefox is not helpful and _WILL NOT CHANGE GOOLE'S MIND ABOUT THIS_.

If you don't understand this, please refrain from commenting as you'll only be decreasing the signal-to-noise ratio in this thread and thus making it more likely that the entire thread (including those who are expressing actual legitimate concerns about the limitations of the new API) gets ignored.

If you want to help:

1. Explain a specific use case that the new API can't handle (including a technical explanation of _why_ it can't handle that use-case)

2. Suggest constructive changes to manifest V3's API that will improve its capabilities _while still adhering to the stated goals of manifest V3_

3. If you can't do any of the above, please refrain from commenting so you don't just make things worse

Sorry if I sound aggressive. It just really frustrates me when constructive technical discussions get hijacked by large volumes of unconstructive, uniformed comments. It makes it way harder to get real work done.

[wOxxOm]

People are really worried and they have a good reason. Chromium developers pushing this change that no one seems to need and doing so without exposing the research that justifies the change makes them and Google look arrogant and uncaring, while covering it all under the "security, privacy, and performance" cliche. We haven't even yet seen the evidence e.g. a performance analysis or some in-depth metrics that show why webRequest API must be limited and why it should be a global rewrite of the API.

[Inv]

I think that both API's should be available. The little increase performance is not worth the loss of functionality and freedom. 

[Barry Kaufman]

Is there a proposed timeline for this change? Will V2 stick around for awhile or will it be deprecated the moment V3 moves to production?

[Devlin Cronin]

Is there a proposed timeline for this change? Will V2 stick around for awhile or will it be deprecated the moment V3 moves to production?

Once v3 moves to production, there will be a transition period before support for v2 is removed.  There is not a firm timeline yet, but we will announce it broadly once there is.

[Thomas Greiner]

Thanks for opening this discussion to gather more feedback. I got a few questions regarding the upcoming changes to content blocking:

1. The design doc mentions that the "new declarativeNetRequest API will be used as the primary content-blocking API in extensions" which implies that there will be other means for content blocking. If so, which is it referring to or is it mean to say "only" instead of "primary"?
   
   
2. The design doc states that the primary reason for disabling the blocking-variant of the webRequest API is that extensions could - potentially - take a long time to come up with a response to a request. Considering that this change affects the API that tens, if not hundreds, of millions of Chrome/Chromium users depend on and that the declaractive variant of the webRequest API has never made it out of its experimental phase, which other options have been taken into consideration so far? (e.g. limiting the time an extension can take to handle a request or "punishing" it if it's consistently slow)
   
   
3. Will there be ways for extension developers to extend the built-in content blocking features that the browser provides? If not, how are ad blocking, privacy protecting and security enhancing extensions expected to react to new developments and practices on the Web in a timely manner? (i.e. not have to wait weeks or months for a Chromium update to reach the masses) For example, malicious actors on the Web can very quickly change their code to work around certain rules (e.g. ad reinjection) and those can only be thwarted by not just keeping the rules up-to-date but by also evolving the filtering engine to be able to create more powerful rules.

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 (see third point).

[Devlin Cronin]

The design doc mentions that the "new declarativeNetRequest API will be used as the primary content-blocking API in extensions" which implies that there will be other means for content blocking. If so, which is it referring to or is it mean to say "only" instead of "primary"?

The webRequest API offers much more flexibility than the declarative version, and there are some known cases that it won't properly address.  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).

The design doc states that the primary reason for disabling the blocking-variant of the webRequest API is that extensions could - potentially - take a long time to come up with a response to a request. Considering that this change affects the API that tens, if not hundreds, of millions of Chrome/Chromium users depend on and that the declaractive variant of the webRequest API has never made it out of its experimental phase, which other options have been taken into consideration so far? (e.g. limiting the time an extension can take to handle a request or "punishing" it if it's consistently slow)

We did think about approaches like this.  Overall, a declarative approach offered greater benefits (ensured performance and guaranteed execution) versus potentially allowing content that would have otherwise been blocked in pessimistic performance cases.  This is particularly important for privacy-related content blockers, where a user may need absolute guarantees that something will be blocked 100% of the time (and won't be allowed through if an extension took to long to decide - which could even happen based on external factors, like other programs running).

Will there be ways for extension developers to extend the built-in content blocking features that the browser provides?

Can you expand on this a bit?  Certainly declarativeNetRequest allows developers to specify their own list of sites in addition to the resources already handled by subresource filtering.  If you're referring to to expanding API capabilities (offering different matching capabilities or actions to take), these would require updates to Chromium itself.

[israelia...@gmail.com]

You are trying to achieve security/privacy/speed, but in the end you'll get the opposite by doing this change.

There are already dozens of companies who are circumventing Adblockers with quite a malicious JS codes, they are using random domains that are changed daily, they are replacing the entire websites URL's (even non ad related URLS) into random junk, they are injecting random elements to the DOM with random names and random classes and a huge sets of CSS tags that should covert the ads to be "undetectable".

Here are a few examples of such companies: InstartLogic (DNS based circumvention), PageFair (injecting ads via WebSocket/WebRTC), BlockThrough (shady DOM injections), Artimedia (Sticking video ads into regular videos) and much more.

Those companies above have already claimed huge sites (InstartLogic is working with msn.com for example), and making all the browsers much more slower, the fact that I have uBlock to finally read msn.com without annoying ads, and without advanced shady circumvention techniques that are really slowing down my PC is the only fact that I am using web extensions whatsoever!

You are giving those companies the means to destroy the web with this change, they would sign up more companies and sites since their technology would no longer be block-able, and it's a "game-over" for everyone, not just Chromium users.

What would be the end result here?

No security (since all those websites and requests that are going thorough 3rd party proxies will be much wider spread)

No blocking (I can just buy a new .xyz domain each day for 90 cents and replace it via S2S integrations, and the Adblockers won't be able to do anything since they have a 30,000/300,000/3,000,000 domain limit).

and no privacy, since my requests, and all of my cookies are now forwarded to third-party shady companies like InstartLogic.

How do you plan to tickle that? and please, don't delete this comment.

[ibrah...@gmail.com]

>We did think about approaches like this.  Overall, a declarative approach offered greater benefits (ensured performance and guaranteed execution) versus potentially allowing content that would have otherwise been blocked in pessimistic performance cases.  >This is particularly important for privacy-related content blockers, where a user may need absolute guarantees that something will be blocked 100% of the time (and won't be allowed through if an extension took to long to decide - which could even happen based on external factors, like other programs running).

I'm not seeing the full logic here.

Why not have the declarativeNetRequest API be the fallback when the webRequest API takes too long?  100% sure unwanted requests get blocked and the other more specific selectors still get a chance to filter.  It allows developers and list maintainers to combat threats that you won't have time for.  This doesn't even cover modifying the request headers.  I don't see why both cannot coexist so long as performance guarantees are made.  The full declarative tradeoff only works if you can compile it into Chrome.  The current declarativeNetRequest API spec doesn't even approach that so some trade-offs need to be made in order to maintain our flexibility.

You didn't mention it in the above reply but the argument of privacy was made for the declarativeNetRequest API.  I believe this is a moot point considering the extension has both:

1. been explicitly added by the user

2. passed the chrome store vetting process

Please do not break the tools we use to make the web better.  You will objectively make it worse if the new API is implemented without support for what we can currently accomplish.  uBlock Origin is a symbol of that.  Sorry for impassioned reply.

[Sebastian Noack]

Adblock Plus developer here. First of all, let me clarify that unlike Raymond Hill implied [1], this will affect Adblock Plus just like it affects every other ad blocker. The declarativeNetRequest API only covers the same limited subset of filter capabilities implemented in Adblock Plus that it does in uBlock Origin. After all both uBlock Origin and Adblock Plus (as well as others) rely on EasyList. I know that uBlock Origin added some non-standard filter capabilities used by it's own filter list, but so has Adblock Plus.

Anyway, even with a more complete/powerful declarativeNetRequest API, the browser would essentially become the ad/content blocker, and extensions that used to provide an advanced blocking mechanism will be limited to providing filter rules. This makes it difficult and slow to evolve blocking capabilities, while web sites become better and faster at circumventing ad blocking. Also it makes it difficult to provide a consistent blocking behavior across browsers, which is essential as in the end we rely on the same filter lists.

The benefits of a declarative approach on the other hand seem bogus. A non-blocking webRequest API (which is planned to remain) is sufficient for a malicious extension, to leak sensible information, and even without, there are still content scripts. In the end, a browser extension is meant to have powerful capabilities in order to extend the functionality of the browser in meaningful way. The only way to ensure security is by moderating the platform extension's are distributed through.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=896897#c23

[Keith Muenze]

With regards to Restricting Origin Access, a feature of our extension uses regex to identify phone numbers and adds a click-to-call feature "across the web".

Under the v3 updates, would they be able to allow an extension to operate everywhere? and maybe add a block list of sites/pages for the extension afterwards?

As I read it they would have to manually select to run each time - if the user is running multiple extensions that could get ridiculous quick.

[Andrey Meshkov]

Hi everybody, AdGuard developer here.

I'd like to raise another concern about the new host permissions scheme. As I understand, the <all_urls> is going to be deprecated and the extension will have to explicitly ask the user to grant permission for every new website. Even if the old webRequest API stays intact, this change alone will ruin user experience and expose users to all kinds of threats. Please, consider keeping the <all_urls> permission or at least making it optional permission that extensions can request at runtime.

[Devlin Cronin]

Hi folks,

A reminder: please help to keep these threads targeted.  This specific thread is about webRequest related changes.  Discussions about host permissions should be moved to a separate thread (feel free to start one!).  The more off-topic or non-technical posts there are in this thread, the harder it is for us to properly evaluate use cases related to webRequest.

That said, to quickly clarify this, there will be an option (at runtime) for users to allow extensions to have all-sites access and not need to grant it on each site visit; this is specified in the design doc (emphasis added for clarity):

In Manifest V3, host permissions will be granted by the user at runtime (similar to activeTab, but with options for the user to choose to always run on a specific site or all sites) 

[Keith Muenze]

Thank you for the clarification.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/59fd14bd-24b3-44a7-b683-a224fd1c6296%40chromium.org.

[Valentino Volonghi]

Hey,

We have a few extensions that are in use. 

One extension specifically cares about just accessing the domain name and the meta tag of the page that is currently visited and displaying a sidebar on the page while browsing. Then on a few other select domains it would like more specific access to understand what's the nature of the content on the page (e.g. in salesforce the user has an opportunity page open as opposed to a contact page and so on) and displaying content that is contextual to that page.

The second extension typically has to do with verifying the correct functioning of the integration with our customer. This typically involves checking that a given set of HTTP calls to specific URLs have been made (usually detected through regexp). At that point the URLs are also parsed to extract some information and display a sidebar on the page with such information. Similar to how Ghostery's extension works. In our case we don't need a long whitelist of domains that we should be able to see requests to, just a handful, but should allow the extension to continue to work.

These both use the webRequest APIs at the moment, not for content blocking but just observation of the outgoing requests and their arguments. 

<