4 ms·

> Their (unstated but suspected) goal is to neuter adblocking chrome extensions. Except they didn't. There's already 3-4 adblockers that work perfectly as far

> Their (unstated but suspected) goal is to neuter adblocking chrome extensions. Except they didn't. There's already 3-4 adblockers that work perfectly as far as blocking ads is concerned. They do lose more advanced features, but 99.9% of people with adblockers installed never ever touch those features. To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking.

TingPing 4y ago
This isn't an advanced feature, it's just how to effectively block modern ads and ad networks will just rely on techniques that can't be blocked now.
- hombre_fatal 4y ago
  Is this speculation or has there actually been an analysis of how many ads are unblockable? I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube Just sounds like a bunch of speculative hysteria tbh.
  - HWR_14 4y ago
    Which declarative ad blocker?
  - gorhill 4y ago
    > Is this speculation or has there actually been an analysis of how many ads are unblockable? You could go through all the issues that are solved on a daily basis by filter list maintainers and see how your content blocker deals with those specific issues being solved for uBO. --- [1] https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+is%3Aclosed https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+...
  - Shank 4y ago
    > I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube I do too! But I also run into pages that are broken all the time (pages don't scroll down, entirely white/black pages load with no content, etc). This is with AdGuard's basic filter set and updated filters. uBlock Origin doesn't have these problems.
gorhill 4y ago
> 99.9% of people with adblockers installed never ever touch those [advanced features] Custom matching algorithms and ability to fine tune or expand matching algorithms according to new content blocking challenges are actually a kind of advanced feature that are used by all those users without them ever realizing it since their content blocker work seamlessly on their favorite sites without the need for intervention. The declarativeNetRequest (DNR) API has been quite improved since it was first announced and its great, but since it's the only one we can use now, it's no longer possible to innovate by coming up with improved matching algorithm for network requests. If the DNR had been designed 8 years ago according to the requirements of content blockers back then, it would be awfully equipped to deal with the challenges thrown at content blockers nowadays, so it's difficult to think the current one will be sufficient in the coming years.
- londons_explore 4y ago
  Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome. Obviously, extending an API is a long term commitment, so I can understand the Chrome team wanting to only do it if there is a decent benefit - "it makes my one extension with 10 users work slightly better" probably doesn't cut it.
  - doomrobo 4y ago
    > Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome. This is not at all how API proposals are handled. There are a lot more (time, financial, logical) barriers to a change like this. See the role of the W3C in this: https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-politics-sheeps-clothing https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-p...
    - westurner 4y ago
      It is reasonable to expect BPF or a BPF-like filter. https://en.wikipedia.org/wiki/Berkeley_Packet_Filter https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
robertoandred 4y ago
There was tons of complaining when Safari adopted those restrictions with the same claims and fears that ad blockers were dead forever.
tyingq 4y ago
>To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking. I think it's more nuanced than that. Working around adblockers is hard right now, because there are many different types, and the ones that leverage onBeforeRequest() are the hardest to work around, and are VERY popular. So widespread working around declarative and DNS based adblocking isn't happening, because the publishers rightly recognize it would just drive people to better adblockers. But, once all adblockers are declarative only, it could be an effort worth taking. Also, the Safari comparison is hard because Apple devices do many other things to shore up their adblocker. It has a larger allowed list, and comes along with everything else Apple does to protect privacy and customer-specific targeted ads. Last, if it was really a nothingburger, I'm curious why mobile Chrome has never allowed Chrome extensions.
deleted 4y ago
[deleted]

TingPing 4y ago

This isn't an advanced feature, it's just how to effectively block modern ads and ad networks will just rely on techniques that can't be blocked now.

hombre_fatal 4y ago
Is this speculation or has there actually been an analysis of how many ads are unblockable? I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube Just sounds like a bunch of speculative hysteria tbh.
- HWR_14 4y ago
  Which declarative ad blocker?
- gorhill 4y ago
  > Is this speculation or has there actually been an analysis of how many ads are unblockable? You could go through all the issues that are solved on a daily basis by filter list maintainers and see how your content blocker deals with those specific issues being solved for uBO. --- [1] https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+is%3Aclosed https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+...
- Shank 4y ago
  > I’ve used a declarative ad blocker on iOS for years and haven’t seen ads in a long time, especially not on big websites like Youtube I do too! But I also run into pages that are broken all the time (pages don't scroll down, entirely white/black pages load with no content, etc). This is with AdGuard's basic filter set and updated filters. uBlock Origin doesn't have these problems.

gorhill 4y ago

> 99.9% of people with adblockers installed never ever touch those [advanced features] Custom matching algorithms and ability to fine tune or expand matching algorithms according to new content blocking challenges are actually a kind of advanced feature that are used by all those users without them ever realizing it since their content blocker work seamlessly on their favorite sites without the need for intervention. The declarativeNetRequest (DNR) API has been quite improved since it was first announced and its great, but since it's the only one we can use now, it's no longer possible to innovate by coming up with improved matching algorithm for network requests. If the DNR had been designed 8 years ago according to the requirements of content blockers back then, it would be awfully equipped to deal with the challenges thrown at content blockers nowadays, so it's difficult to think the current one will be sufficient in the coming years.

londons_explore 4y ago
Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome. Obviously, extending an API is a long term commitment, so I can understand the Chrome team wanting to only do it if there is a decent benefit - "it makes my one extension with 10 users work slightly better" probably doesn't cut it.
- doomrobo 4y ago
  > Nothing stops the API evolving... Anyone can make a build of Chromium with a better API, test it out with their own extension, and if it works better, then they can send a PR to get that API into Chrome. This is not at all how API proposals are handled. There are a lot more (time, financial, logical) barriers to a change like this. See the role of the W3C in this: https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-politics-sheeps-clothing https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-p...
  - westurner 4y ago
    It is reasonable to expect BPF or a BPF-like filter. https://en.wikipedia.org/wiki/Berkeley_Packet_Filter https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

robertoandred 4y ago

There was tons of complaining when Safari adopted those restrictions with the same claims and fears that ad blockers were dead forever.

tyingq 4y ago

>To claim that this neuters adblocking is truly ridiculous. It also ignores that Safari has the exact same restrictions yet no one complains that Apple wanted to neuter ad blocking. I think it's more nuanced than that. Working around adblockers is hard right now, because there are many different types, and the ones that leverage onBeforeRequest() are the hardest to work around, and are VERY popular. So widespread working around declarative and DNS based adblocking isn't happening, because the publishers rightly recognize it would just drive people to better adblockers. But, once all adblockers are declarative only, it could be an effort worth taking. Also, the Safari comparison is hard because Apple devices do many other things to shore up their adblocker. It has a larger allowed list, and comes along with everything else Apple does to protect privacy and customer-specific targeted ads. Last, if it was really a nothingburger, I'm curious why mobile Chrome has never allowed Chrome extensions.

deleted 4y ago

[deleted]