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 !

[Inv]

You either sound like a troll or a bot. Your words are a threat to freedom. Why do you have a brain? We need to do a surgical implant in your brain to make sure you don't do harm or say things we don't like. See how dumb that sounds? That's essentially what you're advocating for.

Instead of dumbing down users, why not make them a bit more accountable for their actions? 
The direction we are heading, there seems to be no line. If you are speeding up something by removing/compromising features, you're a failure and shouldn't be rewarded for it. You so called "vulnerability" researcher should also know that users should have control over the software. As per your logic everything should be a "vulnerability" as long as it is controlled by humans. 

[b3nd...@gmail.com]

First i would like to thank you for your nice words:)

I think you misunderstood my "logic" , i do agree with you saying "users should have control over the software" but if the software can be controlled by many third parties (like all of the third party filter lists) than i think it's wrong , what if one of those lists will be compromised and a new filter will be injected to do some malicious action? currently the extensions can control the headers / inject js / redirect .... , I'm not saying to restrict everything but some actions needs to be taken , like informing the user that the extension has changed the headers or injected new ones ....  

[Inv]

"like informing the user that the extension has changed the headers or injected new ones " We cannot force inform the user at every event that headers were changed/modified. Or should at least allow the user to suppress this informing alerts/notifications.

Instead user should just be made aware that there are risks using those feature/granting access to those permissions. Are the security/privacy risks associated with the permission required by the extension/software worth the risk? This should be left up to the user.

Instead of a taking away control, why not tell the user that if they grant *insert risky permission here* to the extension, Google is not responsible for their loss. It should be up to the user then. Ignorance is not an excuse for giving up freedom and should not be. 

"but if the software can be controlled by many third parties (like all of the third party filter lists) than i think it's wrong". I beg to disagree. If a user authorizes/trusts/is willing to take the risk to allow the software to control things automatically to assist him/her then the software should have the privileges to control/automate/assist with whatever the user likes.

Increasing security by decreasing functionality is not an achievement. Any system that allows for external input carries a security risk. The freedom and control is worth the risk. 

[ublockuser]

> but if the software can be controlled by many third parties

Facts - uBlock Origin is an extension, not a software, third-parties don't control anything, third-party filterlists are selected by the users, they control whether to use it or not. They can disable it on a whim and enable if they want to, anytime, anywhere.

> what if one of those lists will be compromised and a new filter will be injected to do some malicious action?

Fact - has happened before and the filter was disabled using $badfilter directive in uBlock Origin, rectified quickly and easily.

> currently the extensions can control the headers / inject js / redirect .... , I'm not saying to restrict everything but some actions needs to be taken , like informing the user that the extension has changed the headers or injected new ones ....  

Yes, they should have it, you're the troll who's advocating that websites should have that power, infact extensions should have the ABSOLUTE power over website resources.

>  but some actions needs to be taken , like informing the user that the extension has changed the headers or injected new ones ....  

No thanks, us uBlock Origin know everything what goes with the project as it's open source. Your bullshit reasoning has no merit and you sound like that a fucking shill who's trying to lay his egg here to make sure extensions lose control over websites and turn the tide of this anti adblock war.

[Daniel Shumway]

I don't want to start an argument, and I'm glad that people are thinking about security. However, I do want to push back on the security ideas being presented here.

In my mind, this is not a debate about whether it's worth breaking extensions to increase security. My perspective is that powerful extensions make the web *more* secure.

Currently, every single website I visit has the ability to do the following:

1. The ability to set CSP headers without my knowledge. If I'm visiting my bank in an extension-free browser, I have no way to know if their CSP headers are set correctly, and I have no way to fix the problem if they're vulnerable.

2. The ability to redirect and intercept requests via wrapping around native fetch APIs, and to make any request to any site without me knowing about it. Just like with an extension, this can be controlled via 3rd-parties (ad-networks).

3. The ability to inject 3rd-party scripts and modify native context on the page. Again, I have to just trust that the website I'm visiting embeds ads correctly and blocks them from accessing important parts of the page. And there's no way for me to validate that they do so.

Even if extensions present some danger, here's the important thing -- as a user, I currently need to trust maybe 4 or 5 sources to avoid compromising my network. Without extensions like ublock origin or umatrix, I need to trust *every single website* that I visit.

Powerful extensions greatly reduce the number of ways that an attacker can get at me. They allow me to set secure policies that are enforced on every site, no matter what the site operator would prefer.

Having said that, I do agree that some of the access extensions get right now is dangerous, and I would be open to conversations about increasing user control over how extensions are sandboxed. I don't think that the V3 manifest is a step in the right direction. To keep things on topic, I'll only comment in regards request blocking, but I think these problems pop up in multiple areas of the spec.

1. Restricting an extension from modifying requests on the fly is not particularly useful to me if the extension can still monitor requests.

2. Using a declarative blocklist and removing the ability to load blocklists at runtime is not particularly useful if it means that my extensions are slower to update with new blocked domains and malware sites. From my perspective, this is like making it so a software program couldn't ship a security fix without updating my kernel.

What would be interesting to me is an ability for users to override which domains an extension can be active on. For example, perhaps ublock does request that it can monitor requests and change headers on any page, but I, independently of their request, say, "don't even load this extensions code or let them know when I visit my bank." I would like to see the manifest move in a direction where, as a user, I get the final say on which permissions an extension gets regardless of what it wants.

Sandboxing is powerful, and it works. But any discussion about security has to start from an understanding of what my threat model is on the web. My threat model is websites. To me, it is silly to suggest that giving websites free reign over what code they run and what 3rd-parties they contact is somehow more secure than allowing one or two trusted 3rd parties to enforce across the board standards and restrictions. While there's certainly room for improvement in this area, I don't think that V3 makes me more secure. I think it makes me less secure.

[b3nd...@gmail.com]

This will be my last reply here because the last comments seems like some sort of attack on my opinions .

Inv I didn't meant literally inform the user on every action but just to inform and requests permissions for that specific domain.

Anyway thanks for the meaningful  discussion :)

[owne...@gmail.com]

     Seriously, people. Keep it OT and cut the profanity. At this rate, Google won't even consider our side. If you want to be taken seriously, stay focused.
     As I see it, by granting so called privacy and speed with the v3 change, you are restricting that and user choices. The plan, as it is now, destroys any content filtering or adblocking. For instance, I use UBlock, NoScript, and https everywhere. Those all will be either rendered non-functional or severely crippled.
Also, you will take away user choice. If I don't want to see ads or malware or whatever, I should not have to. I should not have to look up every single page to see if it's safe. Extensions like UBlock have the ability currently to prevent malicious pages or ads from loading.
That being said, I do think the current system needs improvement. As in update the webRequest API, not severely restrict it. I would also recommend tighter Web store security
If the proposal was modified so these extensions could still function, that would be just as functional. But as it stands now, our choice, privacy, and security potentially provided by these extensions is at risk.

Sunday, 27 January 2019, 08:59AM -05:00 from b3nd...@gmail.com:

--

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/9fa38309-f094-4a3d-927b-708422038a0e%40chromium.org.

[Sachin Jain]

Guys, Please maintain the sanity of the forum. I believe everyone has the right to put up his opinion about privacy/security or the power/control given to extensions.

I am Founder of Requestly, a product with ~100K users (the majority of them are web developers) and I too complain that such power shouldn't be taken away from Chrome extensions. Instead, I advocate providing more insights to users so that they are aware of any modifications made by an extension or not. 

Once again, I humbly request to maintain the sanity of the group and communicate your thoughts in a respectful manner. We want to have a productive discussion here and let Google folks/designers know that we want such use cases to be achievable with a new set of APIs.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/1548598666.25187359%40f29.my.com.

[Rajdeep Chatterjee]

As a user to uorigin and a long time user of chrome (in fact I am always the first one to recommend Chrome to my friends), I humbly ask you not to go ahead with a change that cripples 1000's of extensions. 

No one in this would likes to loose freedom to choose, and by crippling extensions your taking away the users right to choose.

Users should be notified about the performance impact that an extension might have, after that it should always be up to the user to select if they want to run the extension or not.

Also, forcefully breaking 1000's of extensions will create a a deep frustration among the developer and user community, and this is one of the fastest way to make users switch browsers.

I again humbly ask you to reconsider this change, or atleast come up with an alternative that first break or cripple extensions.

Crippling extensions for a very little speed gain is not worth it.

[Brian Coleman]

Bromium develops and maintains two cross browser web extensions, Secure Browsing and HP SureClick Secure Browsing. Both extensions share the same code base and feature set, so for the rest of this message I will refer only to Secure Browsing. Secure Browsing is a web extension designed to run on Windows PCs with an installation of the Bromium Secure Platform security product. In particular, Secure Browsing is designed to block navigations to potentially risky websites, and to launch the Chromium-based Bromium Secure Browser to use for those navigations instead. Bromium Secure Browser offers an additional level of security on top of that provided by Google Chrome. Navigations to websites in Bromium Secure Browser take place inside an ephemeral virtual machine, that is isolated from the rest of the operating system. In its current iteration, Secure Browsing uses the webRequest API to deliver this functionality. In its current proposed form, the replacement declarativeNetRequest API will prove insufficient to re-implement this functionality. Logic for determining whether a navigation is potentially risky The logic for determining whether a navigation is potentially risky is based on an engine which works in a similar way to the declarativeNetRequest API, but which is more general in scope. Rather than specifying a set of rules which match a pattern against the URL of a network request, the engine used by Secure Browser specifies a set of rules which match a sequence of patterns against the origins of a sequence of top-level network requests. For example, when a user on mail.gmail.com clicks a link in an email to evil.com, a new tab is opened, and in that tab, a request is first made to google.com, which then redirects to evil.com. This sequence of requests can be expressed by a rule, which matches against each request in turn, and takes an action when every pattern in the sequence, up to and including the last pattern has matched. That action may be to allow the request, to block the request or to redirect the request to a different URL. Both the origin and the Content-Type of the request can be matched against. Origins can be matched literally or named groups of related origins can be referred to by a single group name. Features - When a user clicks on a link in an email on a webmail site, or on a link to a PDF document, and the extension considers the link to be potentially risky, the user will be prompted with a choice, allowing them to open the link safely in Bromium Secure Browser. - When a user clicks on a link in an email in a desktop email client such as Outlook, and Google Chrome is the default browser, the user will be prompted with a choice, allowing them to open the link safely in Bromium Secure Browser. Permissons Secure Browsing requires the following permissions: - webRequest - webRequestBlocking - <all_urls> The extension does not have apriori knowledge of the websites a particular user may attempt to visit. Lists of trusted and untrusted origins are dynamically fetched via HTTPS requests. It is therefore unrealistic to expect the extension to be able to enumerate all URLs which are of interest statically in the manifest. APIs used - webRequest Secure Browsing relies on the ability to register blocking event handlers for the onBeforeRequest and onHeadersReceived for top-level requests. An event handler is also registered for the onBeforeRedirect event. - onBeforeRequest is used to track the sequence of navigations for each tab, and to match the origin of the request against the set of rules specifying an origin pattern. If one of the rules matches, the extension relies upon the ability to redirect the tab to an extension resource hosting a prompt. It also relies upon the ability to cancel the request if the request URL is untrusted. - onBeforeRedirect is used to track the sequence of navigations for each tab. - onHeadersReceived is used to match the content type of the request against the set of rules specifying an content type pattern. If one of the rules matches, the extension relies upon the ability to redirect the tab to an extension resource hosting a prompt. You can find more details in this document: https://www.dropbox.com/s/ota07d7gowfmu71/Chrome%20Manifest%20v3.pdf?dl=0

On Wednesday, 23 January 2019 16:57:06 UTC, Devlin Cronin wrote:

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

On Wednesday, January 23, 2019 at 8:10:35 AM UTC-8, addisons...@gmail.com wrote:

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

[cad...@gmail.com]

I'm going to talk here about the elephant in the room: The false argument that for the safety of people it is important to restrict the ability of action of extensions with version 3 of the manifesto.

For several years, users and even developers have been asking Google for a manual check of extensions in the Chrome web store so that malicious extensions are not published in the Chrome Store.

A full manual check of any new extensions submitted by a developer who has less than 2 years of seniority and less than 5 major revisions of its extensions would prevent the abuses that are seen today in the Chrome Store.

Also if an extension to more than 50,000 users a new full manual check would take place and another to 100,000 and 150,000 users etc etc.

Manual verification of extensions is the only effective way to protect users and allow them to use powerful and versatile extensions.

The only disadvantage of having manual reviews of extensions would be that developers should wait longer before their extensions are available to the general public, but it is a compromise that all serious developers would gladly accept.

Private extensions would not have to have a manual review only the public ones.

The longer an extension is, the more active the developer would be, the less likely the developer would be subject to manual reviews during subsequent updates of its extension as mutual trust would develop over time between Google and the developer.

Also selling an extension with its users should be impossible for the author and this to prevent abuse. In fact if it is sold the new acquirer should create a new entry in the Chrome Store and if it is a new developer it would be subject to more frequent manual verification.

The manual checks are very effective the Mozilla AMO was very safe and had very few malicious extensions when the checks were manual and from the moment the mandatory manual checks were removed the malicious extentions abound almost as much as in the Chrome Store unfortunately.

I am aware that my post is not directly related to version 3 of the manifest but it directly affects the reason why Google says that it wants to cut / remove power APIs ie user security.

Personally I believe Google does not want to hire people to do manual verification because its profit margins would decrease what proves that the real and main objective of Google is not the safety of people or to make advanced technology but that its Profit margins remain as high as possible.

Google unfortunately favors having a lot of crappy extensions instead of privileging the quality and safety of people because it attracts more people to have "big numbers" that is why he does not seem to know anything about doing manual extension checks because the number of extensions in the Chrome Store would decrease and so would Google's profits.

So removing features in the extension APIs to stay safe amounts to eating 1 x a week to have less chance of suffering from food poisoning instead of adding food inspectors so that food quality is assured, it's stupid and shows that the real goal is to save money on the backs of users and not to increase their security.

[Adam Winn]

After reviewing the proposed changes in v3, we've determined the Cisco Umbrella Client for Chrome (UCC) would no longer be feasible. We introduced the client late 2018 and already have 300k active users, with continued growth--so the impact would be significant.

We do not store any of our block information in the extension or app, because our domain and URL intelligence lists are over 10 million entries. Instead, the extension holds the request while our app does a just-in-time lookup (using DNS for speed) of the disposition of that destination (and also if the user's policy allows/blocks the category). 

Interestingly, our choice to use the webRequest API was because ChromeOS does not have any mechanism for us to implement our preferred method of endpoint support--intercepting DNS at the client, adding metadata and forwarding to our servers. This is how our endpoint agents work on other platforms. 

We understand the motivation behind the proposed API changes, and agree with the intentions, but in the current proposal (even with an expanded rule list) we don't see a way forward for the Cisco UCC. 

For Cisco's use-case specifically, we require customers to use Chrome management via G-Suite (there are no ad hoc installs by end users), so we would be okay if blocking/modifying features of the webRequest API were only accessible on managed Chrome devices. Granted, this is not a solution for developers of extensions like uBlock. 

[Adam Winn]

Constrained execution time would work for us (Cisco / OpenDNS) as well. webRequest would ignore the hold after N milliseconds or something like that.

[Aleksandr G.]

Hi all!

I'm developer of Sticky Password and it's Chrome extension which is ~15 years old with thousands of active users.

Having read the Manifest V3 draft I can declare than couple changes can kill our extension:

• Background Process: Migrate from event/persistent background pages to Service Workers.

       I can't imagine how to migrate our code from persistent background script to Service Workers, I even still not sure Service Workers will fit for our extension logic. We definitely need persistent background script for making the extension work secure (as you know none of storage API like localStorage or chrome.storage are secured by Chrome, therefore the Service Workers security state can't be saved to storage).

       Please, keep persistent background script as an option for V3 extension! Otherwise can you please describe the way how the developers can secure migrate their code from persistent background script to Service Workers (which was designed to work with simple web pages and not with extensions)?

       Who and how will load Service Workers?

       Will Service Workers support Chrome API (like chrome.tabs, chrome.browserAction)?

       Will JSON parser (it's the primary data type for our protocol between extension and application) be still available in Service Workers?

       How to work with Native Messaging API from Service Workers?

• Cross-Origin Communication: Content scripts share the same cross-origin communication rules as the page. ... If a content script needs access to data fetched from a cross-origin server that requires authentication, it can proxy the request through its background page using extension messaging.

       Wait a second! The draft doc said the background page will be removed, but here the draft said it should be done through the background page.

•  Dynamic Content Scripts: Provide more capabilities to extensions to support dynamic content scripts.
  

       How this will be implemented? Draft said that background page will be removed, then who and where will inject content scripts (the core of each extension)? Service Workers? Definitely no - because they should be registered too!

Here are just the unclear cases:

• Restricting Origin Access: Migrate to an activeTab-style model, where access is granted at runtime. In Manifest V3, we want activeTab-style host permissions to be the default, with a number of extra options.  Instead of being granted access to all URLs on installation, extensions will be unable to request <all_urls>, and instead the user can choose to invoke the extension on certain websites, lik

       How this will be implemented for user? I navigate some page and Chrome offers me to activate my 10-20-50 extensions for that page? I suppose normal user have 15-20 extensions, but anyway this will lead to activating your extensions on each page instead of working with web, doesn't it? I definitely sure most of users will allow the majority of extensions for all sites.

• Remove APIs replaced by the Open Web Platform: Remove any APIs whose functionality is now available on the Open Web Platform.
  

           I'm sorry, but officially supported Web Notifications API doesn't worked for me neither in Chrome nor in Firefox (both latest release version, clean profile without extensions). We do use Extension Notifications API in our extension, not critical for us, but at least new offered API should work!

[matthew weaver]

Howdy, all. Thanks rdelvin[...]@ for helping to wrangle input into a forum. I appreciate it.

I am convinced I want the same end state as the chrome developers: extensions like uBlock Origin and HTTPS Everywhere have reduced permission surface area and guaranteed runtime behavior.

It is very important to me that we get there without crippling those extensions' ability to do good work.

One of my lines of work is helping to manage IT infrastructure for organizations of various sizes (some O(1) users, some O(1K) users).

My role is usually helping to structure tools, authentication, and endpoint management to find low-overhead ways of protecting the users and the organizations against their threat models.

Sophisticated blocking of user requests at the browser, managed by the enterprise, is one of my primary tools. Using HTTPS everywhere and uBlock origin, sometimes with centrally managed custom bock lists, is particularly critical for protection in these examples taken from my experience over the past four years:

1. Principals at political organizations, activist organizations, and in enterprise C-suites who are subject to a smattering of surveillance and malware delivery threats via the advertising networks and protocol downgrade attacks
2. Employees' web access at public organizations (US municipal, state, federal), and health care organizations as part of data loss protection strategy
   
3. Student web access at educational institutions using fleets of chromebooks
   

Reducing the webRequest API behavior as proposed, to short (O(10K)), static lists, will harm my ability to do what I do for these organizations.

In some cases, it will directly result in a reversion to TLS-MiTM proxies to manage user network behavior. I'm convinced that will bring with it all the old attendant problems we know those solutions have displayed in the past.

Thanks everyone for your work, I appreciate it.

In general, chromeOS and Chrome have helped me defend important, vulnerable populations even in situations where financial resources and support resources are badly constrained. I hope that will remain true in the future.

weaver

[Alex]

For Privacy Badger's response, please see https://github.com/EFForg/privacybadger/issues/2273#issuecomment-458697088

Note that we cover all aspects of Manifest V3, not just webRequest, because it makes more sense to address them together.

[Sebastian Noack]

I had a closer look at the declarativeNetRequest API, and wrote a script [1] that converts filter lists (like EasyList). However, due to the limited filter capabilities of delcarativeNetRequest, not all filters can be converted. Here is what is missing in order to support existing filter lists and current ad blocking requirements:

1. In condition.urlFilter, the ^ character should match the end of the URL as well. It seems the developer who wrote the code was aware of that and left a TODO comment [2]. For the time being, I could add another rule using | instead, for each rule ending with ^, in order to get the correct behavior, but that would significantly increase the number of resulting rules which is already extremely limited.

2. There are some filters in EasyList that matches the URL against a regular expression. There are only a few, but the ads they block cannot be targeted with simple glob patterns. It would be great if there would be an option like condition.urlRegExp for cases like that. It might even be OK if the number of regular expression filters is limited.

3. Adblock Plus supports $document exception rules (used in EasyList), which essentially prevent anything from being blocked within a matching document (top-level or iframe) and recursively within any sub-document. This is somewhat similar to using addAllowedPages(), but the pattern accepted by addAllowedPages() is more limited, and it is only applied to top-level documents. It would be great if there would be an "allow-sub-resources" action that, instead of whitelisting the matching request, whitelists everything within the document loaded by that request, just like $document exception rules.

4. There is also the $genericblock filter option, which follows the same semantics as the $document filter option (see above), but instead of whitelisting everything within the document, it only prevents filters without domain restriction from blocking requests. That is useful when generic filters (i.e. filters without domain restriction) cause false positives or other side effects on a page. In order to support the $genericblock filter option, we'd need rule priorities (currently the priority seems to be ignored by block/allow rules), in addition to the aforementioned "allow-sub-resources" action.

5. There are $csp filters (used in EasyList) that inject a Content-Security-Policy header into the response of the matching request. This is very helpful in cases where websites go to quite some length trying to circumvent ad blocking (through workers, inline scripts, plugins, etc.). Therefore it would be great to have a rule action that injects arbitrary headers, or at the very least specifically Content-Security-Policy headers. Note that if multiple Content-Security-Policy headers are given in a response, only the subset allowed by each Content-Security-Policy header will be allowed.

6. Unfortunately, "redirect" actions don't seem to work yet in Chrome beta 72.0.3626.81. But once supported, it would be great if "allow" rules would as well prevent "redirect" actions. According to the documentation this doesn't seem to be the case. This is necessary to support $rewrite/$redirect filter options, without breaking the whitelisting semantics of Adblock Plus.

7. 30,000 rules are just not enough for EasyList alone. My script outputs almost 40K rules for EasyList, once the above limitations are lifted and more filters can be converted, this number will increase. Moreover, users that speak other languages than English have at least one language-specific complementary filter list in addition to EasyList, not to mention other complementary filter lists like EasyPrivacy.

Furthemore, the following limitations of the API make an adoption in Adblock Plus impractical:

8. It is essential for Adblock Plus to be able to update the rules at runtime. Users need to be in control of what is blocked, but even in the default configuration the filter lists vary based on the user's language. Also filter lists need to be updated at a much higher frequency than updating an extension would be practical at, in order to keep up with websites as they change, sometimes at a high frequency specifically to prevent their ads from being blocked.

9. It would be great if there would be an API in order to observe rules as they are applied and the request they were applied to. Otherwise, we can no longer provide filter analysis functionality [3] which is an important tool for filter list authors.

[1]: https://gitlab.com/eyeo/adblockplus/adblockpluschrome/blob/convert-declarative-net-request-rules/build/convert-declarative-net-request-rules.js

[2]: https://chromium.googlesource.com/chromium/src.git/+/master/components/url_pattern_index/fuzzy_pattern_matching.h#9

[3]: https://adblockplus.org/development-builds/bringing-blockable-items-to-chrome-introducing-the-adblock-plus-developer-tools-panel

[Karishma Chaudhary]

Having a few questions and concerns with respect to v3 changes:

1. What is the estimated time to release the webRequest changes in Dev/beta/production?

2. DeclarativeNetRequest does not support adding the block domain at runtime. Same time it supports maximum entries in block list is 30k. Our domain lists are over 30k entries. And that is increasing. If you are forcing us to use only 30k blocked domain, that will reduce the security on Chromebook.

If you are removing blocking options from webRequest API then we are completely blocked. Is there any alternative solution to provide security for more than 30k blocked domain.

3. What is the estimated time to release the newly introduced DeclarativeNetRequest APIs in production/beta? Any detailed doc for same?

4. If V3 Applies to App, our APP uses TCP server that serves requests all the time is there a time constraint for the application in the new version. For example, if a process is running more than x hours then will it be terminated?

5. “Long-running background processes should not be allowed.” How can this impact us as we have App running TCP server?

[sak...@aravalli.co.in]

Need clarity on below points-

1. Manifest V3 update is for Extension and App both?

2. Is the WebRequest API being deprecated for blocking requests, if yes any detailed documentation available on the same?

3. Is it possible to hold the request in webRequest API or it is going to become read only.

4. Is any other alternative available for blocking requests other than DeclarativeNetRequest?

5. Is it possible to time bound the waiting/holding time of webRequest API instead of removing the blocking option.

[dan.f...@consensys.net]

I’m Dan Finlay, a lead developer at MetaMask. We’re a chrome extension crypto wallet and account manager with about a million active installs.

We would like the v3 manifest format to not be pushed to production in its current form until support for the FrozenRealms specification has been included, or at least iFrame API support is kept in the background script context.

We have been working on using Agoric’s SES (Secure EcmaScript) to better isolate our dependencies, to reduce the risk of dependency-based thefts like the CoPay Dash event-stream hack, as suggested by Zooko Wilcox. SES was derived from Google’s own Caja project.

Currently Agoric’s SES relies on a polyfill of the Realms API that relies on the iFrame API, which is not available in ServiceWorkers at this time, which the manifest v3 currently requires all background scripts to be.

All we really want is the FrozenRealms API, since it’s the simplest way to truly isolate module code, but keeping iFrame support would at least let us continue using the SES Realms polyfill.

As the extension singleton script, our background script must handle the user keys, which manage their cryptocurrency accounts, often the most security sensitive bits of data on the user’s entire computer, so it should be understandable that we care very much about the security available to the background script in particular.

Thanks for your time,
- Dan Finlay

[Adam Winn]

One additional suggestion/alternative--certain APIs or functions in the API could be limited to developers who go through some type of extra registration step with Google. This would mitigate the risk of malicious actors using those APIs. For example, to use VPN API on iOS, you have to be a registered corporation with Apple.

[lotn2...@gmail.com]

the below is a pure crock of shit. the only real real for this is to dig deeper into what we do and to shove ads down our throats.  google keep this up and you won't exist.

"This document describes a large set of planned changes to the Chrome Extensions platform, ranging from core features to specific APIs, with the motivation of increasing security, privacy, and performance for extensions.  These changes will be bundled with a new manifest version. Once announced and implemented, it will eventually be required for all extensions over a year+ rollout process."

[INL Owner]

KEEP IT CLEAN!!!!!!

And don't threaten Google. You really think they're afraid of you?

Seriously. If we want our concerns taken seriously, they must be presented in a clear, organized fashion, without a bunch of outraged people making extra noise

If you don't have something thoughtful and insightful, don't write here

---

From: chromium-...@chromium.org <chromium-...@chromium.org> on behalf of lotn2...@gmail.com <lotn2...@gmail.com>
Sent: Monday, February 11, 2019 11:13:51 AM
To: Chromium Extensions
Cc: rdevlin...@chromium.org
Subject: [crx] Re: Manifest V3: Web Request Changes

 

the below is a pure crock of shit. the only real real for this is to dig deeper into what we do and to shove ads down our throats.  google keep this up and you won't exist.

"This document describes a large set of planned changes to the Chrome Extensions platform, ranging from core features to specific APIs, with the motivation of increasing security, privacy, and performance for extensions.  These changes will be bundled with a new manifest version. Once announced and implemented, it will eventually be required for all extensions over a year+ rollout process."

--
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/5039cfed-2677-45c9-a394-db38b92ced01%40chromium.org.

[Darren Govoni]

People have a right to say whatever they want and feel and express their concerns here. We don't silence peoples voices and we sure as heck don't need to appease Googles feelings on the matter. They will make their decisions based solely on the merit of their own interests. 

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/MN2PR17MB2814B9DA22D49A5B6A27565AAD640%40MN2PR17MB2814.namprd17.prod.outlook.com.

[INL Owner]

Google has listen before. They sometimes have to. With people like you generating a lot of noise, though, they may ignore this thread. You'll notice that at one point, a chrome developer (Devlin Cronin) was on this thread and participating.

And although it is true you are allowed to express your opinion, this is neither the time nor place.

If you can constructively pose arguments against the change, please express them. Otherwise, find another place to be outraged

---

From: Darren Govoni <darre...@gmail.com>
Sent: Monday, February 11, 2019 11:28:27 AM
To: INL Owner
Cc: Chromium-extensions; lotn2...@gmail.com; rdevlin...@chromium.org
Subject: Re: [crx] Re: Manifest V3: Web Request Changes

 

[wOxxOm]

If anything, the current public response is quite mild. I would expect 1000 times more noise and outrage everywhere. Evidently, the users still believe Google will listen. But so far there's no indication from Google that they will actually reconsider anything at all regarding the Manifest V3 plan. The lack of proper technical communication and acknowledgement of the voiced concerns creates a void that's filled by negativity, which is a natural consequence. We also haven't seen any proof that these changes will indeed help move the platform forward, improve security, and performance. Some of the changes (like the deprecation of the background pages in favor of service workers) make me think the extension component was "hijacked" by web-development-related people who don't really know the specifics of the extensions API, and didn't measure the impact of setting up API bindings, didn't actually test a proof-of-concept, and so on. I wouldn't be even surprised if there is no one among them who actually develops extensions like we do so they might have problems with the fact the extensions are so powerful and hence want to nerf the API. On the other hand, we all know how bureaucratic the big corporations are, so maybe they're just that bad at communicating.

On Monday, February 11, 2019 at 7:43:29 PM UTC+3, INL Owner wrote:

Google has listen before. They sometimes have to. With people like you generating a lot of noise, though, they may ignore this thread. You'll notice that at one point, a chrome developer (Devlin Cronin) was on this thread and participating.

And although it is true you are allowed to express your opinion, this is neither the time nor place.

If you can constructively pose arguments against the change, please express them. Otherwise, find another place to be outraged

---

From: Darren Govoni <darre...@gmail.com>
Sent: Monday, February 11, 2019 11:28:27 AM
To: INL Owner
Cc: Chromium-extensions; lotn2...@gmail.com; rdevlin...@chromium.org
Subject: Re: [crx] Re: Manifest V3: Web Request Changes

 

People have a right to say whatever they want and feel and express their concerns here. We don't silence peoples voices and we sure as heck don't need to appease Googles feelings on the matter. They will make their decisions based solely on the merit of their own interests. 

On Mon, Feb 11, 2019, 11:17 AM INL Owner <owne...@gmail.com> wrote:

KEEP IT CLEAN!!!!!!

And don't threaten Google. You really think they're afraid of you?

Seriously. If we want our concerns taken seriously, they must be presented in a clear, organized fashion, without a bunch of outraged people making extra noise

If you don't have something thoughtful and insightful, don't write here

---

From: chromium-...@chromium.org <chromium-...@chromium.org> on behalf of lotn2...@gmail.com <lotn2...@gmail.com>
Sent: Monday, February 11, 2019 11:13:51 AM
To: Chromium Extensions

Cc: rdevli...@chromium.org

Subject: [crx] Re: Manifest V3: Web Request Changes

the below is a pure crock of shit. the only real real for this is to dig deeper into what we do and to shove ads down our throats.  google keep this up and you won't exist.

"This document describes a large set of planned changes to the Chrome Extensions platform, ranging from core features to specific APIs, with the motivation of increasing security, privacy, and performance for extensions.  These changes will be bundled with a new manifest version. Once announced and implemented, it will eventually be required for all extensions over a year+ rollout process."

--
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-extensions+unsub...@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/5039cfed-2677-45c9-a394-db38b92ced01%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--
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-extensions+unsub...@chromium.org.

[Anshul Sharma]

In Addition to the other questions, we needed below information:

1. “In Manifest V3, the only allowable background presence type will be ServiceWorkers.” Is this going to change the way currently extensions work w.r.t having only one instance of extension that will call the APP or is it one extension instance per tab?
   

2. In Restricting Origin Access, As part of v3 changes activeTab-style host permissions will be the default instead of *://*/*. Can we still use the regex pattern like *://*/* to access the all type of urls?

3. Is there any doc for Web-Accessible Resource Hardening changes? That may describe how can we test the unique id instead of url.

4. What are the increased privacy as mentioned here :: “Users should have increased control over their extensions.  A user should be able to determine what information is available to an extension, and be able to control that privilege.”

5. For previous question follow-up will there be any changes in the way Gsuite Admin has control over Extension and App?
   

these questions will help address some changes that we can take into consideration for our Ext & App

[re...@cliqz.com]

Hi,

Cliqz engineer here.

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

TL;DR: they are all very efficient, having median decision times per request anywhere between 7 μs and 1 ms (depending on the extension), which is at least three orders of magnitude less than the requests themselves.

Their performance is also continuously evolving thanks to the innovations and hard work of developers, browser improvements, technologies like WebAssembly, etc. and we do not see how this will cause an issue in the future.

There is a second aspect to this performance argument: the overhead of the WebRequest listeners themselves. Some pointers can be found in this document: https://docs.google.com/document/d/1TZEuPvr2KAbP4_TZpuuwtEEArQsyAkc2HDu68l66YwU/edit?ts=598244df# We learn that the overhead of a WebRequest listener is of the order of 10 μs.

The way we see it is that the Manifest v3 proposal is sacrificing privacy and flexibility of the extension ecosystem as a whole for a negligible gain which will not be perceived by users.

Moreover, the declarative API, if it were to replace the current WebRequest APIs, would introduce an innovation lock, effectively acting as a bottleneck for future privacy improvements as this essential component of privacy extensions becomes out of reach. There are currently hundreds (if not thousands) of individuals actively working on making content-blocking, anti-tracking and more generally privacy-enhancing technologies better. They work for companies, in open-source communities or as individual towards the same goals: offering better protection for users while they browse the web. If tomorrow the APIs that they need disappear or are crippled, the potential privacy protection of all users will be greatly diminished.

We urge the Chromium developers to re-consider some aspects of the proposal, as these changes will have huge consequences on the ability of users to protect their own privacy on the Internet.

[lgr...@gmail.com]

We are currently evaluating all the feedback that has been offered, much of which has been centered on the declarativeNetRequest API.  There are a number of additions and changes we plan on making to the declarativeNetRequest API as a result of the concerns raised.  These include:
Dynamic Rule Support: We agree that this is valuable in creating sophisticated content blocking extensions, and will be adding support for declarative rules that can be added or removed at runtime to the declarativeNetRequest API.
Increased Ruleset Size: We will raise the rule limit from the draft 30K value.  However, an upper limit is still necessary to ensure performance for users.  Block lists have tended to be “push-only”, where new rules are added but obsolete rules are rarely, if ever, removed (external research has shown that 90% of EasyList blocking rules provided no benefit in common blocking scenarios).  Having this list continue to grow unbounded is problematic.
Additional Actions and Conditions: We plan to add support for matching based on more conditions, such as resource size, and will provide actions to modify parts of a request instead of just blocking it, such as stripping cookies.  We are also investigating other conditions and actions that may make sense to add, such as matching based on top-level domain.  (One additional note: While we are investigating adding support for CSP modifications, adding a CSP header to disable JavaScript was frequently mentioned as a use-case; this is already possible through the contentSettings API.  If this is insufficient, please let us know why.)

Backing off on the 30k rule limit further proves that these new restrictions are 100% arbitrary. And now they're going to half-assedly attempt to reinvent the wheel with a filtering engine which adblockers have already tweaked, honed, and customized for many years? Come on, guys, this is just a complicated, embarrassing mess. All you have to do is not break something that is already working! It has been definitively proven now that there isn't a performance issue here. And apparently it's not a privacy issue, because webRequest will still be able to read all requests, just not stop them. So what then, is the goal here if not to hobble ad blockers?

[INL Owner]

I do believe the current API needs some updates, but not removed in it's entirety. Or replaced

I cannot think of an extension I make or use that will not be hobbled or broken by this (ex. Ublock origin, noscript, browser plugs, etc). Also the widely popular Tampermonkey would be hit hard

Any tests I have seen do not suggest that extensions significantly slow down the web; in fact, they prove the opposite: if you prevent some resource intensive elements from loading, you offset the negligible decrease in performance. Take, for instance, ads. Anything that big and flashy will eat resources, unless blocked from loading.

Although there are genuine security concerns to be had about malicious extensions, I do not believe this is the right way of solving it. Several good ideas have been presented: better webstore review, informing the user, etc. Also, some extensions even provide for security (such as ones provided by antivirus).

Also, privacy concerns have yet to be substantiated. The only way this should happen is if the review process somehow fails. Also worth noting is the content usually blocked using existing APIs/extensions is much more privacy intrusive: give me an advertising provider that actually respects privacy, and I'll show you a good psychiatrist: you are delusional. Without privacy invasion, advertising could not survive.

I guess the biggest point I wish to make is that by diminishing the webRequest API and not providing a suitable replacement, you will diminish users' right and ability to choose what they see and have on their computer or other device. That is going to upset a majority of users, whether they know the true impact or meaning of these changes or not. That,in turn,may cause some of the posts seen here. Even if not expressed productively, their concerns are still valid

However, I like the progress that has been made so far in altering the proposed changes to manifest v3. It is certainly headed in the right direction

---

From: chromium-...@chromium.org <chromium-...@chromium.org> on behalf of lgr...@gmail.com <lgr...@gmail.com>
Sent: Saturday, February 16, 2019 10:05:33 PM

To: Chromium Extensions
Cc: rdevlin...@chromium.org

Subject: [crx] Re: Manifest V3: Web Request Changes

 

We are currently evaluating all the feedback that has been offered, much of which has been centered on the declarativeNetRequest API.  There are a number of additions and changes we plan on making to the declarativeNetRequest API as a result of the concerns raised.  These include:

--

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/e09fba28-b179-4747-a932-9c4f63ffe859%40chromium.org.

[s.d...@eyeo.com]

Hello everyone,

The proposed changes to webRequest, as well as the new declarativeNetRequest will affect a number of important use cases affecting  security, privacy, ad- and content-blocking extensions. 

Ad Remover, Adblock, AdBlock Plus, AdGuard, Cliqz / Ghostery, MalwareBytes as well Easylist authors (Fanboy and MonztA) have worked together to come up with a shared document, listing out the major issues, the use cases these might affect, as well as technical suggestions on possible ways to improve the APIs and it’s implementation. 

Here is a link to the feedback document. 

We would urge the chromium team as well as the rest of the extensions community to take a look. The recent post from the chrome team on iterating on manifest v3 is encouraging. We hope our feedback provides additional impetus to the changes mentioned by the chrome team in the post, as well as sheds light on what else is needed to improve upon in manifest v3 from the perspective of privacy, ad- and content-blocking extensions.

If the Chrome team needs any details or clarifications on anything mentioned in our feedback, then we would be happy to answer them and discuss more in the forums. 

[lgr...@gmail.com]

Nice list, but it's simply unfeasible for Chromium to reimplement every single current and future use case in their "one-size-fits-all" declarative API.

[Radiant One]

Not to mention that I doubt supporting ad block use cases are high on Googles list. As some have suggested all these changes are probably designed to squash those extensions and the rest along with it.

On Wed, Feb 20, 2019, 12:29 PM <lgr...@gmail.com> wrote:

Nice list, but it's simply unfeasible for Chromium to reimplement every single current and future use case in their "one-size-fits-all" declarative API.

--

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/0b87eccf-cc32-4c59-aa97-2acb6f7168bc%40chromium.org.