4 ms·

> Improving content filtering support by providing more generous limits in the declarativeNetRequest API for static rulesets and dynamic rules Anyone here know

> Improving content filtering support by providing more generous limits in the declarativeNetRequest API for static rulesets and dynamic rules Anyone here know more about this? From the article linked in that quote: > We determined that some filter rules, such as those with an action of block or allow, are much safer and are less likely to be abused. They also happen to make up the large majority of ad block filter rules. Based on this, I drafted and shared a proposal in the Web Extensions Community Group to define a set of rules that we consider lower risk and allow up to 30,000 of these. From what I remember of the discourse at the time Manifest v3 was first announced, the most major complaint from developers who were otherwise open to the idea of static filters was that the number of filters allowed was way too small for the modern web. Google's proposed changes seem to address that, maybe? I don't know how effective they are in practice.

ghostwords 3y ago
DNR is better than at launch, but still full of feature gaps. How do you match a redirect response? How do you robustly rewrite URLs based on query parameters?[1] The fundamental problem is that DNR is not an adequate replacement for webRequest. From something I wrote[2] a couple of years ago: > [R]emoving blocking webRequest won’t stop abusive extensions, but will harm privacy and security extensions. If Manifest V3 is merely a step on the way towards a more "safe" (i.e., limited) extensions experience, what will Manifest V4 look like? If the answer is fewer, less-powerful APIs in service of “safety”, users will ultimately suffer. The universe of possible extensions will be limited to what Google explicitly chooses to allow, and creative developers will find they lack the tools to innovate. Meanwhile, extensions that defend user privacy and safety against various threats on the Web will be stuck in the past, unable to adapt as the threats evolve. [1] https://github.com/w3c/webextensions/issues/302 https://github.com/w3c/webextensions/issues/302 [2] https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-st...
- ameshkov 3y ago
  For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”. If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR. Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process. Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.
  - ghostwords 3y ago
    > If the things continue to develop the way they are now I am not comfortable making that assumption! We already went through one "lost decade" for Chrome extensions.
    - ameshkov 3y ago
      Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.
  - xg15 3y ago
    > Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.
    - ameshkov 3y ago
      I would argue that new APIs are better thought through and cover the use cases that the extensions actually need. Let me name a few examples. 1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before. 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them. Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves. Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. edit: formatting

ghostwords 3y ago

DNR is better than at launch, but still full of feature gaps. How do you match a redirect response? How do you robustly rewrite URLs based on query parameters?[1] The fundamental problem is that DNR is not an adequate replacement for webRequest. From something I wrote[2] a couple of years ago: > [R]emoving blocking webRequest won’t stop abusive extensions, but will harm privacy and security extensions. If Manifest V3 is merely a step on the way towards a more "safe" (i.e., limited) extensions experience, what will Manifest V4 look like? If the answer is fewer, less-powerful APIs in service of “safety”, users will ultimately suffer. The universe of possible extensions will be limited to what Google explicitly chooses to allow, and creative developers will find they lack the tools to innovate. Meanwhile, extensions that defend user privacy and safety against various threats on the Web will be stuck in the past, unable to adapt as the threats evolve. [1] https://github.com/w3c/webextensions/issues/302 https://github.com/w3c/webextensions/issues/302 [2] https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-st...

ameshkov 3y ago
For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”. If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR. Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process. Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.
- ghostwords 3y ago
  > If the things continue to develop the way they are now I am not comfortable making that assumption! We already went through one "lost decade" for Chrome extensions.
  - ameshkov 3y ago
    Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.
- xg15 3y ago
  > Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant. Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.
  - ameshkov 3y ago
    I would argue that new APIs are better thought through and cover the use cases that the extensions actually need. Let me name a few examples. 1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before. 2. Dynamic content scripts registration that everyone has waited for so long. 3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them. Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves. Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it. edit: formatting