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.
YouTube’s end game is baked in ads. There are streaming services that already do this so it’s not impossible. It would not surprise me one iota if YouTube isn’t working on this now.
Once this happens, I suspect that the last round of people that have been holding out to subscribe to premium will either cave and do so or people will simply abandon YouTube.
Baked in ads run counter to googles entire ad philosophy though, to say nothing of the technical challenges that poses. Googles big selling point right now is targeted ads where the ads they serve you are based on your activities that they’ve tracked. With baked in ads every viewer of that stream gets the same ads, so while they could traget ads based on the contents of the stream, they would no longer be able to target the ads at specific viewers.
There’s also the problem that baked in ads are in many ways actually easier to skip. There are already extensions like sponsorblock that can skip specific segments of videos, and if it’s not served as a separate stream it will be more difficult to give special treatment to the ad portion of the video.
Baked in personalized ads aren’t impossible.
I can’t remember which streaming service it was (I want to say Tubi?) But they had baked in personalized ads. The technology isn’t far fetched and certainly possible with what youtube already has.
Sponsorblock only works on specific, known timed segments.
Say a video you want to watch has 8 places that YouTube can put up an ad (as determined by YouTube). Out of those 8 places, it decides to serve 5 ads. But the ads are of different lengths.
Sponsorblock can’t block those ads.
I’m not saying people won’t try but YouTube has all the information it needs to serve intrusive ads. And, I hate to say it, but they have the market dominance to pull the rug under premium subscribers feet because you know that in a year or two, they are going to start serving ads to those people too.
That’s not true though, sponsorblock is user reported, that’s why it works for sponsor segments and in-video ads of all lengths and locations in videos. If ads get baked into a video they can’t be taken out or changed, since that’s what getting “baked in” means in this context, and as soon as a single user reports the ad it will be blocked by sponsorblock for anyone who uses it. If it can be taken out or changed, then it’s not truly baked in and that can be exploited.
Ah I think we have a different definition of “baked in”.
What I mean is that the video does not change urls or sources when playing the ad and the video. So it looks like an unbroken video feed but on the back end, YouTube added the video between the designated time frames.
I get what you mean that if ads never change and are forever in the video file then sponsorblock will continue to work. But I don’t think this is what YouTube will do.
If they make it in any way removable no matter which end its on then other people will be able to figure out how to remove it too.
All they need to do is fuzz the time when the ad plays to defeat this.
The ads would be baked into the stream, not the source video. This is a fairly trivial problem, and I’m surprised they aren’t doing it already.
As soon as on user does it? Welcome, DoS attack!
This is completely wrong. You are serving video stream, you just substitute for the ad you would serve the user, at a randomized point in the video. YouTube doesn’t do this because they don’t want to reimplement the tracking and logging, but if it was financially necessary it wouldn’t be hard to do.
They would then also need to implement a new (and much less intuitive than 4m20s) way of referring to specific timestamps, since with ads at random points the timecode would be dynamically changing for each viewing.
I have some background in tech but admit I’m a long way out of touch now. I wouldn’t be at all surprised if they’re working on back end stuff to have personalised ads “baked in”. I know the resource implications of this are huge, but it still wouldn’t surprise me.
The resource implications are the problem. The cost - in terms of compute time - to bake those ads eats into the profit earned from advertising as a whole. Since only a fraction of users adblock, they would probably lose more money than they gained.
They’ll consider it once the compute cost inserting the ads is low enough that it’s worth it. I have no idea if we’ve reached that point yet, but I’m guessing not, since otherwise they’d already be doing it.
Most of the formats served by YouTube are already chunked, which means they can easily insert different chunks of video (ads, etc) at various points in the stream by changing the manifest. This is trivial, computationally. The complexity lies in building the mechanisms to make it work.
The non-chunked formats are only used by older devices, and are lower quality. Those would require re-encoding to change, but few users see them anyway, and those users probably don’t adblock.
Platforms can now insert ads directly into the manifest file into totally random timestamps. The file chunks’ names follow the same pattern as the original video. You cannot filter or prepare for it. Probably that will be the future. (AWS MediaConvert can do this for example.)
And they only create the manifest file upon starting the stream so you can inject personalized ads too.
I guess we will have to compare the last video frame and/or audio sample of every segment to the first frame and/or sample of the next segment or something like that?! Maybe the effects of “the loudness war” in ads will help us detect ads solely by the loudness change within the audiostream?
But don’t they do that on their tv app already, that’s why DNS blockers don’t work? I’m pretty sure they serve targeted ads on the tv app.
Wouldn’t SponsorBlock be a way around this?
Platforms can now insert ads directly into the manifest file into totally random timestamps. The file chunks’ names follow the same pattern as the original video. You cannot filter or prepare for it. Probably that will be the future. (AWS MediaConvert can do this for example.)
Meh, download the vid, then have software figure out where the ads are. It’s possible.
Hell, even just present a button for the user to hit when an ad segment starts.
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.
The only reason it hasn’t happened yet is because it is a fundamental change to the architecture of the platform, but will very much happen.