4 ms·

Remember the discussion about Manifest V3, eliminating webRequest API [1] which results in Adblockers being thrown out of the Chrome ecosystem? Guess what the

Remember the discussion about Manifest V3, eliminating webRequest API [1] which results in Adblockers being thrown out of the Chrome ecosystem? Guess what the state is, now, 1 year later ... the declarativeWebRequest API is still on hold; and it's not supported outside of Beta Channel, and there are no plans to move it to stable. [2] Its documentation still states the same as it did half a year ago: "Note: this API is currently on hold, without concrete plans to move to stable. Use the chrome.declarativeWebRequest API to intercept, block, or modify requests in-flight." ... which effectively means that there's no way to block or modify request/response headers in Manifest V3, which is essential for Adblockers because they tend to override the Content-Security-Policy and remove headers like "Cookie" or "Set-Cookie" etc. And now we have the Chrome Web Store moving ahead with the Manifest V3 rollout. [3] [1] https://developer.chrome.com/docs/extensions/reference/webRequest/ https://developer.chrome.com/docs/extensions/reference/webRe... [2] https://developer.chrome.com/docs/extensions/reference/declarativeWebRequest https://developer.chrome.com/docs/extensions/reference/decla... [3] https://blog.chromium.org/2020/12/manifest-v3-now-available-on-m88-beta.html https://blog.chromium.org/2020/12/manifest-v3-now-available-...

lima 6y ago
> Remember the discussion about Manifest V3, eliminating webRequest API [1] which results in Adblockers being thrown out of the Chrome ecosystem? The whole point of declarativeNetRequest is to make it safer and faster to use adblockers. The tradeoff is fewer rules and less expressivity. As someone who couldn't live without an adblocker, I appreciate it and look forward to it because it removes a massive security risk (image the carnage if one of the major adblocker extensions get compromised). Your citations do not support the claim that "It's only a matter of months before Adblockers won't work anymore.". There's plenty of reasons to not like Chrome, but this is not a justification for spreading FUD. In fact, the very blog post you cite states that "There is not an exact date for removing support for Manifest V2 extensions" and has a quote from the Adblock Plus team, praising the collaboration with Chromium.
- cookiengineer 6y ago
  > Your citations do not support the claim that "It's only a matter of months before Adblockers won't work anymore.". Yes, I agree. I removed that part of my statement. Still, the declarativeWebRequest API does not allow to filter out tracking-related headers from incoming responses or sent requests. I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declaration of all protocol schemes and host suffixes; which is very bad if a website can pretty much do whatever it wants when it executes js code. > In fact, the very blog post you cite states that "There is not an exact date for removing support for Manifest V2 extensions" and has a quote from the Adblock Plus team, praising the collaboration with Chromium. You know that eyeo GmbH were the ones with the "Acceptable Ads" initiative that are literally forcing websites to pay them money so that their ads continue to work, right? Personally, I would take their comment with a grain of salt. For their whitelisting-ads use case the API works; for the use case of uBlock Origin et al - it doesn't.
  - lima 6y ago
    > I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declaration of all protocol schemes and host suffixes; which is very bad if a website can pretty much do whatever it wants when it executes js code. Yes, but this is a good thing. This kind of intrusive logic with full access to view and modify request data does not belong in a Chrome extension that can be updated by a single account at a moment's notice through the store, with zero peer review (unlike changes to Chrome itself). This is much safer to implement in the browser core. If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way.
    - cookiengineer 6y ago
      > If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way. You're welcome to prove me wrong by implementing an Ad-Blocker that can override Content-Security-Policy by default; and incrementally allow to execute things. As Google continues the Manifest V3 rollout, their priorities seem to be not on that specific degradation of this featureset; and that was all I'm saying. I've been working on my own Extension for the last week [1], and I had to switch back to Manifest V2 because there was no way to create an Adblocker that's based on a concept that allows the user to select what should be executed; as the Content-Security-Policy header couldn't be set and malicious HTTP headers couldn't be filtered for all domains by default. You claim that the new API is a full replacement of the featureset, so rather than saying that I'd welcome a hint to some examples or other evidence I'm probably missing here. [1] https://github.com/tholian-network/stealthify https://github.com/tholian-network/stealthify

lima 6y ago

> Remember the discussion about Manifest V3, eliminating webRequest API [1] which results in Adblockers being thrown out of the Chrome ecosystem? The whole point of declarativeNetRequest is to make it safer and faster to use adblockers. The tradeoff is fewer rules and less expressivity. As someone who couldn't live without an adblocker, I appreciate it and look forward to it because it removes a massive security risk (image the carnage if one of the major adblocker extensions get compromised). Your citations do not support the claim that "It's only a matter of months before Adblockers won't work anymore.". There's plenty of reasons to not like Chrome, but this is not a justification for spreading FUD. In fact, the very blog post you cite states that "There is not an exact date for removing support for Manifest V2 extensions" and has a quote from the Adblock Plus team, praising the collaboration with Chromium.

cookiengineer 6y ago
> Your citations do not support the claim that "It's only a matter of months before Adblockers won't work anymore.". Yes, I agree. I removed that part of my statement. Still, the declarativeWebRequest API does not allow to filter out tracking-related headers from incoming responses or sent requests. I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declaration of all protocol schemes and host suffixes; which is very bad if a website can pretty much do whatever it wants when it executes js code. > In fact, the very blog post you cite states that "There is not an exact date for removing support for Manifest V2 extensions" and has a quote from the Adblock Plus team, praising the collaboration with Chromium. You know that eyeo GmbH were the ones with the "Acceptable Ads" initiative that are literally forcing websites to pay them money so that their ads continue to work, right? Personally, I would take their comment with a grain of salt. For their whitelisting-ads use case the API works; for the use case of uBlock Origin et al - it doesn't.
- lima 6y ago
  > I mean, you cannot declare the rules via the RequestMatcher and know what headers are going to be sent or received in advance, as the API expects full declaration of all protocol schemes and host suffixes; which is very bad if a website can pretty much do whatever it wants when it executes js code. Yes, but this is a good thing. This kind of intrusive logic with full access to view and modify request data does not belong in a Chrome extension that can be updated by a single account at a moment's notice through the store, with zero peer review (unlike changes to Chrome itself). This is much safer to implement in the browser core. If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way.
  - cookiengineer 6y ago
    > If the declarativeNetRequest API is insufficiently expressive, then it needs to be improved to handle those use cases instead of sticking with the old way. You're welcome to prove me wrong by implementing an Ad-Blocker that can override Content-Security-Policy by default; and incrementally allow to execute things. As Google continues the Manifest V3 rollout, their priorities seem to be not on that specific degradation of this featureset; and that was all I'm saying. I've been working on my own Extension for the last week [1], and I had to switch back to Manifest V2 because there was no way to create an Adblocker that's based on a concept that allows the user to select what should be executed; as the Content-Security-Policy header couldn't be set and malicious HTTP headers couldn't be filtered for all domains by default. You claim that the new API is a full replacement of the featureset, so rather than saying that I'd welcome a hint to some examples or other evidence I'm probably missing here. [1] https://github.com/tholian-network/stealthify https://github.com/tholian-network/stealthify