| > 2015 — Content blocking comes to Safari and iOS typo. He means "Safari on iOS". Safari on desktop had normal extension-based ad blocking since day 1. Then the content blocking API came to iOS then later the same API in macOS. > • No debugging tools perhaps in 2015 -- I wouldn't know -- but today it's certainly debuggable with the help of a macOS host. Much like remote gdb. > The maximum number of rules limitation is a huge problem, not a problem at all. rules limitation is per filter but each adblocker can install multiple filters. I suppose the rules limitation is for latency reasons, in case of a poorly designed blocker. > It was disproportionately hard to maintain a completely different filter list for Safari alone. Completely false. filters are regex's. It's trivial to use the same source list with whatever filter technology. I guess because this article is content marketing, and not academic research, these errors (and omissions) are ok. But I do wish, that given the title, the author had bothered to mention that Bing inserts ads that are not blockable via simple URL filters. adblock+ currently doesn't handle them and I believe they are not handle-able at all via the Safari content filter API. By extension => ad blockers are doomed. So yeah, he's not going to say that because he's selling an ad blocker ... |
2. The maximum number of rules IS a problem and it is there only because the current implementation consumes to much memory and slow to compile a content blocker. WebKit devs may allow us to pull request an alternative implementation (there’s an ongoing discussion on bwo), and if there are no performance issues, the limit will be increased.
3. Regarding maintaining a filter list, traditional blockers do not use regexes unless it is really really necessary. What’s written in this post is by people who maintain filter lists for over 10 years.