[Thoughts] Apple Content Blocker in iOS/Safari 9

Privacy is hitting the mainstream, the cows are smelling hamburgers and asking questions (Update: I’ve tested some benchmarks on ad-blocking in various configurations here). Apple is finally rolling out an ad-blocking feature in Safari 9, with the following official description:

“The new Safari release brings Content Blocking Safari Extensions to iOS. Content Blocking gives your extensions a fast and efficient way to block cookies, images, resources, pop-ups, and other content. Your app extension is responsible for supplying a JSON file to Safari. The JSON consists of an array of rules (triggers and actions) for blocking specified content. Safari converts the JSON to bytecode, which it applies efficiently to all resource loads without leaking information about the user’s browsing back to the app extension.”

Makes perfect sense – sites deprived of their ad revenue look elsewhere, like pushing native apps onto users, where tracking and ads can’t be blocked, or use Apple iAds platform. Either way, Apple gets their cut, whilst looking like the good guys for prioritizing the user experience. Or alternatively, the number of native advertisements increases exponentially, leveraging the inability of many people to tell if what they’re reading a review or an ad.

There are already a few ad-blockers being worked on to use the new capabilities for iOS, including Crystal, 1Blocker, and Purify (Update: The maker of the Peace ad-blocker has removed it from the market, citing conscience. The others are topping the charts, indicating huge pent-up demand for a usable mobile web).  Some initial testing of the iOS ad-blocker looks promising. Needless to say, this is a good thing, especially for smaller mobile screens. I found ad-blocking to reduce page load times by around 3-4x at minimum on common news sites. With Javascript blocked, that number increases to around 10x faster, even on a mobile device. You can try it yourself, hit F12 and bring up the network view, then see the number, bandwidth and time that 3rd-party JS takes. I would never consider using any computer or device without some kind of hosts or browser blocking, it’s a consequence of the unfortunate state of the web today.


Some relevant bits on how Safari content blocker works (source):

blockerList.json contains the list of things to block, written in JavaScript Object Notation (JSON)

ActionRequestHandler.swift contains a tiny amount of Swift required to bootstrap your extension. If you know Swift you can add features here, but you’ll need to use Swift 2. If you missed it, you can read my introduction to Swift 2 tutorial first.

Info.plist contains the settings for the app extension.

“…it ran your extension, fetched out the blockerList.json file, and compiled it into an optimized form representing all your rules. That optimized form is what’s given to Safari, which is why this new model is so much faster – extensions don’t link into Safari at all, they just provide rules once, up front, then let Safari do the rest.”

Helpfully, one of the WebKit engineers confirmed to me that they expect to allow 50,000(!) rules per extension.

A list of content types that can be blocked (1st and 3rd party, with regex URL matching), (in-depth source):

  • “document”
  • “image”
  • “style-sheet”
  • “script”
  • “font”
  • “raw” (any untyped load, like XMLHttpRequest)
  • “svg-document”
  • “media”
  • “popup”

This is very comprehensive, on par with uBlock Origin on other platforms (to date the most comprehensive and customizable ad-blocker) and if the ad-blocker itself is created properly, then I am certain 50,000 rules would be sufficient for most people. The implemention then boils down to whitelist/blacklist capabilities and the source of the rules (ie. hosts sources). My current hosts file is around 150,000 domains long and it’s reasonably comprehensive. I’ve seen hosts file go up to 50MB (4.5 million+ hosts) before, but that’s a niche case. You can read Adblock Plus’s response here, basically their filter lists are not compatible.

Note that content blocking applies ONLY to the Safari view controller. There is also significant difference between ad-blocking (of mostly cosmetic benefit to the user), with user tracking. Often both are rolled into websites, but tracking can exist without any visible ads being seen at all, it’s loaded in the background silently. Similarly, tracking is nearly always built into downloaded apps, for a variety of reasons. Developers can track your usage habits, and in some cases feed back your email address, unique ID, rough location (based on wifi networks) and other details for unknown uses. For now, let’s ignore that.

The good news is that the Safari view controller (which supports the content blocker extension), is able to be implemented in third-party apps, replacing their own in-app browsers. If this is the case, and the app decides to do so, then ad-blocking will be available in those apps, as per the extension rules. Combined with deep-linking, this could be a very good thing. I am fairly certain than WKWebview will not receive content blocking capabilities, this includes Google Chrome, which uses WKWebview.

However, in typical Apple fashion, it’s not available on the iPad 4 backwards, nor the iPhone 5 backwards, citing performance reasons. However, we know this is bunk – ad-blocking itself barely increases the CPU load, as it has less content to load and render, including bloated 3rd-party Javascript. Javascript itself, in my own testing and from what I’ve seen, accounts for the vast majority of CPU load and rendering time, not to mention it can introduce a whole host of security and privacy issues. Where it might differ is an increase in RAM usage as the content blocking rules have to be loaded into memory – but iPad 4 has the same amount of RAM (1GB) as the iPad Air, which can run the content blocker. Same with the iPhone 5, which also has 1GB like the iPhone 5S. The real reason is simple – Enforced upgrade cycle, you shall obey. Apple’s money stash is waiting for you.

Tangentially, it’s worth mentioning that mobile Chrome, on every platform, doesn’t support Extensions at all. I suspect this is not for a technical reason (mobile Firefox has supported it’s more complex XUL addons for a while), but that Google knows the number one extension installed will be an ad-blocker. People hate floating ads, massive banners, interstitials and all other manner of space-hogging, bandwidth-slurping ads. Bottom line – if you’re using Android, either apply a hosts file, or use Firefox + uBlock Origin. The reason I would never recommend using Adblock Plus is that the method it uses to block ads (injecting frames everywhere), is extremely memory and CPU intensive. In addition, they take money for allowing ads through. Use uBlock Origin instead.

If you’re interested to see what mobile ad-blocking can do, uBlock Origin has been available for mobile Firefox for a while, and it allows extremely fine and granular controls including a wide range of ad-blocking sources. Ad-blocking has also been available for all desktop browsers for a while. Make sure you use uBlock Origin, it has the most features, the least bloat, and the developer Raymond Hill has virtuously refuses to take donations. He made the non-Origin uBlock originally, handed it off to a volunteer, Chris, who then promptly tried to monetize every part of it. Raymond then resumed development under the uBlock Origin moniker, with the non-Origin uBlock stagnating.


A browser-based content blocker will do nothing to stop tracking in every other part of the OS. There’s only really one way tried-and-tested way of stopping that, and that’s a hosts file. All connections going to a known blacklist (often of hundreds of thousands or millions) of known advertising or third-party tracking servers are sent into a black hole. The blocking is done universally, regardless of any settings in the OS or in any app. It takes no additional CPU cycles and requires no installation of addons. However, on all systems, you will require root/administrator/jailbreak access to apply a hosts file.

What I expect to happen in the immediate future is because the least-technically inclined users with the most spendy habits now have access to ad-blocking, sites will resort to using more nefarious means. Things like same-domain ad hosting, or randomized CSS naming could be implemented. More paywalls, more subscription nagging, more urgency in ‘Install Our App!’ messages.

For tracking, techniques like canvas fingerprinting, supercookies, ETags / DOM storage, or plain old browser fingerprinting have already been in use for a while, rendering VPNs/proxies ineffective for privacy. These techniques are incredibly difficult to stop, even on desktop browsers, but you can get close. That information can then be cross-matched against where users are seeing ads – whether it’s tailored native advertisements, or Apple ‘approved’ ads in iAds/News, or installed apps. One thing that you won’t see if wholesale moving to a subscription model, people love free things too much. Prepare for wave two of the ad wars, the one that happens in the background.



2 thoughts on “[Thoughts] Apple Content Blocker in iOS/Safari 9

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s