Hacker News Reader

Comment by shawnz | Hacker News Reader

Ad blockers on Safari effectively have the same weaknesses as ad blockers on Chrome now have since the deprecation of the blocking webRequest API (which Safari never supported).

See https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... for some examples of things you can't do without those APIs.

View on HN

> the blocking webRequest API (which Safari never supported)

This is inaccurate. Safari (Mac) supported it until 2019, and indeed there was a version of uBlock Origin for Safari back then.

I don't think uBlock Origin ever supported Safari?

https://github.com/el1t/uBlock-Safari/issues/158

Ah, unofficial fork

It was a fork. I'm not sure what you mean exactly by "unofficial". Gorhill said at the time that he didn't have time to maintain a Safari version, but he was aware of the fork, which mostly shared code with upstream, and seemingly endorsed the fork.

https://github.com/gorhill/uBlock/wiki/About-Safari-and-Cana...

Interesting, thanks for the correction.

As I understand it, AdGuard uses (in addition to a browser extension) a system-level local network proxy so can do anything to requests and responses?

Confusingly, there are 3 offerings: "AdGuard for Mac", "AdGuard for iOS" and "AdGuard for Safari" and I think it's the first 2 that are the good stuff, even for Safari.

that said, gorhill has made a decent effort on making most uBlock/Adguard filter rules work within dNR.

the only problem is that you just don't have any choice for custom filters, it relies on prebaked resources.

Which is not a Safari restriction. Applications are allowed to revise those resources, they are not hardcoded into the bundle.

Reply on news.ycombinator.com