4 ms·

> MV3 adblockers are still going to, broadly, work fine, if slightly worse than before. I just don't think this is true, ad blocking will be substantially degr

> MV3 adblockers are still going to, broadly, work fine, if slightly worse than before. I just don't think this is true, ad blocking will be substantially degraded and, more importantly to certain companies involved, the ability to block tracking cookies and request metadata will be almost entirely removed. > just poorly-informed fluff around attempts to rephrase comments from gorhill. gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1253893421 https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss... > There's slightly more concern over privacy blockers I don't know if users of ad blockers make this distinction.

staticassertion 4y ago
> gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. How do you figure? Gorhill actually states that there are many improvements only possible because of V3. What's also said is that for some features in the future there's further investigation required. And the last thing said in that comment is: > Many users of uBO will dislike the limitations of uBOL when compared to uBO. There is no point complaining about it, it's just not for you, it's meant for another kind of users -- you do not have to use it.[..] but I want to offer an option for those who use uBO as an install-and-forget blocker without ever interacting with it. I think you're kind of mischaracterizing the comment.
- AaronFriel 4y ago
  > Gorhill actually states that there are many improvements only possible because of V3. I think that's a charitable - to the Chrome team - misunderstanding of an artificial limitation they've imposed. The improvements are possible without MV3: * declarativeNetRequest is implemented today, they could expose it in MV2 * nothing prevents Google Chrome from continuing to offer the current onBeforeRequest API as a permission extensions can request in MV3 * nothing prevents Google Chrome from working with developers like gorhill, who are sensitive to performance concerns as you'll see below, to develop more powerful APIs that fit within a security and performance profile that satisfies end users, gorhill, and the Chrome team. On performance: While many of the performance improvements are made possible with a declarative API, uBlock Origin uses WebAssembly for an extremely performant fully dynamic blocking implementation that has almost no impact on battery life. (I believe other experiments have shown that blocking these requests yields increases in battery life, even.) You can see some benchmarks here that were posted from his experimentation: https://raw.githack.com/gorhill/uBlock/master/docs/tests/hnset-benchmark.html https://raw.githack.com/gorhill/uBlock/master/docs/tests/hns... On security: gorhill has proven that he's capable of writing WebAssembly to implement highly performant and sandboxed checking of dynamic filters. WebAssembly is in fact the perfect technology for a "declarativeNetRequest" to use. Could Chrome cut the Gordian knot of enabling performant and safe ad blocking extensions with an API that registers a WASM program as web request filter? The program could be limited to pass/fail/redact actions, where redact would involve removing headers, query parameters, trailing path parts. That is, "utm_campaign=..." could be removed, but the extension would not have a side channel for injecting information into requests.
- gorhill 4y ago
  Firefox adopted the `scripting` API and made it available for MV2 extensions: > This API is available in Manifest V3 or higher in Chrome and Firefox 101. In Safari and Firefox 102+, this API is also available in Manifest V2. When I say, it's not possible in MV2, I of course mean Google's version of MV2. --- [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
  - staticassertion 4y ago
    Nice, I definitely think Firefox is doing it the right way.
    - staticassertion 4y ago
      Actually I changed my mind
      - AaronFriel 4y ago
        Not so static, now? :)
LordDragonfang 4y ago
>more importantly to certain companies involved, the ability to block tracking cookies and request metadata will be almost entirely removed. Right, that's precisely what I mean. Trackers are a privacy issue, not an "ad" issue. >I don't know if users of ad blockers make this distinction. Contrary to what people on HN think, the absolute majority of users care little about tracking and a lot about whether there's a huge banner ad in the middle of their content. MV3 does comparatively little to affect the latter (which can be removed through cosmetic blocking). Most users use adblockers purely to get rid of ads. >gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. Right, that's my point. Tech news sites just running specifically gorhill's comments through an "underpaid intern" filter and then printing them, without actually explaining or probably even understanding them. Gorhill is complaining loudly because it makes his specific software worse, and everyone interprets this as "Google getting rid of adblockers".
- stefan_ 4y ago
  You are here to tell us when posed with the question "do you want to block trackers who do nothing but slow down your browsing" users would go "no thank you, only the ads"? That is of course nonsense. Ad blockers can block trackers with much the same mechanisms and it's just a pure and utter improvement at no cost.

staticassertion 4y ago

> gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. How do you figure? Gorhill actually states that there are many improvements only possible because of V3. What's also said is that for some features in the future there's further investigation required. And the last thing said in that comment is: > Many users of uBO will dislike the limitations of uBOL when compared to uBO. There is no point complaining about it, it's just not for you, it's meant for another kind of users -- you do not have to use it.[..] but I want to offer an option for those who use uBO as an install-and-forget blocker without ever interacting with it. I think you're kind of mischaracterizing the comment.

AaronFriel 4y ago
> Gorhill actually states that there are many improvements only possible because of V3. I think that's a charitable - to the Chrome team - misunderstanding of an artificial limitation they've imposed. The improvements are possible without MV3: * declarativeNetRequest is implemented today, they could expose it in MV2 * nothing prevents Google Chrome from continuing to offer the current onBeforeRequest API as a permission extensions can request in MV3 * nothing prevents Google Chrome from working with developers like gorhill, who are sensitive to performance concerns as you'll see below, to develop more powerful APIs that fit within a security and performance profile that satisfies end users, gorhill, and the Chrome team. On performance: While many of the performance improvements are made possible with a declarative API, uBlock Origin uses WebAssembly for an extremely performant fully dynamic blocking implementation that has almost no impact on battery life. (I believe other experiments have shown that blocking these requests yields increases in battery life, even.) You can see some benchmarks here that were posted from his experimentation: https://raw.githack.com/gorhill/uBlock/master/docs/tests/hnset-benchmark.html https://raw.githack.com/gorhill/uBlock/master/docs/tests/hns... On security: gorhill has proven that he's capable of writing WebAssembly to implement highly performant and sandboxed checking of dynamic filters. WebAssembly is in fact the perfect technology for a "declarativeNetRequest" to use. Could Chrome cut the Gordian knot of enabling performant and safe ad blocking extensions with an API that registers a WASM program as web request filter? The program could be limited to pass/fail/redact actions, where redact would involve removing headers, query parameters, trailing path parts. That is, "utm_campaign=..." could be removed, but the extension would not have a side channel for injecting information into requests.
gorhill 4y ago
Firefox adopted the `scripting` API and made it available for MV2 extensions: > This API is available in Manifest V3 or higher in Chrome and Firefox 101. In Safari and Firefox 102+, this API is also available in Manifest V2. When I say, it's not possible in MV2, I of course mean Google's version of MV2. --- [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- staticassertion 4y ago
  Nice, I definitely think Firefox is doing it the right way.
  - staticassertion 4y ago
    Actually I changed my mind
    - AaronFriel 4y ago
      Not so static, now? :)

LordDragonfang 4y ago

>more importantly to certain companies involved, the ability to block tracking cookies and request metadata will be almost entirely removed. Right, that's precisely what I mean. Trackers are a privacy issue, not an "ad" issue. >I don't know if users of ad blockers make this distinction. Contrary to what people on HN think, the absolute majority of users care little about tracking and a lot about whether there's a huge banner ad in the middle of their content. MV3 does comparatively little to affect the latter (which can be removed through cosmetic blocking). Most users use adblockers purely to get rid of ads. >gorhill's comments here indicate many issues remain with MV3 and that it still fails to meet his own requirements. Right, that's my point. Tech news sites just running specifically gorhill's comments through an "underpaid intern" filter and then printing them, without actually explaining or probably even understanding them. Gorhill is complaining loudly because it makes his specific software worse, and everyone interprets this as "Google getting rid of adblockers".

stefan_ 4y ago
You are here to tell us when posed with the question "do you want to block trackers who do nothing but slow down your browsing" users would go "no thank you, only the ads"? That is of course nonsense. Ad blockers can block trackers with much the same mechanisms and it's just a pure and utter improvement at no cost.