4 ms·

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

by 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
tristan957 6y ago
Ahh yes, please go on and defend a billion-dollar company who has no reason to continue letting ad-blockers exist. If you are for taking away APIs that uBlock Origin needs to operate, you are on the wrong side of history and should re-evaluate your position. The lead dev of uBlock Origin can be trusted so much more than Google. You are the one spreading FUD here by claiming that the new API is so much better than the old one. Chrome is a shitty browser. Google is a shitty company. Stop defending shit.
- lima 6y ago
  > Chrome is a shitty browser. Google is a shitty company. Stop defending shit. > You are the one spreading FUD here by claiming that the new API is so much better than the old one. This kind of language is not welcome here. Please have a look at the guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html I read the design documents and I'm convinced that the new API is a big improvement, and that the design decision was made in good faith and for technical, not political reasons. The uBlock Origin developer is very trustworthy, but there's so many things that can go wrong - like a workstation, repository, signing key or account compromise. It's a massive single point of failure. Anyone who can sneak malicious code into the extension has instant and unlimited access to millions of browsers and sensitive personal and company data. A project like Chrome has extensive processes and safeguards to prevent this kind of compromise, including strict code review. As far as I can tell, uBlock has no code review process[1]. We need to move away from such points of failure no matter how well-intentioned they are. [1]: https://github.com/gorhill/uBlock/commits/master https://github.com/gorhill/uBlock/commits/master The webRequest API also forces a lot of IPC overhead and serialization in the runtime, no matter how fast the extension itself is. uBlock is very, very fast - but it's still a lot slower than native code in the core. I'm not against adblocking or in favor of stripping away adblocker features, but why not implement it right in the core of the browser, where it belongs? Chrome is open source, if Google doesn't want to do it, another vendor or open source project most certainly could.

by lima 6y ago

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

tristan957 6y ago

Ahh yes, please go on and defend a billion-dollar company who has no reason to continue letting ad-blockers exist. If you are for taking away APIs that uBlock Origin needs to operate, you are on the wrong side of history and should re-evaluate your position. The lead dev of uBlock Origin can be trusted so much more than Google. You are the one spreading FUD here by claiming that the new API is so much better than the old one. Chrome is a shitty browser. Google is a shitty company. Stop defending shit.

lima 6y ago
> Chrome is a shitty browser. Google is a shitty company. Stop defending shit. > You are the one spreading FUD here by claiming that the new API is so much better than the old one. This kind of language is not welcome here. Please have a look at the guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html I read the design documents and I'm convinced that the new API is a big improvement, and that the design decision was made in good faith and for technical, not political reasons. The uBlock Origin developer is very trustworthy, but there's so many things that can go wrong - like a workstation, repository, signing key or account compromise. It's a massive single point of failure. Anyone who can sneak malicious code into the extension has instant and unlimited access to millions of browsers and sensitive personal and company data. A project like Chrome has extensive processes and safeguards to prevent this kind of compromise, including strict code review. As far as I can tell, uBlock has no code review process[1]. We need to move away from such points of failure no matter how well-intentioned they are. [1]: https://github.com/gorhill/uBlock/commits/master https://github.com/gorhill/uBlock/commits/master The webRequest API also forces a lot of IPC overhead and serialization in the runtime, no matter how fast the extension itself is. uBlock is very, very fast - but it's still a lot slower than native code in the core. I'm not against adblocking or in favor of stripping away adblocker features, but why not implement it right in the core of the browser, where it belongs? Chrome is open source, if Google doesn't want to do it, another vendor or open source project most certainly could.