Reactions to Collateral Damage

Last night, I wrote up a quick post on the importance of iOS9’s introduction of a content-filtering API.

Naturally, there have been a variety of reactions to this post, so I’d like to address some of those and provide some additional context.


First, I’d like to point out that while there are many important factors in the evolution of technology, ignore economics at your peril. My first-hand experience with this was watching the “race to the bottom” in the Certificate Authority market; anyone with even a passing examination of the economics behind CAs could have seen it coming many years before it actually happened.

Second, I’ll point out that I wrote a much longer and more popular blog post on ad-blocking almost five years ago. Beyond showing how to block many web ads, I also provided some examples of what happens when ad-blocking becomes prevalent enough for sites to respond; generally, it’s not pretty. Go give it a quick skim, especially starting at the section Evaluation of Blocking Mechanisms. If you didn’t read between the lines, the tl;dr subtext of the post is “Hey, all of y’all evangelizing mass adoption of ad-blockers—knock it off, or you’re going to ruin it for us.

Third, I maintain a Tracking Protection List for IE9 to IE11 that blocks many web advertisements.


@mattapperson noted that iOS isn’t shipping with an ad-blocker, only a filtering API, and that’s true.  As I noted, however, there are significant short- and long-term strategic benefits for Apple if their new API is broadly used to block web ads. Mike and @steve228uk think the new API won’t be a game-changer and only power-users will block ads. That’s a possibility for sure, but again, it’s absolutely in Apple’s interest to ensure the API is broadly used.

@reganwald implies that ad-blocking won’t damage the open web, only its monetization. This is that pesky “ignore the economics” fallacy; the web grew not only because it was super neat, but also because there was plenty of money available. Shut off the money spigot and the attention and investment will move elsewhere.

@thomask77 observes that ads will simply get integrated into the first-party HTML and obfuscated; you could imagine technology like ShapeSecurity getting used for this. That’s certainly a possibility, but it overlooks some technical complexity and other problems (e.g. harder for ad networks to root out fraudulent clicks, which are already a huge problem). But yes, one outcome of widespread adoption of ad blockers will be a further blurring of “content” and “ads”, in the same way that American Idol judges guzzle Coke out of big cups and the singers croon at Fords parked on stage.

Several commenters, including @theodorejb opined that sites just need “to move beyond ads to other forms of revenue.” It’s a fine idea, but the genius of Apple’s position here is that the easiest move is for the publisher to build an iOS app and leave their existing ad investments intact.

On April Fools day in 2011, I proposed a new specification, P5P, the Pretty Please Platform for Participating Publishers. While this was mostly a tongue-in-cheek takedown of the Do Not Track request header, I also took some shots like this one:


This token indicates that the user does not wish to be shown any form of advertising content, and expresses their earnest belief that the web publisher will find some way to remain in business without an income stream.

Note: This preference appears to be far more common than the related NO-ADS-HERE-IS-MY-BILLING-INFO-INSTEAD value.

@joshin4colours points out that some sites may be overlooking obvious revenue opportunities; I’m sure this is true in some cases, but again, the inertia is going to be for the blockee to simply kick the user over to their unconstrained iOS app.

One alternative revenue model is “tipping.” For instance, detects blocked ads and allows users to send support via Bitcoin or Litecoin:


I support Virtual Globetrotting by using the Amazon Affiliates link to shop (and I buy quite a bit on Amazon), but I suspect that ad-blocking is still revenue negative for the developer.

@MaxenceBouret observes that widespread use of Safari’s content blocker could backfire and lead to users being asked to switch out of Safari to Chrome instead of using an iOS app. It’s a possibility, but I think it’s not the likely outcome.

@jdev1977 and others point out that sites can simply block visitors who block ads; that’s true, and it’ll likely be early return fire in an escalating arms race.

Related Reading

Here are a few articles in this area:

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, working on Office, IE, Edge, and Web Protection. My words are my own, I do not speak for any other entity.

4 thoughts on “Reactions to Collateral Damage

    1. Yes, this is interesting, but one key caveat: “Each of the network extension points requires special permission from Apple.”

      1. And why would Apple disallow AdBlock for such an API? “It is fine when it does not hurt us (web), but not when it does (native)”? Oh, the hypocrisy…

Leave a Reply

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

You are commenting using your 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

%d bloggers like this: