Hacker News Reader

Comment by hnarn | Hacker News Reader

This is a badly written and hyperbolic article. What does "server side injection" actually mean? The article also touches on SponsorBlock, which in my mind would have no problems skipping whatever "injected" ads show up since this is already what that application does, but it doesn't address this at all, it just mentions that the team behind it "mentioned" that youtube is "experimenting".

At the end of the day ruining adblock is impossible, the only question is whether all engineering hours and extra infrastructure/complexity put into making it more difficult will actually render a net benefit in the end. I'm skeptical.

View on HN

> What does "server side injection" actually mean?

The way ads usually work is that they are separate video files that are fetched by the YouTube client (e.g., the browser) and then displayed to the user. Ad blockers modify the content of the web site such that the URLs to those ads (usually embedded in some JSON object from an API endpoint or something like that) get removed so that no ads are displayed.

Server side injection in this context means that the server renders a video file on demand that contains the original clean video plus a few ads here or there. Blocking the ads now is much harder because you cannot simply manipulate API responses containing refrences to those ads because there is only this one video file. Instead you would need to implement a mechanism that skips those ads in the player.

AFAIK server sie injection is already done on twitch for live streams where blocking ads is really basically impossible because you cannot skip anything in a live stream. I think the best solution for twitch to get rid of ads is to use a VPN/Proxy in a country where no ads are delivered for contractual reasons.

Even if they decide to take an aggressive approach of injecting ads into the video stream at unknown positions, there are still going to be ways around it.

For one thing, this approach seems to inherently conflict with the fact that you can link directly to a particular timestamp in a YouTube video, either in an external link using the `&t=...` URL parameter, or by just including a timestamp in a YouTube comment.

So unless YouTube is willing to break all those links or drop timestamp linking entirely, then it seems to me that they'll have to give clients a way to convert "original" video timestamps into corresponding offsets into the delivered video stream. And if you have that, you have enough information to locate the ad segments, at least to the nearest second.

Or, another option: Presumably the server is just muxing together pre-encoded video segments corresponding to either the original video or the ads. So one could create a database of segment hashes, look for identical segments that appear in multiple videos, and add them to a crowdsourced database of known ad content.

It might be difficult to use these strategies to block ads interactively in a browser, by patching the behavior of YouTube's player, but they ought to still be usable in non-interactive tools like yt-dlp.

> For one thing, this approach seems to inherently conflict with the fact that you can link directly to a particular timestamp in a YouTube video, either in an external link using the `&t=...` URL parameter, or by just including a timestamp in a YouTube comment.

The more I think about this, the more I belive that this is literally the only reason that ad blocking cannot be meaningfully defeated for video on emand. Because of the concept of referencing a fixed point in the video by a time stamp, there will always need to be a mechanism to offset the time stamp with respect to the injected ads, which, in turn, gives ad blockers the ability to find out where the ads are exactly.

> At the end of the day ruining adblock is impossible

They just need to not send the part of the stream past the ads until it’s the right time to do so. You may not watch the ads, but you’ll still wait for them to finish.

Yes, like Hulu (not sure if they still do).

I think doing this would be a positive thing for some consumers. It’s a good blank space to reflect on whether our time spent watching the video is actually worth it.

I’ve done my best to move away from real-time YT viewing and instead download set channels into Plex for on-demand viewing. This somewhat helps binging, as it is not infinite and does not suggest the next video via algorithm. This method wouldn’t affect my viewing to any meaningful degree.

> which in my mind would have no problems skipping whatever "injected" ads show up since this is already what that application does

SponsorBlock contributors tag certain parts of the video where the video creators talk about sponsored products, or self-advertise. These timestamps are fixed, as the video creator uploads a single video for distribution.

If YouTube dynamically injects additional ads on a user-by-user or region-by-region basis, not only will these ads all have different lengths and timestamps, making SponsorBlock ineffective, but will also render existing tagged segments obsolete, as they are now offset by the length of any preceeding injected ads.

> will also render existing tagged segments obsolete, as they are now offset by the length of any preceeding injected ads.

By the same mechanic, it would also invalidate all the timestamps that people put in video descriptions and comments. Are you sure YouTube would do that?

As the article hints, youtube does know how long and at what positions the injected ads are. So they could use this information to skip to user-supplied timestamps correctly. The question then becomes, whether Adblockers could use this information to skip the ads.

It's a cat and mouse game.

> The question then becomes, whether Adblockers could use this information to skip the ads. It's a cat and mouse game.

I wouldn't call it a cat and mouse game because there is nothing from a technical point of view that prevents adblockers to use this information to skip ads. Unless YouTube gets completely rid of the concept of timestamps for their videos, they will always lose this battle.

They could make the timestamp conversion very Server-Side or create a very unwieldy API where it's difficult to collect all ad segments via timestamp sampling.

> they could use this information to skip to user-supplied timestamps correctly

If that information is available, it can be gathered by adblockers to guesstimate how the video has been offset, and then you're back to square one.

If "clean" videos are still available (which they likely will be via youtube premium), you still have a reference of how the video should look, so you can start tagging suspicious sections as soon as they are categorically avoided by the youtube "timestamp fixer".

Sure, it will become harder as the frequency of mangled videos increase, worst case every single user will get their unique rendered video, but I think the performance hit on youtube would be immense, because AFAIK you cannot simply cut together separate video streams, even if they are aligned in encoding, resolution and everything beforehand, because it will break keyframes and create artifacts unless transcoded.

If the frequency is relatively low (say, one video per nation or US state) then adblock efforts can just adapt, the existing sponsorblock implementation could probably still work with some modifications.

The article includes a quote from the creator of Sponsorblock saying "This breaks sponsorblock since now all timestamps are offset by the ad times".

Yeah, TouTube would have to rotate the insertion time on the fly, but again as the article mentions it needs to be user context aware before building it into the stream. Possible? Sure, but the cost and potential architecture change could be too much.

I have premium because I use YouTube quite a lot, but for non premium users YouTube pushed the ads too far. Unskippable, some reports of 70 min + adds, multiple ad segments in a < 10 min video.

Ad to that the content creators adds, I think it’s understandable more and more people are frustrated.

Reply on news.ycombinator.com