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.
Will it also show up as multiple extensions (like it does for AdGuard) if I want to use more than 1 type of blocking/lists? (I am aware that it is Apple's artificially forced limitation but thought I will still ask and whether you folks have found a way around it)
WebShield shows up as multiple extensions, 1 content blocker for each category, and 1 for advanced blocking (a webextension). This is because each content blocker, I believe IIRC, has a limit of 150k rules.
If your motivation is to make it free and open-source because there is no alternative that isn’t, but otherwise it doesn’t add any new capabilities that aren’t already available in other products, then that’s very helpful to know. The problem when seeing a submission and GitHub readme like this one is that it’s missing that information. One wonders whether there is any new interesting capability that may be worth giving this a shot, or what else the motivation might be for starting a new software for which a number of well-established alternatives already exist.
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.
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: 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.
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.
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.
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.
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.
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.
In case it helps, at least on desktop browsers, there is a toggle switch to disable autoplay.
I agree about shorts. I’ve repeatedly “removed” them by clicking “less like this” under the ellipsis next to the Shorts heading, but they keep coming back. I’ve also submitted UX feedback about this customer hostile (I pay for YouTube premium) pattern. It’s frustrating when features like this are force fed to you.
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.
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.
I'd rather have an open platform with free choice (including the side effect of Chrome taking even more market share) instead of Apple forcing users to use their browser. I definitely dislike Chrome and you may unfortunately be right with your projection, but forcing people to use a different browser does not help the greater cause IMO.
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.
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.
That said, as a frontend dev, I very very rarely run into real world issues between Safari and Chrome. More often it's Firefox/Gecko that lags behind, usually in some sort of graphics optimization (SVG and canvas stuff). Also some differences in WebGL and webgpu support, but those are niche enough that it's not a big deal yet.
That's true, I'm mostly pissed about Apple locking down the iOS browser ecosystem, which is not the case on macOS.
While I think Firefox and Chrome did not have a level playing field especially the release of the M1, because Apple has started optimizing Safari for their arm64 platform for example way earlier than FF/Chrome even could. Also, obviously, Safari can focus on a single OS while Chrome/Firefox has a lot more to manage here. But I mean, that's not Apples fault.
Still, while I also experienced the problems you referenced with Firefox on my M1 for months or a year, it has greatly improved and IMO is at this point on par with Safari. With the plus of being open, having a huge community and heavy customization options, and privacy. But with the minus of being ugly in comparison to Safari, I must say.
So yeah I mostly am in line with your opinion, apart from one thing:
> so it's not like there's all that much competition.
This, at least this is my opionion, is no argument. It's playing down the importance of free choice IMO. It should not be more okay to disallow alternative browsers based on the existence of alternatives. I mean, if they never allow it, there will never be any. We can just hope that at some point some competitors will rise again, maybe Firefox will get a bigger foothold, or Ladybird, or Servo, or whatever. I'm just trying to keep my hopes high here, haha.
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 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.
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.
Yes! Me and 0xCube created WebShield & wBlock respectively in parallel in close collaboration with each other. They're pretty much sister projects. I do think since I create more free time for myself, WebShield has (some) more features - just off the top of my head: iOS/iPadOS/visionOS support. wBlock does currently have an auto updater for filter lists when you open the app though, which WebShield doesn't have, but I'm working on it!
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.
Will it also show up as multiple extensions (like it does for AdGuard) if I want to use more than 1 type of blocking/lists? (I am aware that it is Apple's artificially forced limitation but thought I will still ask and whether you folks have found a way around it)
WebShield shows up as multiple extensions, 1 content blocker for each category, and 1 for advanced blocking (a webextension). This is because each content blocker, I believe IIRC, has a limit of 150k rules.
If your motivation is to make it free and open-source because there is no alternative that isn’t, but otherwise it doesn’t add any new capabilities that aren’t already available in other products, then that’s very helpful to know. The problem when seeing a submission and GitHub readme like this one is that it’s missing that information. One wonders whether there is any new interesting capability that may be worth giving this a shot, or what else the motivation might be for starting a new software for which a number of well-established alternatives already exist.
What do you use that blocks YouTube ads?
So in a way it's similar to Adguard pro?
Maybe, unlike the existing ones, this one works
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.
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.
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
The creator of uBlock is again trying to make uBlock Origin Lite work in Safari.
https://github.com/uBlockOrigin/uBOL-home/issues/52#issuecom...
They might need some help, not much visible progress since it started.
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?
In the EU, they are legally obliged to do so.
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've been very happy with Wipr.
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.
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.
Are you using anything new in iOS 17?
It would be nice to be able to run it on my iPhone which is stuck on 16.2 because of TrollStore and Dopamine
I can't use anything below iOS 17 because I use SwiftData, probably some other newer APIs too. Sorry.
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.
Thank you for this detailed and honest reply.
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.
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
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.
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...
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.
>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.
I think its open source, but yes the app is paid.
Is it possible to disable autoplay next video on YouTube?
And disable YouTube shorts?
Thank you for developing open source extension.
In case it helps, at least on desktop browsers, there is a toggle switch to disable autoplay.
I agree about shorts. I’ve repeatedly “removed” them by clicking “less like this” under the ellipsis next to the Shorts heading, but they keep coming back. I’ve also submitted UX feedback about this customer hostile (I pay for YouTube premium) pattern. It’s frustrating when features like this are force fed to you.
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.
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.
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
I'd rather have an open platform with free choice (including the side effect of Chrome taking even more market share) instead of Apple forcing users to use their browser. I definitely dislike Chrome and you may unfortunately be right with your projection, but forcing people to use a different browser does not help the greater cause IMO.
I agree, I'm just sad it has come down to this
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.
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.
How significantly could it actually change? Maybe the process model, etc but I doubt most of the layout algorithms etc have changed much.
Blink forked from Webkit more than a decade ago. There are tests that try to measure their compatibility, like https://wpt.fyi/results/?label=experimental&label=master&ali... (part of https://web-platform-tests.org/). They also have different JS engines these days (V8 vs JSCore).
That said, as a frontend dev, I very very rarely run into real world issues between Safari and Chrome. More often it's Firefox/Gecko that lags behind, usually in some sort of graphics optimization (SVG and canvas stuff). Also some differences in WebGL and webgpu support, but those are niche enough that it's not a big deal yet.
That's true, I'm mostly pissed about Apple locking down the iOS browser ecosystem, which is not the case on macOS. While I think Firefox and Chrome did not have a level playing field especially the release of the M1, because Apple has started optimizing Safari for their arm64 platform for example way earlier than FF/Chrome even could. Also, obviously, Safari can focus on a single OS while Chrome/Firefox has a lot more to manage here. But I mean, that's not Apples fault.
Still, while I also experienced the problems you referenced with Firefox on my M1 for months or a year, it has greatly improved and IMO is at this point on par with Safari. With the plus of being open, having a huge community and heavy customization options, and privacy. But with the minus of being ugly in comparison to Safari, I must say.
So yeah I mostly am in line with your opinion, apart from one thing:
> so it's not like there's all that much competition.
This, at least this is my opionion, is no argument. It's playing down the importance of free choice IMO. It should not be more okay to disallow alternative browsers based on the existence of alternatives. I mean, if they never allow it, there will never be any. We can just hope that at some point some competitors will rise again, maybe Firefox will get a bigger foothold, or Ladybird, or Servo, or whatever. I'm just trying to keep my hopes high here, haha.
Wipr2 does a pretty good job.
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.
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.
I've been using this here:
https://github.com/0xCUB3/wBlock
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 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.
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.
wondering how many users firefox has lost, myself for sure..
Is this similar to wBlock?
Yes! Me and 0xCube created WebShield & wBlock respectively in parallel in close collaboration with each other. They're pretty much sister projects. I do think since I create more free time for myself, WebShield has (some) more features - just off the top of my head: iOS/iPadOS/visionOS support. wBlock does currently have an auto updater for filter lists when you open the app though, which WebShield doesn't have, but I'm working on it!
This might be silly but it would be awesome if you added a category for blocking blue check accounts on twitter