Network-level Ad Blocking

A new form of adblocking - at the cellular network level - has entered the news. Three, a UK mobile company (noteworthy aside, Three is owned by a billionaire that has invested in Shine) announced a partnership with Shine ( What's going on here?

First, let's take a quick stroll through the world of online security / encryption. In https, you take your standard http protocol and wrap it in SSL (secure socket layer). The idea of SSL is that device A and device B can communicate, and anyone in the middle can't see what A and B are saying to each other - even if they can see the actual data being sent between the two. Nonetheless, the requests still have to get to the destination, and the hostname (e.g., etc is still visible to anyone in between). The full path (e.g. is not visible, nor are the contents of messages sent in either direction.



So, Three is a cellular network. It's basically acting as a conveyance between the end user A and the ultimate destination on the web, B - back and forth. So, like the man in the middle between A and B above, for https communications, Three - and thus Shine - can see the hostnames, but not the data being sent. So, much like adblock plus, Shine can intercept web requests made by A, and block them. So if you send a request to doubleclick, Shine will know it's an ad and block it (even if it's not an ad). It will do this at the request level. Unlike adblock, Shine does not live in the browser, so it can't remove elements from the page after it's loaded - it can only block entire requests.

This means that Shine wouldn't have any impact on Buzzfeed, where the ad is embedded in the HTML of the page. It's possible that Buzzfeed transmits everything in http, not https - and it's possible that Shine assembles the data in their system and then removes it from the assembled HTML. But that's very, very unlikely. This means that for every system that uses HTTPS, and which serves ads from its primary domain, or includes it in the HTML of the page - Shine won't do anything. Google search, Facebook, Buzzfeed, etc. won't be impacted by Shine based on the above.

The idea is that Shine would block ad tech providers, and presumably - at some point - charge a vig like adblock plus. This makes sense at some level, because cell phone bills increasingly have limited amounts of data and consumers are likely annoyed to spend that money on ads (especially video ads). But Shine will have the issue that AdBlock doesn't - that publishers can easily identify users on providers that block their ads, and easily create paywalls for those users. Because Shine isn't client side, there would be no workaround.

As an aside, it's an interesting question about whether Shine is even legal at all in the US - because it violates net neutrality - though not if it's opt-in by the consumer, maybe? The UK and the Caribbean (where Shine's other customer, Digicel, is based), probably do not have the same laws.

Question: if Three/Shine won't have an impact on advertisers whose ads are embedded in the HTML of the page, is it safe to assume this wouldn't have an impact on TripleLift's ads? Or, since Three/Shine blocks at the adserver call would we be blocked as well....and to be clear, this is why we are susceptible to current ad blocking?

Answer: Shine will block TripleLift's ads at the adserver call, meaning when the user's browser makes a request to (our adserver domain), Shine will block it from hitting our server. The question of embedding into the HTML is a little complicated. When you make a request to a website (let's say, the server returns a chunk of HTML. CNN could put whatever it wants into that HTML - and generally it's the "markup" of the page, meaning some HTML and instructions to the browser to make subsequent calls for stylesheets, javascript and ads. This is the stuff that Shine cannot likely edit - meaning it came directly from the server. Our ads are injected into the HTML rendered by the browser, but aren't actually transmitted by the original server. So they'd be blocked at the adserver request. There's actually a bit of a nuance here, in that HTML is text - the text transmitted by the original server. What we're injecting our ads into is the DOM (document object model) - which is the browser's store of the current state of the web page. It's sorta the same thing as HTML, but it's not _actually_ HTML, since it's a representation of the elements conveyed by the HTML text, and any modifications made to the text over the lifetime that that page is open.