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