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. 

My feeling is that you are trying to protect the user from stuff like change of ownership of extensions, that down the line become malicious, and start to read all the content from pages and so on. Seems like a valuable goal however I wonder if there couldn't be anything a bit less disruptive than asking for permission each time a domain is changed. Apple has the purple arrow when applications are using the location information, perhaps something like that could work here as well? The icon changes background color when it accesses content-level APIs and the user can choose to disable that stuff?

[Andrey Meshkov]

I'll try to be a little bit more specific.

Here is a short list of what's missing from the declarativeNetRequest and what was not yet mentioned here.

1. Dynamic rules registration (or had it been mentioned already?).
2. Full regular expressions support. These might be used not so often, but are really crucial in some cases.

3. There is no way to make a blocking rule (or a redirect rule) prevail over an "allow" rule. The thing is that ad blockers use multiple filter lists and it is sometimes necessary to override what's allowed in other filters.

4. There is no way to not just block a web request but to prevent opening navigating to a website or opening a new tab ($popup/$popunder modifiers).

5. It is unclear if "redirect" rules allow specifying a "data:" URL or a "chrome-extension:" URL and how it will work with the website's own content security policy. Also, it will make sense to let us create a dictionary of named redirect resources instead of copy/pasting the same redirectUrl (pretty long in case of "data:" URLs) in numerous rules.

6. There is nothing about headers modification there. Although, I don't see how this can be made declarative. Here are some real-life examples: adding CSP headers, modifying "Cookie" or "Set-Cookie" (removing or adding cookies, enforcing same-site policy or modifying max-age), modifying Referer or User-Agent, etc, etc.

[Andrey Meshkov]

7. One more thing that is crucial in some cases is having an option to disable generic blocking/redirect rules (those that have no "domains" key specified). This is important for avoiding ad blocking detection -- a filter list author can disable generic rules for a website and instead specify some more precise rules specifically for that website.

8. Another thing that would be really helpful is having an option to specify origin URL mask and not just the domain name. This is useful for large websites (like google.com for instance) which have different web apps in different locations of the same website (for instance, google.com/maps and google.com/flights).

9. We really need an option to receive feedback on what's done by the declarativeNetApi. What rule was applied to what request? For instance, the webRequest API can be extended to supply this information in one of the callbacks (onBeforeRequest?).

[wOxxOm]

It'd be nice to have a technical confirmation from a Chromium engineer that they understand the total inadequacy of the current declarativeNetRequest API for most of the scenarios mentioned in this thread (something that was obvious to us extension developers right from the start). Otherwise this entire discussion starts to look like a cynical public relation formality ending in a small note - "after discussing with developers we ended up making a judgment call and went with our initial plan".

[ublockuser]

The best approach would be to not remove or modify the webRequest API at all and keep it as is, while making declarativeNetRequest API a lighter version of webRequest API and keeping it optional, so those who need it can use that while uBO and other content blockers stick to webRequest API which works best for their use case.

[Sachin Jain]

Hi Everyone,

This is Sachin, developer of Requestly - https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa

Requestly is a chrome and Firefox extension used by ~100K users. It is used by web developers in their testing purposes. It allows users to set up rules like this

• Redirect "https://example.com/abc.js" to "https://localhost:8080/abc.js" to debug remotely hosted scripts
  
• Block websites/requests in order to assess how it impacts their website
  
• Modifying request and response headers in their testing purposes.
  

Since these are dynamic rules defined by the users, they cannot be determined early and cannot go in rules.json

If webRequest API is removed, it will impact all Requestly users (~100K users) and it will also affect their testing. It is like we are trying to achieve speed by compromising control here.

I'd suggest the same like previously others have said - Keep and maintain webRequestAPI as it is and provide declarativeNetRequest API which will be faster and developer can choose which set of APIs to be used.

Thanks

-Sachin

[Thomas Greiner]

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

Thanks for clarifying and I do understand that the plan is to keep the webRequest API around. Although from what I read, it's not meant to be used for content blocking anymore as it won't be able to block requests so, technically, it can't be used for content blocking. That's why I'm wondering what the secondary way is, that the doc is implying.

Unless you are saying that extension developers will continue to be able to use the webRequestBlocking API for the forseeable future until the declarative API has caught up with it?

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 questioning the introduction of a declarative API because, as you pointed out, some extensions could benefit from it. Why would that require removing the webRequestBlocking API though?

I could even imagine a hybrid model where the declarative API acts as a filter that takes care of all the heavy lifting and only passes on matching requests to the webRequest API. For instance, this could lead to only those requests being delayed that are likely going to be blocked anyway while all others could go through without any unnecessary delays.

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.

Do I understand you correctly that extensions will be able to override Chromium's own subresource filtering rules?

To answer your question: Yes, I'm referring to expanding the capabilities of the API. Since the Chromium project would effectively be in control of what can and can't be blocked, I'm wondering whether you think it'd make sense to allow extensions to extend it, allowing them to quickly act and be more flexible in the fight against bad actors on the Web.

Such extensions could then act as proof-of-concept for future modifications to the declarativeNetRequest or other extension APIs.

[Oliver Mattos]

Proposal:

Limit synchronous WebRequest filtering to a certain percentage of the total request time.

By saying 'a web request can only be filtered by an extension if the total time spent by that extension is <1% of the total request time for past requests' then an extension will get taken out of the critical path if it's too slow.

I propose doing it on a per top-level-domain, request-domain, and per extension basis.  All three of those must historically be under 1% (with a moving average) for a webrequest to be allowed to be synchronous, otherwise it becomes observe-only (and a property in the request gets set to inform the extension why).

It will provide an incentive for extension authors to use less time, and to migrate as many use cases as possible to the declarative API (which is always available, and hence reliable, for use cases where stochastic behaviour isn't acceptable).  It will provide an incentive for ad-providers to make their ads load quickly to try and 'beat' the adblocker.

The disadvantage to this approach is maintaining more code and API's going forward.

[Michael Volz]

Hi everyone, EPUBReader extension developer here.

Although WebRequest API is not needed for the core functionality of the ebook reader extension, replacement of this API would hurt, as it would decrease usability.

Currently the reader uses webRequest.onHeadersReceived to analyze if an opened url links to an epub file. If so, it downloads and opens this file automatically. With the new declarativeNetRequest API this won't be possible anymore. The reader can in this case register only the simple rule to redirect all urls which end with .epub. This will fail in all cases the files are named otherwise which is often the case.

I understand, that the WebExtensions API is not standardized but I would appreciate it if the Chrome team would discuss these changes with the Firefox team. Identical APIs in both browsers are important for extension developers. Extension developers are an important part of the Chrome ecosystem, so you shouldn't forget about their needs.

[Vasco Gomes]

Hi, I also want to raise another issue.

If background persistent pages with DOM are gone it will break dozens of thousands of extensions.

Simple example:

- A Notifier Extension for any social media network (facebook, twitter) or email client that shows on the extension icon (badge) the number of missed messages, chats, emails,....

Typically the extension loads the page (for example facebook.com) on an iframe in the background page DOM and use chrome.webRequest to remove the x-frame-options.

After that it will monitor every x minutes the number of missed messages/chats/emails/... by using the stored working iframe in the background page with the page loaded.

The user can silently monitor it's missed notifications in the extension app icon without to have to have every tab opened with facebook, messenger, email and constantly monitoring them.

This is the more secure, simple, reasonable way to do this. Otherwise the extension have to be messing and violating cookies or in violation of company's private API's just to give a simple number of missed notifications in the Extension icon.

And there are literally millions of people using Google Chrome just for this.

I strongly believe that persistent background pages with DOM is what make Chrome Extensions great because it gives developers power to deliver thousands of new and exciting ideas that everyday makes the way into Chrome Web Store. And by navigating in the Chrome Web Store we see exciting extensions that in the end is what makes Google Chrome great. 

There are thousands of other examples, I just gave one.

I think that manifest V3 by the way is documented here on the P1 changes and some API changes: https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit#

Is a drastic change from manifest V2 and will make over >50% of extensions unable to work or it's functionality crippled.

Users will complaint for sure, thousands of bad reviews/ratings and in the end can lead to a massive user migration to other platforms. 

In the end also lead to Developers frustration and bad reviews/rating lead to no monetization and Developers abandon the extension development.

On Google Play, developers are given each time with more power tools and more monetization options. On Chrome it's the reverse.

Greetings.

[david preston]

When will Google and it's developers listen to it's users. if this Change goes ahead, I will walk away from google and its software completely. Websites load fast enough. the Add blocker is not going to make a noticeable difference. Also as seen with google search, this is able making money through google ads and searches. It is nothing to do with speeding up websites. Just do a standard search on Google, often the searches give you absolute rubbish not even what you searched. No more so when you click shopping, the first search does look like it's giving you what you wanted. But always the Higher end of the price range, soon as you use, the filters, you suddenly getting stuff not even related to your search. Google search often brings up commercial news sites ahead of none commercial, specially those using google ads. The decision to remove Flash is also a way to force websites to use code that makes it harder to block ads. Look at the mess of Youtube, now you need 4000 watch hours and 1000 subscribers, they block accounts that get close, suspend people that dare challenge the trolls that Google does nothing about because it helps them keep the money from advertising.

Google need to improve it's image because its software is glitch y, it's devices seriously glitch y and its terms are against the user and to make it self money. So be careful google and it's programmers, your forcing people away from Google. and in the end that isn't going to make you any money. Google+ closing, reason no one took it up? Because people don't trust google. That is bad.

[Daniel Glazman]

> Le 23 janv. 2019 à 23:54, Devlin Cronin <rdevlin...@chromium.org> a écrit :
>
> 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.

Fine, then let's discuss elsewhere the rest because it's not discussed at all:

- dropping background scripts in favor of Service Workers will be super harmful to ALL extension developers

- removal of deprecated but HEAVILY used APIs is super harmful to ALL extension developers

- pretending Google discussed all of this with (extension) developers is super harmful to the whole ecosystem, it's a question of trust

I am absolutely not ready to restrict the discussion to webRequest only. The other proposed changes are also unbearable to us as is, to put it bluntly but politely (to be honest, a few harsh words come to my mind these days). As Vasco Gomes said it in another message, « If background persistent pages with DOM are gone it will break dozens of thousands of extensions ».

Following the review changes on extension submission that EVERYONE is complaining about because it made submission success totally unpredictable and even more importantly time-to-market unpredictable, I hope you understand our trust in Google Extensions, and beyond that in Chrome market dominance, is a bit shaky these days.

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

Let me add a comment on the proposed webRequest changes. I read here and there they were motivated by speed and performance.

With all due respect, no user, no ad/tracker blocker extension developer can seriously accept that explanation.

The highest performance improvements for Chrome are reached precisely when the browser DOES, through all the extensions the v3 proposal would break, block all heavy stuff web pages are clogged with. We, in Europe, have seen precisely what it means: because of GDPR, some top100 american web sites have drastically if not completely reduced the number of ad/trackers in their web pages for european visitors; suddenly, these web sites saw a download time divided by 20 (yes, twenty...), a speed increase up to x4.

"Time to fork Chromium?", that a developer employee of another well-known chromium-based browser told me yesterday, should sound to you as a immense warning signal.

</Daniel>

[Daniel Shumway]

I realize that the point of these changes are to stop extensions from slowing down page loads, but I want to add the use case that there are legitimate reasons to slow a page down.

I am currently working on a personal extension that helps wean me off of sites that I don't want to check too often. One of the ways it does this is by introducing delays to specific network requests on those sites. There are, of course, theoretically other ways to make a website slower to use, but they're not as elegant. I'm playing with the idea of slowly increasing delays as I spend more time on a site -- so when I check it in the morning, it's snappy, but if I'm still on it by lunch, it starts to really lag everywhere.

Purely off the top of my head, some use cases I would want to see supported:

- Using delays to sort network reuqests and force them to resolve in a specific order.

- Responding to or altering a network request based on the result of another network request.

- Uniformly delaying network requests like I described above.

- Delaying a network request while a custom prompt is shown to a user ("this page wants to contact AD_NETWORK with THIS_DATA, do you want to let it continue?")

I realize that part of the point of the current changes are explicitly to block my use case. But I don't feel like my use case is illegitimate. Is the position that there is never a valid reason to slow down a network request? Google's own dev tools allow for very primitive throttling? Would it be a bad thing for the same capabilities to be given to regular user as well as developers?

[Pál Tamás Ács]

Dear All,

I am a devops engineer and a user of Chrome and uBlock Origin from the beginning of its development. As an advanced user I couldn't imagine a browser without uBlock Origin. I have the following concerns about the proposed webRequests API changes that are likely to affect ad-blockers and content blockers.

I think uBlock Origin, Google, Inc. and the Chromium Project have at least one thing in common: They want to make sure that we, the users who browse the web, can stay secure, work efficiently, to the highest extent possible. This is why it would be a great loss for all of us if the proposed API changes made the further development impossible of uBlock Origin and similar content blockers. I have the following reasons to think so.

• Content blockers like uBlock Origin are enhancing efficiency as well as security on a much higher level than your proposed API changes ever would. For instance, in uBlock Origin, there are block lists specifically for blocking sites known to have malicious code injected or perform fraudulent operations to hijack the browser somehow.
  
  
• Content blockers make a good commitment to enhance user freedom. A great example is the feature called Cosmetic Filters. In uBlock Origin you can restyle websites real-time, hide annoyances, disable time-wasting animations, replace poor contrasted, unreadable blurry web fonts to reduce eye strain.
  
  
• Content blockers like uBlock Origin have element blocking capability that allows you to hide whatever you want from any site, including annoying floating search and menu bars (as annoying as IE toolbars in the 2000s), cookie warnings (useless EU parliament idealism). You can disable extremely annoying modal dialogs popping up without user consent. This can enhance productivity very much.
  
  
• With content blockers like uBlock Origin you can disable all advertisements without exceptions. In general, advertisements are there to make people buy things they naturally don't want to buy, by using psychologically tested manipulation techniques. This is of course not an issue with Google or Chromium, still people must have the right as well as the technical possibility to keep their minds clean from advertisements and I mean all advertisements and no exceptions. It is not okay if some advertisements get through the blocker just because advertisers pay extra money to the creators of the extension. uBlock Origin is a completely community-developed extension that accepts no money for exceptions.
  
  
• With content blockers like uBlock Origin it is possible to reduce network traffic generated by advertisements and web resources that are not necessary for what the user wants to see or do on a site. Traffic equals money, especially for people using their notebook or desktop PC on mobile broadband with a traffic-based price plan. Why should anyone spend money for advertising content that tries to convince them to spend money again for advertised products?
  
  
• Chrome and Chromium eat more resources if there is no content blocking turned on. They're not just the advertisements that waste at least the 40-50% of the browser's available resources but there are also crypto-mining engines injected into the JS code of the site, often without user knowledge. uBlock Origin tends to have block lists included by default and disables loading of these kinds of abusive resources. Eliminating the capability for an extension to disable specific JS resources for a site would have a catastrophic impact on performance and would cause lots of disadvantages for users who are really concerned about security, stability and efficiency and really do something about it - instead of just naively believing Google that they're secure™ by using their browser.
  
  
• Chrome and Chromium also eat more resources if there is an inefficiently-written, bloated extension (like AdBlock Plus) in action. I mentioned AdBlock Plus because if this webRequests API proposal gets through, it will be the only popular alternative that is not severely impacted. However that is not intended as AdBlock Plus is not an alternative of uBlock Origin. It tends to profit from allowing some content of advertisers who pay enough money to them. Also, there are exact performance comparisons on that. [1] It would be kind of ridiculous if AdBlock Plus - that makes Chromium consume more resources than if there was no blocker at all - would stayed alive while uBlock Origin - a really efficient blocker with low-resource consumption - would be killed due to the limitations of API changes.

Keep in mind that uBlock Origin is used by more than ten million users and is one of the most successful and useful extensions in the Chrome Web Store. There must be a solution. I'm also aware of the problems malicious Chromium extensions can cause but I think it's a rather an issue of discipline in the Chrome Web Store than of the API capabilities. Google should commit more developer/devops/testing resources to review these extensions instead of putting more and more boundaries around them over time. Useful extensions should stay, malicious extensions should go. Simple as that. However, I have a few more constructive general ideas which could help us avoid the great loss that pulling the rug out of uBlock Origin would cause.

1. Pay more attention to Chrome Web Store by Google developers or independent open-source developers who continuously review the code of extensions and test them. If there is something malicious, they can step in or block those extensions from Web Store. The infrastructure is already there. Google should only allocate more developer resources for it.
   
   
2. Introducing a reputation system for extensions in Chrome Web Store would also help reducing the spread of malicious, insecure extensions. Those that are around for years (like uBlock Origin) and used by tens of millions of people without complaints could stay and would have a high reputation. Reviewers could focus on new extensions with lower reputation.
   
   
3. Propose a webRequests API that wouldn't make content blockers like uBlock Origin impossible to maintain. For example, it would be a good idea to let users decide themselves whether they allow the blocking version of webRequests to be used by an extension or not. As they can already allow extensions to be present in Incognito mode. It would be also great if most important API features could be allowed or disallowed for extensions. Like microphone, camera, notifications, etc. for websites.
   

All in all, introducing API changes that pulls the rug out of the development of uBlock Origin and similar extensions would be an arrogant move with a catastrophic effect on user freedom and the overall productivity, efficiency and software value of Chromium and Google Chrome. I hope some stakeholder wise enough to realize that (e.g. Devlin Cronin) would step up to help find a proper solution for all parties.

Best Regards,
Pál Tamás Ács

[1] - https://github.com/gorhill/uBlock#performance

[wOxxOm]

Unless you or someone from Chrome can guarantee the new format makes it impossible for extensions to find a different workaround, there's no point in restricting/crippling just a few API. There are no such guarantees, though, unless Chrome destroys the ability of content scripts to augment the so-called "main world" of web pages. As people pointed out, such restrictions will only force authors to use even clunkier hacks (the aforementioned main world augmenting) that are likely to cause various inconveniences for the user or speed regressions. When people agree to limit the possibilities because those are abused by the bad actors, everyone ends up losing. As other comments point out there are much better solutions like introducing a more granular permissions system e.g. for modification of security-related headers like CSP, refererrer, etc. I guess the plan to cripple the extensions API was invented due to financial or technical inability for Google to maintain a much larger team of reviewers who can analyze the code in its Web Store for extensions.

[wOxxOm]

But where do we stop with these restrictions? Even if Chrome makes extensions as powerless as those are in Safari, the advanced users who value their privacy or digital rights (whatever that might be) will simply use local MitM proxies like Fiddler or customized solutions that decode the traffic, apply URL/header/content transformation and pass that into the browser. And then someone else comes forward and says OS apps are too powerful, let's not allow them to modify this or that. Using that logic, the brain can make people do bad things based on the manipulated/wrong info supplied to the victim so let's cut the brain and make it impossible to do bad things. Oh wow, the bright future.

On Sunday, January 27, 2019 at 12:20:49 PM UTC+3, b3nd...@gmail.com wrote:

I cannot guarantee anything i'm just sharing my thoughts .

This discussion can last forever but if you ask me the current implementation is really bad, i'm not saying that chrome should brutally restrict everything but some restrictions must be done.  

And regarding other proposed solutions like what you've mentioned  the more granular permissions  system , that's still doesn't change anything because third party lists have the ability to manipulate those headers and even if the user agreed to modify the csp header how can you guarantee that the injected header will not be malicious ? or if the extension have a vulnerability that allows CRLF injection which will cause the response to "split" . so if some threat actor compromised one of those lists the results can be catastrophic.

LSS in the current implementation the extensions api's introduces huge security concerns .  

[wOxxOm]

So just because uBlock (and some other extensions) can be theoretically subverted you suggest that crippling the very ability to perform various advanced activities is good. That's why I asked where do we stop, because if we don't stop following that logic the end result will be a brain surgery as the brain also uses external sources of info to act upon, which can be manipulated/subverted to make the victim do bad things like genocide during WW2 and various atrocities during the entire history of mankind.

On Sunday, January 27, 2019 at 1:01:11 PM UTC+3, b3nd...@gmail.com wrote:

If you're using/developing an "OS app" that executing/using some sort of logic from a third party lists than yes that's a big security risk and very bad practice.

Now If you misunderstood me i'm quite sorry but as i wrote above my concern is the ability of those third party lists to influence the extension logic, the only way to restrict those api properly is to allow only hardcoded manipulation (exactly what this manifest suggests) so google algorithms can properly check them before the end user installs the extension, any dynamic css manipulation is perfectly fine but dynamic manipulation of sensitive headers that can be controlled by third party lists is for me a huge security concern. 

[Sebastian Noack]

Well, as per the standard, an added CSP header (and that is as far as uBlock Origin and Adblock Plus might interfere with headers) can only further restrict the policy, not relax it. I don't see any security concern here.

Regardless of this, of course an extension has more capabilities and therefore bears a higher risk (if abused) than a website. But as we try to make extensions more like websites, we essentially make extensions useless. After all a browser extension requires powerful capabilities in order to extend the browser's functionality in a meaningful way. But if we don't accept that risk, why shall we stop here? We could as well push for limitations in the operating system that prevent third-party browser engines (like Chromium), the same way they attempt to prevent third-party content blocker implementations with this change.

The whole argument about privacy becomes especially hypocritical if you consider that a fair amount of extensions that are to be castrated here improve (or can be used to improve) your privacy by blocking unsolicited tracking. The argument for better privacy/security here is equivalent to saying that an antivirus software would be more secure if it cannot read your files in order to check them for malicious code.

On Sun, Jan 27, 2019, 05:01 <b3nd...@gmail.com wrote:

If you're using/developing an "OS app" that executing/using some sort of logic from a third party lists than yes that's a big security risk and very bad practice.

Now If you misunderstood me i'm quite sorry but as i wrote above my concern is the ability of those third party lists to influence the extension logic, the only way to restrict those api properly is to allow only hardcoded manipulation (exactly what this manifest suggests) so google algorithms can properly check them before the end user installs the extension, any dynamic css manipulation is perfectly fine but dynamic manipulation of sensitive headers that can be controlled by third party lists is for me a huge security concern. 

On Sunday, January 27, 2019 at 11:38:31 AM UTC+2, wOxxOm wrote:

--
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/a81c52f7-60c3-4809-bf5c-3738a4e496f3%40chromium.org.

[b3nd...@gmail.com]

Again as i said this discussion can last forever , all sides concerns should be given serious attention.

if we get into a discussion about security over performance/capabilities we will never finish, I've replied here just to voice my concern about the current implementation , And i'm not saying to brutally restrict everything but only to consider the security aspects of any further implementation.

[wOxxOm]

What "sides" are you talking about? Didn't you know the current implementation plan does brutally restrict everything that makes uBlock Origin and other tools such wonderful managers of the content and resources? And there's no indication that Chrome's engineers will actually change anything *meaningful* in the plan as their decision-making process is a blackbox with the only available reasoning based on meaningless buzz-words like "security", "moving forward".

[b3nd...@gmail.com]

I've already said that brutally restricting everything isn't the right way and i've just wanted to voiced my concerns with the current implementation  , but obviously brutally restricting everything will be bad for everyone !