Hey everyone, author of WebShield here! I had no idea this was posted here. Feel free to ask any questions, I'll be more than happy to answer them here (including any that have been posted), if/when I get the time.
Author here (I'm not OP): It converts filter lists to Safari's content blocking API using SafariConverterLib (by AdGuard) and stores advanced blocking (scriptlets, extended css, css & js) in a json file. The WebExtension then reads the json file through native messaging and injects the scriptlets, extended css, css & js. This means that things like YouTube ads can be blocked too, whereas using just the content blocking api won't allow YouTube ads to be blocked
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.
Well, WebShield is free & open source, those extensions may or may not. It's also a single app/codebase across macOS/iOS/iPadOS/visionOS. If you're happy with your current ad blocking setup for Safari, continue using it. I'm not trying to conquer the world.
The only thing that is holding me back from not making safari my primary browser is not having an extension like ublock origin. This seems really promising.
I’m using it too for now, but considering stopping. afaik the tool is not open source (even if it is, still happy to pay for the app), and to me feels a bit too magical and makes me uneasy. I have no idea what it’s downloading, what lists it’s fetching, what kind of content it’s blocking, what it’s blocking on a specific site, whether some site is broken because of it, or even if it’s working at all. I do like how in ublock (or brave), it shows some info like number of things blocked on current site. And then in ublock you can go arbitrarily deep into logs / custom blocking etc.
Author here: No, not really. It uses AdGuard lists, SafariConverterLib by AdGuard for converting filter lists to Safari content blocking format. The only difference is that WebShield works on iOS, iPadOS, visionOS, and macOS as one app & codebase (AdGuard has separate apps for Safari on macOS & iOS), and its completely free & open source, albeit I accept donations, but nothing is behind a paywall, and will never be behind a paywall. I'd rather just stop developing than sell out to ad companies (acceptable ads) or put things behind a paywall.
Wipr 2 is great! And so is the dev, with who I've talked to before. The difference between WebShield & Wipr 2 is WebShield allows you to specifically toggle on/off which lists you'd like, as well as add your own custom lists. Kaylee (Wipr dev) also has to maintain the lists herself (she sources a lot from other lists), so there is a bit of manual maintenance for her, because Wipr is meant to be an "install & forget" app for the most part. There are tradeoffs that come with this design, for example, all scriptlets (called injectables in Wipr), to my knowledge, are injected as as a content script, whereas WebShield is similar but we inject each scriptlet on demand, cache it (not sure if Wipr does caches too), ensure it doesn't re-inject on the same page (more testing needs to be done with this, and I'm not sure if Wipr 2 already checks for this). That's just off the top of my head.
With that said, Wipr 2 is great and very reliable. If you enjoy using it and it fits all your needs, you tried WebShield and didn't feel the need to switch, continue using Wipr! I'm not trying to conquer the world.
I like projects like this since Safari is probably the biggest competitor to Chrome, but historically Apple hasn't been kind to these sorts of extensions. I hope they're able to find a way to make it work, because Safari is well-integrated into the iOS ecosystem.
While everything you're saying is correct, Safari is only the biggest competitor to Chrome because Apple is going out of their way to make it hard or even impossible in the case of iOS for developers to develop well-oiled browsers for their OSes. Just wanted to add that, because I'm pissed.
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.
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.
Good! because people prefer Chrome. People have to go out of their way to install it and they do.
If Safari was better then Safari would stay #1 on iOS. They shouldn't be allowed force this any more than Microsoft was allowed to force IE.
If 3rd party browsers were allowed we'd have had WebGL2 on iOS 4 years earlier. WebGPU 2 years earlier. WebXR several years earlier (Apple is only adding it now and only for Vision Pro), and many other features.
Since they dropped the old web extension support perhaps 10(?) years ago, the new extension system has only grown new capabilities. They even added the ability to dynamically execute JS, which is what enabled these blockers to do things like block YouTube ads.
Have you actually released this or passed Apple's review process? Soliciting external donations for higher level support gets into a grey area about Apple getting their cut from the apps it distributes. If you haven't registered as a non-profit you are also not doing yourself favors.
I would be extremely upset if I donated and then you never made it to the store/got removed from the store because you didn't consider or do due diligence on this process.
I understand this makes complete sense from an app ecology perspective, but if we were to make a similar bulletin for any other community built product..that list might sound a little overbearing.
I agree it's overbearing, but if that is the case they should consider choosing a different method to distribute their app for which they are trying to solicit my money that they don't find overbearing.
Mixing money and third party app distribution platforms that want a cut is complicated and if this is a serious project it would have considered this.
I don't think soliciting external donations is against Apple's rules as long as those solicitations aren't happening within the app. Don't apps like Spotify give discounts for subscriptions bought outside the app?
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.
I still don't think that is against the rules. As long as the app itself is not telling the users to go outside the app to donate/buy things, Apple can't do anything about it.
While that may be true Apple's opinion is the only one that matters and the author has not provided transparency about it. People are entitled to that transparency if they are soliciting money.
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:
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.
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.
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.
Hey everyone, author of WebShield here! I had no idea this was posted here. Feel free to ask any questions, I'll be more than happy to answer them here (including any that have been posted), if/when I get the time.
It would be useful to describe what specifically this adds over existing Safari content blockers in that space.
Author here (I'm not OP): It converts filter lists to Safari's content blocking API using SafariConverterLib (by AdGuard) and stores advanced blocking (scriptlets, extended css, css & js) in a json file. The WebExtension then reads the json file through native messaging and injects the scriptlets, extended css, css & js. This means that things like YouTube ads can be blocked too, whereas using just the content blocking api won't allow YouTube ads to be blocked
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.
Well, WebShield is free & open source, those extensions may or may not. It's also a single app/codebase across macOS/iOS/iPadOS/visionOS. If you're happy with your current ad blocking setup for Safari, continue using it. I'm not trying to conquer the world.
Maybe, unlike the existing ones, this one works
AdGuard Pro isn't free, but it works well.
Is this similar to wBlock origin?
The only thing that is holding me back from not making safari my primary browser is not having an extension like ublock origin. This seems really promising.
What are you missing specifically? I’ve been pretty happy with Ghostery and AdGuard Pro.
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?
Ghostery doesn’t just hide consent banners and blocks tracking cookies, it also automatically opts-out from tracking consent.
https://www.ghostery.com/blog/never-consent-by-ghostery#neve...
Ghostery is the thing you want to block in the first place.
https://web.archive.org/web/20130619042941/https://www.techn...
I see tracking consent opt-outs as pointless and misleading at best because the adtech industry doesn't operate in good faith. Just block them.
What trackers actually obey said consent?
I've been very happy with Wipr.
1blocker works well for me on iOS, iPadOS and MacOS https://1blocker.com/
If you want to use uBlock Origin on Webkit you can do it with Kagi's Orion browser. https://help.kagi.com/orion/browser-extensions/ublock-origin...
Second the 1Blocker recommendation. Works really well for me for Mac, iPhone, and iPad
I thought Ghostery has been the gold standard for a pretty long time now…?
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 have been using Wipr2, 100/100 on my adblock testing.
I’m using it too for now, but considering stopping. afaik the tool is not open source (even if it is, still happy to pay for the app), and to me feels a bit too magical and makes me uneasy. I have no idea what it’s downloading, what lists it’s fetching, what kind of content it’s blocking, what it’s blocking on a specific site, whether some site is broken because of it, or even if it’s working at all. I do like how in ublock (or brave), it shows some info like number of things blocked on current site. And then in ublock you can go arbitrarily deep into logs / custom blocking etc.
I have been using https://github.com/dgraham/Ka-Block for years.
It works great. Kind of strange it's never mentioned when ad blockers are discussed.
Seems to feature a lot of AdGuard filter lists. Does this blocker differ materially from AdGuard?
Author here: No, not really. It uses AdGuard lists, SafariConverterLib by AdGuard for converting filter lists to Safari content blocking format. The only difference is that WebShield works on iOS, iPadOS, visionOS, and macOS as one app & codebase (AdGuard has separate apps for Safari on macOS & iOS), and its completely free & open source, albeit I accept donations, but nothing is behind a paywall, and will never be behind a paywall. I'd rather just stop developing than sell out to ad companies (acceptable ads) or put things behind a paywall.
The bar they need to clear right now seems to be Wipr2
Wipr 2 is great! And so is the dev, with who I've talked to before. The difference between WebShield & Wipr 2 is WebShield allows you to specifically toggle on/off which lists you'd like, as well as add your own custom lists. Kaylee (Wipr dev) also has to maintain the lists herself (she sources a lot from other lists), so there is a bit of manual maintenance for her, because Wipr is meant to be an "install & forget" app for the most part. There are tradeoffs that come with this design, for example, all scriptlets (called injectables in Wipr), to my knowledge, are injected as as a content script, whereas WebShield is similar but we inject each scriptlet on demand, cache it (not sure if Wipr does caches too), ensure it doesn't re-inject on the same page (more testing needs to be done with this, and I'm not sure if Wipr 2 already checks for this). That's just off the top of my head.
With that said, Wipr 2 is great and very reliable. If you enjoy using it and it fits all your needs, you tried WebShield and didn't feel the need to switch, continue using Wipr! I'm not trying to conquer the world.
can you compare/contrast to 1blocker?
I like projects like this since Safari is probably the biggest competitor to Chrome, but historically Apple hasn't been kind to these sorts of extensions. I hope they're able to find a way to make it work, because Safari is well-integrated into the iOS ecosystem.
While everything you're saying is correct, Safari is only the biggest competitor to Chrome because Apple is going out of their way to make it hard or even impossible in the case of iOS for developers to develop well-oiled browsers for their OSes. Just wanted to add that, because I'm pissed.
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 at the end of the day, it's just mostly WebKit (and Blink derived from it) and Firefox
Blink is a separate engine, as it has significantly diverted from WebKit.
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.
Good! because people prefer Chrome. People have to go out of their way to install it and they do.
If Safari was better then Safari would stay #1 on iOS. They shouldn't be allowed force this any more than Microsoft was allowed to force IE.
If 3rd party browsers were allowed we'd have had WebGL2 on iOS 4 years earlier. WebGPU 2 years earlier. WebXR several years earlier (Apple is only adding it now and only for Vision Pro), and many other features.
Yeah, that's the downside. I'm all for Apple to open up their platform. But the browsers will be dead, and everything will be Chrome
Since they dropped the old web extension support perhaps 10(?) years ago, the new extension system has only grown new capabilities. They even added the ability to dynamically execute JS, which is what enabled these blockers to do things like block YouTube ads.
Wipr2 does a pretty good job.
Have you actually released this or passed Apple's review process? Soliciting external donations for higher level support gets into a grey area about Apple getting their cut from the apps it distributes. If you haven't registered as a non-profit you are also not doing yourself favors.
I would be extremely upset if I donated and then you never made it to the store/got removed from the store because you didn't consider or do due diligence on this process.
This shouldn’t really be an issue for EU users, right?
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.
I understand this makes complete sense from an app ecology perspective, but if we were to make a similar bulletin for any other community built product..that list might sound a little overbearing.
I agree it's overbearing, but if that is the case they should consider choosing a different method to distribute their app for which they are trying to solicit my money that they don't find overbearing.
Mixing money and third party app distribution platforms that want a cut is complicated and if this is a serious project it would have considered this.
I don't think soliciting external donations is against Apple's rules as long as those solicitations aren't happening within the app. Don't apps like Spotify give discounts for subscriptions bought outside the app?
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.
I still don't think that is against the rules. As long as the app itself is not telling the users to go outside the app to donate/buy things, Apple can't do anything about it.
While that may be true Apple's opinion is the only one that matters and the author has not provided transparency about it. People are entitled to that transparency if they are soliciting money.
Author doesn't need to. They only need to if they put an external donation link in the app.
Can someone explain what "wide-spectrum content blocker" means and how it differs from other ad blockers available for Safari?
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.
>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.
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...
wondering how many users firefox has lost, myself for sure..
This might be silly but it would be awesome if you added a category for blocking blue check accounts on twitter