WebShield – A new wide-spectrum content blocker for Safari (opens in new tab)

That’s a very technical description. The Safari extensions I use already do block YouTube ads. So it’s unclear what WebShield brings to the table in practical terms over existing extensions.

So in a way it's similar to Adguard pro?

I've been pretty happy with 1Blocker across all my Apple devices, but I will probably give this one a try.

AdGuard Pro isn't free, but it works well.

Second the 1Blocker recommendation. Works really well for me for Mac, iPhone, and iPad

I've been using AdGuard Pro happily on all my devices for about ten years now. I'm wondering what adding Ghostery to the mix does on Safari?

Well, for starters ublock origin is the gold standard, and it's free, and it's open source, and it's been refined over many years, and etc. etc. etc.

I'm still surprised by how much inertia there is for Ghostery.

People should have stopped using that extension nearly a decade ago after being sold to an advertising company.

Or after they went closed-source.

Or after they were caught selling user info about blocked ads back to the advertisers so they could figure out how to avoid being blocked.

Or after they started showing their own advertisements to users.

I can't use anything below iOS 17 because I use SwiftData, probably some other newer APIs too. Sorry.

Thank you for this detailed and honest reply.

For Wipr 2, on macOS you can see the rules here: `~/Library/Group Containers/group.wipr2.rules/Rules/` in the JSON files. Kaylee (Wipr dev) sources the blocker list data from these [0] sources.

[0]: https://kaylees.site/wipr-acknowledgements.html

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...

>AdGuard has its own too:

AFAIK only the paid version of adguard has access to these scriptlets. The free version only has content blockers, which puts webshield ahead of adguard.

No; it’s because then, the internet would go from 80% Chromium, to 95% Chromium.

Allowing alternative browser engines does not mean Firefox gets a footing. It means Chromium gets a footing even on iOS, and we start seeing Electron apps on iOS, with every app bundling their own Chromium renderer.

If Apple were forced to allow 3rd party engines on iOS, they might as well shut down WebKit. All hail Blink, the universal engine.

Eh not quite. I switched off Chrome many years ago (on macOS) because it had gotten so bloated and was constantly running my fans.

I remember reading that Chrome had worked on fixing a lot of that bloat (so did FF). But Safari was a breath of fresh air in how fast it worked and didn't seem to constantly kill my battery.

Yes it has the occasional quirks. But I do like that Apple focuses more on UX than just DevEx by trying to implement everything and the kitchen sink web standards.

As others have said, we definitely need alternative browsers and browser engines.

But at the end of the day, it's just mostly WebKit (and Blink derived from it) and Firefox, so it's not like there's all that much competition.

But it's no longer a donation (regardless if that word is used or not) when you offer things like material support of the app in exchange for the money. Then it is actually a support contract. If they are not registered a non-profit in the US, they it's just regular income and they have to pay taxes on it. Because they made a profit.

My point is I don't believe this is a serious project worth giving money to until they can say they have resolved this with Apple.

That should change the calculus for payments, but they

a) still need to affirm their model was deemed acceptable to Apple,

if they're limiting their market to EU users they should

b) say so up front, and

c) limit access to the app and origin of donations by region

because the problems I describe are material for everyone else.