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 anoth

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