It's one cat and millions of mice that multiply rapidly. Ads networks that use random unpredictable domains are intractable by the static blacklist approach. Not only that: ads networks can watch the public blacklist and adjust their domains accordingly. If declarative API was about security, Apple would rather block network access for adblockers.

Agreed about Firefox. My goal here is to call out the hypocrisy of the declarative API. So I want to repeat myself that the declarative API is about giving ads networks an easy way to not get blocked, while using performance and security as false arguments that impress only those who know nothing about performance and security.

You know; I just realized I should clarify some confusion I myself may have introduced here. My original comment suggests the trigger is always matching a domain regex but domain isn't the only trigger. Content blocker authors can make use of one or more of seven different triggers. For example:

    `load-type`: An array of strings that can include one of two mutually exclusive values. If not specified, the rule matches all load types. `first-party` is triggered only if the resource has the same scheme, domain, and port as the main page resource. `third-party` is triggered if the resource is not from the same domain as the main page resource.

So our concerns about the cat and mouse game is true, but only for domain triggers.

Actually, I've been using content blockers on iOS and I haven't noticed any ads coming through. That's not to say they won't/don't ever but my browsing experience is noticeably smooth on that platform.