I’ve been curious to know more about the reasoning behind content blocking extensions coming to iOS 9 and OS X El Capitan. The general assumption is that Apple wants to enable users to activate ad blockers on the iPhone and iPad, but I wanted to hear Apple’s public stance and details on the implementation.
The WebKit blog answers my questions with an in-depth post on content blocking extensions. First off, Apple engineers were unhappy with the current state of content blockers:
It is an area were we want to do better. We are working on new tools to enable content blocking at a fraction of the cost.
As for Apple’s motivation, they never mention “ads” in the post, but the focus on disabling trackers and making webpages faster by removing external scripts is fairly clear:
We have been building these features with a focus on providing better control over privacy. We wanted to enable better privacy filters, and that is what has been driving the feature set that exists today.
There is a whole universe of features that can take advantage of the content blocker API, around privacy or better user experience. We would love to hear your feedback about what works well, what needs improvement, and what is missing.
Unsurprisingly, Apple built these new extensions differently than most content blockers for desktop browsers. Content blocking extensions won’t see the URLs of pages or resources being blocked:
A major benefit of the declarative content blocking extension model is that the extension does not see the URLs of pages and resources the user browsed to or had a page request.
WebKit itself does not keep track of what rules have been executed on which URLs; we do not track you by design.
User privacy is at the center of content blocking for both webpages and extensions. It’ll be interesting to see how many apps that just focus on blocking ads in Safari will be approved on the App Store (and how much they’ll leverage freemium models if so).