←back to thread

143 points tW4r | 1 comments | | HN request time: 0s | source
Show context
busymom0 ◴[] No.43207283[source]
Can someone explain what "wide-spectrum content blocker" means and how it differs from other ad blockers available for Safari?
replies(1): >>43208085 #
TingPing ◴[] No.43208085[source]
To set a baseline: Ad blockers work by a combination of static rulesets and dynamic javascript.

Safari does not support the ruleset format of Chrome/Firefox, so a ruleset has to be maintained for it specifically. In practice this is always the AdGuard ruleset. I doubt a single adblocker doesn't use this as a base.

Beyond that is the custom JS they inject. It's hard to say how good it is but that is the only selling point:

- https://github.com/arjpar/WebShield/tree/cae7629f1c5fb79fe76...

AdGuard has its own too:

- https://github.com/AdguardTeam/AdGuardForSafari/tree/master/... (JS files)

They look similar in a lot of ways, because well they have to, but I haven't done any deep analysis.

Safari extensions will never match uBlock Origin because it simply does not provide the same APIs (webRequest blocking and DNS) that Firefox does. The ruleset format is also more limited.

replies(2): >>43209198 #>>43211630 #
InfiniteVortex ◴[] No.43209198[source]
Safari ad blocker extensions will never be as powerful as uBlock Origin in terms of the sheer number or types of content they can block, but they can be as performant or efficient, or even more so. To my knowledge, uBlock Origin uses its own custom networking engine through webRequest, WebShield uses Safari's content blocking API which is baked into WebKit. When loading a content blocker in Safari (& thus WebKit) rules are converted into DFA in WebKit [0]. Pretty sure this is the code in WebKit [1]. Yes, the content blocking API is more limited than full blown adblock filter list syntax, meaning its not as powerful, but it is more performant & efficient than uBlock Origin, within the subset of rules that it supports. To complement the content blocking API we use scriptlet/extended css/css/js injection in advanced blocking, similar to AdGuard. The AdGuard guys probably know way more about the specifics of how content blocking works in WebKit than I do though. But I do know that the content blocking API in WebKit & Safari is more performant/efficient than uBlock Origin, subject to limitations on powerfulness in terms of the types and number of content that can be blocked as mentioned before.

I still feel like I need to performance test WebShield more to back my claims, so take it with a grain of salt, but based on what I've seen, it is comparable with or better than uBlock Origin in terms of performance/efficiency, not pure power, but again, please take it with a grain of salt, because I can't believe it.

[0]: https://en.wikipedia.org/wiki/Deterministic_finite_automaton [1]: https://github.com/WebKit/WebKit/tree/04edf7716a74170fb0967f...

replies(1): >>43222304 #
1. TingPing ◴[] No.43222304[source]
I agree with what you say, but I think many users care most about coverage. Its not like ublock is slow on a desktop.

It would be great if you did some benchmarking though!

Its also possible to extend WebKits rules, if you can prove minimal performance regression.