– Baldur Bjarnason
Over the past couple of days I sat down and did what most tech columnists seem unwilling to do:
I actually looked into what an announced API is capable of.
Namely, the upcoming iOS 9 Safari content blocking extensions.
What follows is a very rough rewrite of a couple of tweetstorms.
ETA: I extended the conclusion to explain things more clearly.
iOS 9 content blocking extensions have the potential to improve web performance on a massive scale.
Browser vendors like Firefox and Apple have a very compelling reason for blocking tracking scripts: they are some of the most misbehaving scripts on the web, a Mozilla study revealed that blocking these scripts results in an on average decrease in loading time of about 44%.
Excessive and badly designed tracking scripts are one half of the problem that is plaguing the web (the other half being a web development culture that isn’t interested in performance and accessibility).
That people’s efforts to monitor an ecosystem damages it is par for the course for modern life.
After watching the WWDC session on content blocking extensions it does indeed look like like they are mostly optimised for things like Disconnect or Ghostery, specifically targeting tracking scripts, in a way that’s similar to Firefox’s built in tracking protection.
As anybody who regularly uses these privacy services can attest to (I’m one), they actually don’t do much in terms of ad-blocking, concentrating instead on tracking scripts and only a subset of ads. If the ad network falls back to generic display ads, those aren’t usually blocked. If the ads come from the same server as the content, such as search result ads or ads on social media networks, those aren’t usually blocked either.
The new content blocking APIs do not seem to be designed for ad blocking and the Adblock Plus people seem to agree.
The best case is that the new API will help us to improve the performance and adblocking experience on Safari, and paves the way for an iOS adblocker. If their block list format turns out to be useless, however, that could mean the end of adblocking on Safari, as the old mechanism relying on the
onbeforeloadDOM event andsafari.self.tab.canLoadwill get deprecated now.Content blocking in Safari 9 and iOS 9: good news? Or the death knell of adblocking on Safari? by Sebastian Noack (935 words).
My first impression of the API is that the content blocking mechanism is more a pro performance/privacy feature than an anti-ads feature, which lends credence to the concerns of the Adblock Plus people.
The reason iOS9 content blocking seems more for performance is that ad-blocking extensions using it would probably let quite a few ads through. What they would do is net a consistent improvement in load performance by blocking tracking and ad scripts that are known to behave badly.
An ad provider wanting to bypass these blockers should be able to do so with relative ease.
After I wrote the above, the Webkit folks went and outlined the API in more detail, including the motivation behind it:
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.
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.
Everything has been developed in the open; everyone is welcome to audit and improve the code. The main part of content blockers lives in Source/WebCore/contentextensions.
Introduction to WebKit Content Blockers by Benjamin Poulain (2601 words).
The bit that I highlighted supports my impression of the API.
Unfortunately, I followed that up by reading and listening to columnists and journalists speculating on the implications of that new feature. Even more unfortunately, I had also spent some time going over the API and thinking about what it can and cannot do.
Most of the journalists speculating clearly hadn’t looked into what the API could do.
My biggest disappointment was with the hosts of the Exponential podcast who are otherwise consistently excellent. I can only hope that Ben Thompson had looked into the issue in greater detail before he wrote his update for private members of the Stratechery website.
(This led to my second tweetstorm on this which I’ve rewritten into the following passage.)
People are overestimating the ad blocking capabilities of the new iOS9 content blocking extensions.
The content blocking API relies on a static JSON configuration file. This file only seems to updated when the user runs the app or when the app itself is updated. The extensions aren’t allowed to extend or add to the Safari UI itself. This means that the only time that the extension can run any sort of logic is when the app providing the extension is opened which in almost all cases is going to be relatively infrequently. To reliably block ads you need a much greater dynamism—per request logic is needed to keep up with ad networks.
A static lists won’t cut it. A infrequently updated static list is even less likely to cut it. This won’t even come to an arms race between blockers and ads. It’ll be over before it starts.
Providers who are intent on bypassing content blockers built using iOS 9’s new APIs should be able to do so with relative ease.
The scripts that will get blocked are the ones that reliably come from a single known location, like most tracking scripts.
Static lists are good for blocking known bad actors and excessive trackers. They aren’t particularly good at ad-blocking.
I use the Disconnect.me browser extension, which is structured much like iOS 9 content blockers will be structured (i.e. it uses a static JSON list), and it only blocks ads about half the time.
Which is fine. I don’t use it to block ads. It’s there to block tracking scripts.
The ads I get are obviously generic and not targeted in any real way but, in a testament to how horrible most media companies are at actual ad targeting, the generic ads tend to be more relevant to me and the content I’m viewing than the targeted ads I supposedly get when I’m using the iOS 8 browser which has no tracking protection.
But that isn’t the only issue preventing content blocking apps from causing a global mobile advertising armageddon. Extension not only need to be installed but they also need to have enabled separately via a pretty hard to discover UI. (This is an issue with iOS extensions in general.)
Not only does the user have to download the app but for content blocking extensions they also have to navigate to an obscure part of the Settings app and enable the extension.
A minority of mobile users will install a content blocker and in all probability only a minority of those will actually enable it.
This isn’t the end of mobile web advertising.
Although that’s partly because the mobile web advertising economy is stillborn—apps not websites, e.g. Facebook and Youtube, dominate. Media companies won’t be able to blame content blockers for their pre-existing inability to grow mobile advertising revenue.
It’s easy to assume that the addition of content blocking to the iOS platform is some sort of strategic move against companies like Google.
I think that’s reading too much into it. Misbehaving tracking scripts are such a big performance problem for mobile browsers that adding blocking features is a simple matter of self-preservation for most browser vendors.
Browser vendors who don’t rely on advertising as a source of revenue, that is.
Could it be a part of a larger overall anti-Google strategy? Sure. But in and of itself it isn’t proof of the existence of such a strategy.
A conversation with Jordi Bruin reminded me that I didn’t explain why tracking services operate under a dynamic that’s different from ad services.
Simple:
-
If ad blockers become popular and effective, websites go bankrupt.
-
If tracking blockers become popular and effective, many websites won’t even notice.
A site that is ad-supported has a strong economic incentive to be obsessed about making sure the ads work. They will be following the adoption of content blocking apps closely and they will look into ways to bypass them if they think it’s necessary.
And as I outlined above, bypassing them won’t be that hard.
Most tracking services, on the other hand, aren’t of the kind that provides a web site owner with vital, strategic data, but are instead a negative externality—the price society pays for the prevalence of free services.
Every social media button you embed comes with tracking code. Every free third party service you use on your website comes with tracking code.
Analytics code is almost universal. If your site isn’t ad supported, having your analytics blocked doesn’t threaten your business in any substantial way.
Website owners have even less of an incentive to help free third party services get their button and widget analytics past blockers. Raising a fuss is, if anything, more likely to cause publications to remove these widgets. After all, the point of having these services and widgets on your website is to increase engagement, not piss your readers off.
Many websites won’t even notice if most of their readers install privacy blockers but their readers will sure as hell notice websites loading almost twice as fast.
Which is why the most likely result of a widespread adoption of iOS 9 content blockers is the following:
- Ad networks pre-emptively update their code to bypass these blockers.
- Website owners get their strategically important analytics code past the blockers by proxying them through their own domains.
- Tracking scripts belonging to free third party services get blocked almost universally. Nobody actually embedding these services has much of an incentive to get them past the blockers.
- These widgets will then either be re-architected so as to not track the user or simply removed by website owners.
The web is improved.
That’s assuming these blocking apps become popular, which isn’t that likely. Fewer people care about ads and privacy than many of us would like.