Hacker News new | ask | show | jobs
by viktorcode 1859 days ago
There's some misconceptions being put forth in the article which I, as a developer of a Safari ad blocker, would like to address.

Content blockers are limited by design to ensure privacy and speed, but they may work together with other kinds of Safari extension. So, when AdGuard guys say that the only debugging tool you can use is Console, know that this isn’t true. There’s SFSafariExtensionHandler API which you can use with blockers as another extension with higher privileges to track who blocked what. Very handy in debugging (and informative for the user).

Should I say that converting something like EasyList to Safari content blocker json is trivial? It is. Granted, ABP has more capabilities in its extended syntax, so you won’t be able to convert everything. There's also some rules that don’t match 1 to 1, but it isn’t something that can’t be solved.

Compiling speed, for the process that happens once the blocker rules json is changed, is irrelevant for the users, unlike battery life. Thanks to the compilation, content blockers have less overhead.

The number of rules limit is a non-issue. As explained in the original, EasyList has lot of mergeable rules. I may add that it has some overlapping rules too. And if for whatever reason you hit 50k limit, you can add another content blocker extension to your app.

And the most important thing. It seems that AdGuard guys don’t get why content blockers in Safari don’t run scripts. It’s privacy. But Safari itself doesn’t prevent you from doing that, only not as a part of content blocker extension that is privacy-safe.

Speaking of YouTube ads, yeah, it’s a pain point. By blocking resources you can get to the point where an ad will be a white screen or a video loading delay. To get around those you have to get beyond what content blockers are offering. I’m thinking about adding that capability into my blocker, but it isn’t a priority.

6 comments

>The number of rules limit is a non-issue

The big controversy some time back when Chrome wanted to implement a limit just like this with Manifest v3 says otherwise. This was both from users and adblock developers and it is exactly as bad as people said it would be. Saying it is a good idea because of privacy risks is completely off the rails. Sure you might run a tiny risk but without a proper adblocker like uBlock you do run a risk on every single webpage you open and unlike a good adblokcer you have no idea if you can trust a webpage until after they have already harvested everything they can about you. You cannot uninstall yourself from the thousands of databases you get added to to so it is in a totally other ballpark.

> Sure you might run a tiny risk.

Having a third party monitor and inject code into every page I visit on the internet or intranet means you are trusting the browser extension as much as you are trusting the browser manufacturer themselves.

The popularity of content blocking means the evaluation of lists of hundreds of thousands of rules on every page request becomes a significant source of slower page load speed. It is not surprising that the browser makers would try to add highly optimized, native code to execute these lists.

>Having a third party monitor

If you install an extension that shares your browsing habits then that is on you of course but good ad-blocking extensions doesn't do that and if the data doesn't leave the extension it isn't really monitoring you. I would personally trust the author of uBlock Origin and the in-built uBO made lists over Safari and Chrome any day. Both Apple and Google are running advertisement services so I don't see any reason to ever put any trust in them doing what is best for the user in blocking ads. I wouldn't really trust Mozilla that much either come to think of it.

>hundreds of thousands of rules on every page request becomes a significant source of slower page load speed

This is a myth really. Almost all websites the average user visit have some form of advertisement and/or tracking. Such sites load much faster with any good and modern ad-blocker installed. Besides, it is not like any developer worth his salt would run through hundreds of thousands of URLs looking for a match. The only time it does add any overhead is on a site with nothing to block at all and the amount is tiny compared to the time wasted on all the other sites.

Note that the rules limit has now been increased from 50k to 150k. Sorry if we failed to publicize this sufficiently.
As someone who contributed to the post we're discussing, let me please respond.

> There’s SFSafariExtensionHandler API which you can use with blockers as another extension with higher privileges to track who blocked what.

I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script that will get some information about what's blocked, but it's far from what's required.

Just compare what Safari provides with AdGuard's filtering log on any other platform or with uBlock Origin's log. The lack of such tool is the main reason filters maintainers avoid dealing with Safari.

> Compiling speed, for the process that happens once the blocker rules json is changed, is irrelevant for the users

Compiling speed is the reason for the rules limitation.

> There's also some rules that don’t match 1 to 1, but it isn’t something that can’t be solved.

Unfortunately, there is something that cannot be solved, and YT is a great example of that something.

> The number of rules limit is a non-issue

I have to disagree here.

We're not dealing with EasyList alone, there're many other lists (regional lists for instance). You may say - okay, let's split them all to different content blockers. There's a serious problem with that, though. Different content blockers are completely independent. However, that's not how those lists are being developed - there're lists that are supposed to influence each other.

Let's take the simple example - unblocking something. For instance, here is the most obvious example that happens all the time. There may be a regional list that unblocks something blocked by EasyList (or EasyPrivacy) because this "something" breaks an important website in that region. Putting EasyList into one content blocker and the regional list into another breaks the regional list.

> And the most important thing. It seems that AdGuard guys don’t get why content blockers in Safari don’t run scripts. It’s privacy. But Safari itself doesn’t prevent you from doing that, only not as a part of content blocker extension that is privacy-safe.

We accept that argument despite me being literally sick of hearing it (so there's privacy on iOS, but no privacy on macOS since scripts are allowed to extensions there, okaay).

What's important is that we do not propose allowing running arbitrary scripts. We propose extending the declarative API in a controlled manner and it does not conflict with Safari vision.

Also, that's just one of the feature requests (and bug reports) reported over the years.

edit: typos

> I am not sure what you mean here. This API (available only on macOS) does allow injecting scripts and stylesheets, it does not provide any feasible debugging tools. Granted, you may inject a script that will get some information about what's blocked, but it's far from what's required.

SFSafariExtensionHandler implements SFSafariExtensionHandling protocol, which has this function:

optional func contentBlocker(withIdentifier contentBlockerIdentifier: String, blockedResourcesWith urls: [URL], on page: SFSafariPage)

So, this is used in statistics extension that prevents me ever looking into the console. Helps to shorten the time it takes to add a new rule and see if it works.

> Let's take the simple example - unblocking something. For instance, here is the most obvious example that happens all the time. There may be a regional list that unblocks something blocked by EasyList (or EasyPrivacy) because this "something" breaks an important website in that region. Putting EasyList into one content blocker and the regional list into another breaks the regional list.

I totally agree! This is one of the reasons I don't use those lists as is. Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.

> We accept that argument despite me being literally sick of hearing it (so there's privacy on iOS, but no privacy on macOS since scripts are allowed to extensions there, okaay).

The statement that there's no privacy on macOS is incorrect. The user can see what privileges different extensions require, and can enable only those they are okay with, like content blockers. Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.

> SFSafariExtensionHandler implements SFSafariExtensionHandling protocol, which has this function

First of all, shame on me for missing this, and thank you for pointing this out.

Unfortunately, this still does not solve the issue in question - we cannot figure out which rule was triggered. But it is definitely better than nothing, at least knowing what's blocked we can try creating something resembling a debugging tool.

> Thankfully, many unblock rules can be merged into the corresponding block rules in the form of "unless-domain" specifier.

Some of them can be handled this way, some of them cannot. Trying to handle all possible issues automatically right on the device is not at all as trivial as simply converting EasyList. And we need to do it that way (real-time, on device) because our goal is not to just convert a few lists, but also to provide maintainers with a tool they can use to develop their lists and test&fix them for Safari.

> Due to their design, content blocker extensions can guarantee privacy, unlike the ones that can run JS code.

Content blockers that can run JS code can guarantee privacy better by doing their work better than the others.

Anyways, let's not go further on this, we won't change each others view on this and we've already stated our positions.

My point was that we want to extend the declarative API, it has nothing to do with running JS.

> Unfortunately, this still does not solve the issue in question - we cannot figure out which rule was triggered. But it is definitely better than nothing, at least knowing what's blocked we can try creating something resembling a debugging tool.

Yes, such a tool should exist - but I am not surprised it isn't in the API, since the input list has been compiled down at that point.

You may be amused to know that I debug my content blockers by keeping around a debug build if WebKit with a handful of breakpoints at the right spots to trace them. The experience really does suck…
Well, I have the same exact experience and frankly, it is not what I intend to repeat again.

At least developers can do that. But most of the people who maintain filter lists are not developers and cannot afford enjoying compiling WebKit for the sake of finding what exact rule has blocked this or hidden that.

Honest question: Why not just drop support for Safari? If Apple wants to make it hard to write content blockers, they can do without content blockers, and the users can see ads and eventually switch to a browser that doesn't show them ads.
I do honestly believe they want to make content blockers good. Maybe the problem is that we don't communicate our pains good enough, maybe it's that they don't hear us sometimes, but I think that we have the common goal and this post will help them understand us better.
I see, thank you. Hopefully it's just about not enough extension writer feedback, fingers crossed it'll get addressed!
The browser they switch to is more likely than not to be Chrome, furthering Google's control of the web.
> as a developer of a Safari ad blocker

As a Safari user and someone that wants a better browser blocker I really want to know what ad blocker you develop. May I suggest you add it to your HN profile

Do you have a link for your ad blocker? Thanks!
> but it isn’t a priority.

I would kill for this.

Unpopular opinion: you can subscribe to YouTube Premium to stop ads on YT on all your devices
Popular opinion: Youtube premium is laughably overpriced (in the UK anyway) due to bundling with the totally unrelated youtube music service.

The premium cost of 11.99 GBP per month gets you: * No ads. * Additional music service I don't want. * No additional made-for-youtube video content that I'm aware of. * The app removes one user-hostile non-feature: it no longer refuses to play audio while in the background (iOS). * The app gains no new features, The iOS system wide Picture-in-picture that every other video service supports is still blocked, including from the Safari browser.

Considering that I get the only features I want in desktop Firefox for free, it's incredibly poor value and badly marketed. They could get perhaps 2 GBP a month for no ads, but their other user hostile behaviour on iOS and that price makes it a joke.

The ads are so intrusive, frequent and low quality that I just stopped using youtube on iOS completely. Good job.

I set Insight [0] browser as the default browser on my iPhone and iPad just so that I can click links to YouTube that I get sent without having to watch some of the worst advertising ever produced. I still actually _use_ Safari as my main browser though.

[0] https://insightbrowser.com

I did yet I still get the embedded ads (lots of VPNs,“brilliant“ subscriptions) YouTubers rely on to make a living because while YouTube shares Premium revenues with Creators it doesn’t allow them to enable a version of their Videos without „sponsored content“ for subscribers. And whats more, because the YouTube Algorithm is totally broken with regards to recency bias, if friends send me links to YouTube Videos that are even slightly political, or related to covid, or any more popular category than what I like to watch, then I have to open them in an incognito tab and get all the ads because I don’t want to have my feed filled with that kind of content for weeks. When I use the App it even features it’s own incognito mode but even though I’m logged in the app, when I switch to incognito it shows me ads. So yea ad blocking is the best option as long as it remains feasible.
You might like that: https://sponsor.ajay.app/