Recently Apple announced that, for the first time ever, ad-blocking plugins will be allowed in mobile Safari in iOS 9. There has been a large outpouring of commentary about this, and there seems to be pretty broad agreement on two things: (1) this action on Apple’s part was aimed at Google and (2) for publishers this will be something between terrible and catastrophic.
I believe that people are making these assessments based on a lack of understanding of the technical details of what is in fact going on.
For the most part, the public does not appreciate the extent to which, when a web browser visits a typical site, the “page” being served comes from multiple parties. Go to a typical e-commerce site, and you will find pixels, trackers, and content from additional servers, from a few to dozens. These produce analytics for the site owner, run A/B tests, place ads, and many other things. There is even a service that knows what size clothing to sell. It is these services that are the target of ad blockers.
It is this architecture however that renders the ad vulnerable to the blocker. In fact, ad blockers have existed for desktop browsers for a long time.
So there is nothing really new under the sun, just the growing popularity of the tracker/ad blocking software. If the use of these plugins becomes ubiquitous, only one thing would have to change – the publishers would have to insert the line of code in some way on the server side, and the ad would just look as though it came with the rest of the page. At that point, the browser plugin is useless.
What would be the knock-on effects of this? The ad companies no longer have any way to track users as they move around the web. Absent some way on the ad companies’ part to implement a cross-site evercookie (which would be considered unethical and would quickly be blocked by browser authors if discovered), the ad companies will no longer have a way to connect users on one site to users on another. The ads you’d see on a given site could be based solely on the interactions you’ve had with that one site – which would be a boon to privacy.
This is a change, for certain, but probably not the apocalypse for publishing it has been made out to be. There will be a rush to develop ad-placement technology for the server side as there was on the client, but when all settles down it will be pretty easy for the publishers to implement.
It’s even arguable that in that world of anonymous web surfing, the better web properties would be able to charge higher rates – absent spying on the readers, decisions about the value of ad placements would be based on the demographics of the readers of the site – just as for offline properties.
That being said, if you ever reveal your identity to a web site (for example by entering your e-mail address) that site could set a cookie so as to remember who you are. From that point on, information could quietly be sent to the ad server, perhaps storing all the URLs you visit on that site.
So, in the end, this change actually may be a boon for Google. If it’s really true that tracking users is so valuable for ad placement, Google has an advantage the other ad companies do not: many millions of users using Gmail and the Chrome browser, both of which Google controls. If you use Google’s e-mail, Google knows what links you are getting sent from advertisers. If you click a link in a Gmail message going to a web site with Google serving ads on the back end, you can arrive at the site with Google already knowing who you are. (This can be done unobtrusively using the http referrer header.)
Even if you don’t use Gmail, you may sign in to Chrome to sync your data across devices. This uploads information to Google’s servers so it can be sent to other devices, such as your Android phone. One of the things that can be synced is the browser history. If this is done, Google – and no one else – will have the same information they would have collected with browser cookies.
If Apple is looking to damage Google, their plan may backfire. No one else, not even Facebook, has a chance of matching this.