this post was submitted on 02 Dec 2023
783 points (97.9% liked)
Technology
59402 readers
3761 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.