Inside the ‘arms race’ between YouTube and ad blockers / Against all odds, open source hackers keep outfoxing one of the wealthiest companies.::YouTube’s dramatic content gatekeeping decisions of late have a long history behind them, and there’s an equally long history of these defenses being bypassed.
A lot of people are saying this isn’t possible, theyre wrong. It’s called “Server Side Ad Insertion (SSAI)” and tldr it places the ads directly in the video itself. One of the popular streaming services uses SSAI, another uses SGAI. Theyre both something the CDN must implement alongside the client.
The technical explanation: SSAI, at least with HLS, places the ad segments within the media playlist. This means there is no additional and easy to block call to the ad server to ask for ads (that’s Server Guided Ad Insertion, SGAI). SGAI places markers where ads need to go in the media playlist, and the client asks the server for some ads to place there.
There’s also CSAI which is fully client side (the client decides where to place ads and how many) but I’d like to doubt youtube uses this. Doesn’t seem very smart.
Even if, lets say, youtube baked the ads into the content segments, it wouldn’t solve anything. There will still be markers and metadata to find where they are (the client needs these to notify ad partners you watched the ad, and to display the yellow “ad” markers, and to display a timer) which can be used to skip them client-side with an extension.
Overall YouTube probably won’t win because there’s always something to do to bypass ads. Some methods are easier to bypass than others, but they’re all enforced client-side in the end. The only thing they could possibly do to have even a fraction of a chance would be to block you from getting the next content segments until the ad duration has passed in real-time. That’s a last resort, however, because that will likely hurt QoS and client stability. There’s a reason it isn’t already done. Don’t forget, also, the developers who work on this stuff don’t like ads either. Nobody is going out of their way to prevent ad blocking beyond what the execs want, and the execs don’t know what they want.
Do note that although I specify HLS there is likely little to no difference with other streaming tech, I just want to be clear about my experience.
If ads are inserted at random time stamps and the client reports the watched intervals, then the server doesn’t need to communicate which intervals are ads.
That could still be bypassed by building a library of ads in the ad blocker, then examining the video feed when an ad is encountered, looking it up in the DB, and automatically jumping ahead as many seconds as its expected duration, but that would be a substantially heavier operation than what uBlock Origin currently does.
It also wouldn’t enable forcing users to watch the ads, since the client wouldn’t know to enforce an unskippable segment from 1:38 to 2:08. And that’s probably the real reason it won’t be implemented - an executive probably has “must preserve these features” as a constraint, so an engineer wouldn’t even propose this feature to them.