[crx] Manifest V3: Web Request Changes

classic Classic list List threaded Threaded
120 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

[crx] 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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/7adbbbfb-71a3-4d65-b584-f54434cc7e61%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

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.

On Tuesday, January 22, 2019 at 7:30:31 PM UTC-6, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/9b73983e-0ac8-4683-b5b8-80570b1bd7bb%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

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.

On Tuesday, January 22, 2019 at 7:33:19 PM UTC-8, Ryan Brooks wrote:
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.

On Tuesday, January 22, 2019 at 7:30:31 PM UTC-6, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/63ead229-a49c-438f-afd4-4f0b1bc16016%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

Robert Headley
In reply to this post by Ivan Koldaev
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:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/50c6e820-cc69-4504-a782-86724e2cf037%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/4752a166-40d1-4e86-96d0-886f7ed9c5a1%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

daniel-4
In reply to this post by Fightin Filipino


> Le 23 janv. 2019 à 06:21, Fightin Filipino <[hidden email]> 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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/E8FD933F-D25C-4597-8B9E-A952EA1439E6%40privowny.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

Giorgio Maone
In reply to this post by Ivan Koldaev
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.

On Wednesday, January 23, 2019 at 2:30:31 AM UTC+1, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/0591ddcc-ab2d-40bf-8805-ad1f84df36c8%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

daniel-4


> Le 23 janv. 2019 à 08:29, Giorgio Maone <[hidden email]> 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.

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



--
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 [hidden email].
To post to this group, send email to [hidden email].
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/6165A44E-D441-4D99-9969-1E5E328368A5%40privowny.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

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


--
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 [hidden email].
To post to this group, send email to [hidden email].
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/ed584324-b8e2-40bf-91d8-5fde5c034293%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

Stefano Traverso
In reply to this post by Fightin Filipino

+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

On Wednesday, January 23, 2019 at 6:21:17 AM UTC+1, Fightin Filipino wrote:
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.

On Tuesday, January 22, 2019 at 7:33:19 PM UTC-8, Ryan Brooks wrote:
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.

On Tuesday, January 22, 2019 at 7:30:31 PM UTC-6, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/35d118ed-3fc6-4e91-8f91-a5bf758f06e4%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

K Kovács
In reply to this post by Ivan Koldaev
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:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/45845275-f628-41fe-844b-d86b7ebb30f0%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

momonga sama
In reply to this post by Stefano Traverso


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 ? 

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/3973b683-011c-42c6-b065-b0683f7a0664%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

ahsan ejaz
In reply to this post by Ivan Koldaev
Man, if all of you people are impacted by it, why don't you all volunteer and advertise Firefox? If all of you grouped and promoted Firefox to your clients you could have things go your way.

Tell your clients that Chrome/Chromium would no longer be supported after 1 year and that they should migrate to Firefox.
It is very clear from the direction that Chromium project is going is that it is taking away power from everyone else (users AND developers) except Google. 

Just look at what happened with the WebAudio 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 [hidden email].
To post to this group, send email to [hidden email].
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/ed84a694-ee90-41b3-bfc6-bb1c17acc5c5%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

ahsan ejaz
In reply to this post by Ivan Koldaev
Couldn't this be worked around/poly-filled ? 
Override the XMLHTTP, Fetch native methods to your method/function. Remove the  event listeners on HTML elements that are fetching resources and fire custom events manually.
Someone will just make a library for this and you would just inject it on every page.

End result would be worse performance then the native webrequest API though.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/5afb008e-5096-4287-a8dd-f007502a9940%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

INL Owner
In reply to this post by Ivan Koldaev
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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/daa5d333-55a7-4ffb-aa34-7b4cb4cb23ae%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

INL Owner
In reply to this post by Peter Dolding
On Wednesday, January 23, 2019 at 3:52:06 AM UTC-5, Peter Dolding wrote:

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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/8ff7594c-e071-448b-bbc3-329f663d29e9%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

wOxxOm zOo
In reply to this post by Ivan Koldaev
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/1db189c3-184d-4beb-be74-6471870d3c1a%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

addisonsnyderwork
In reply to this post by Ivan Koldaev
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)..

On Tuesday, January 22, 2019 at 8:30:31 PM UTC-5, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/f5d8b97a-a55c-463e-90a4-decf20a27531%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
Reply | Threaded
Open this post in threaded view
|

[crx] Re: Manifest V3: Web Request Changes

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

On Wednesday, January 23, 2019 at 8:10:35 AM UTC-8, [hidden email] 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)..

On Tuesday, January 22, 2019 at 8:30:31 PM UTC-5, Ivan Koldaev wrote:
Concerns regarding webRequest API were raised in comments of <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=896897" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;" onclick="this.href=&#39;https://bugs.chromium.org/p/chromium/issues/detail?id\x3d896897&#39;;return true;">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] - <a href="https://opensource.com/article/17/9/intro-ebpf" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fopensource.com%2Farticle%2F17%2F9%2Fintro-ebpf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnlsaalEbXkTLzkXnTsDI8l8sN-w&#39;;return true;">https://opensource.com/article/17/9/intro-ebpf

--
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

INL Owner
Wow, I can tell you don't use adblocking
This almost certainly will completely break them

From: Devlin Cronin <[hidden email]>
Sent: Wednesday, January 23, 2019 11:57:05 AM
To: Chromium Extensions
Cc: [hidden email]
Subject: [crx] Re: Manifest V3: Web Request Changes
 
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, [hidden email] 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)..

On Tuesday, January 22, 2019 at 8:30:31 PM UTC-5, Ivan Koldaev wrote:
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/DM6PR17MB2460BDD5D20DDB01BB4A4CE4AD990%40DM6PR17MB2460.namprd17.prod.outlook.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.
1234 ... 6