Hacker News new | ask | show | jobs
by ameshkov 1863 days ago
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

2 comments

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