←back to thread

YouTube's new anti-adblock measures

(iter.ca)
990 points smitop | 9 comments | 20 Jun 25 17:01 UTC | HN request time: 1.453s | source | bottom
Show context
ranger_danger ◴[20 Jun 25 17:57 UTC] No.44330199[source]▶
I'm surprised they don't just inject the ads directly into the video stream, I think that would solve their issue overnight (not that I want any ads personally). You could also rate-limit it to the playback speed to prevent pre-downloading the stream easily. But now that everything uses HLS/DASH, it's easy to inject different content right in the middle of the stream without re-encoding anything.
replies(15): >>44330295 #>>44330306 #>>44330327 #>>44330366 #>>44332987 #>>44333096 #>>44333102 #>>44333133 #>>44333320 #>>44333605 #>>44333700 #>>44333858 #>>44334367 #>>44335037 #>>44335453 #
layer8 ◴[21 Jun 25 07:27 UTC] No.44335453[source]▶
Injecting the ads directly would make them skippable. Unskippable ads are inherently detectable (because the unskippability has to be communicated to the client-side player controls), so there’s no easy way out.
replies(2): >>44335611 #>>44336114 #
1. jay_kyburz ◴[21 Jun 25 09:44 UTC] No.44336114[source]▶
The server can just ignore the player and send the bytes for the ad until its finished.
replies(2): >>44336859 #>>44337000 #
2. ◴[21 Jun 25 11:58 UTC] No.44336859[source]▶
3. layer8 ◴[21 Jun 25 12:18 UTC] No.44337000[source]▶
The server can't completely ignore the player, as it would have to adjust the embedded timestamps to be consistent with the skip operations, or otherwise the player won't show the video. In other words, the server would have to act as if the ad is embedded wherever you skip to in the video. Not only would it mean that users lose their position in the video when they try to skip, since after the ad it would continue in a different place, but it would also mean that timestamps don't uniquely identify positions in the non-ad parts of the video anymore, which is a nonstarter in many ways.
replies(1): >>44339484 #
4. ranger_danger ◴[21 Jun 25 18:08 UTC] No.44339484[source]▶
JS on the client (which is already required) can be instructed by the server to manipulate the timeline. You could zero it out completely (or stop it from moving at all) while an ad is playing and then return it to the right spot after, this is not rocket science.
replies(1): >>44339516 #
5. layer8 ◴[21 Jun 25 18:12 UTC] No.44339516{3}[source]▶
For JS on the client side to be able to behave in the way you describe, it has to be informed by the server about the unskippable parts. Thus browser extensions are informed as well, and can take action correspondingly. In the worst case, they’ll behave as YouTube’s new hold screen does now.

Anything that JS on the client can do is also under control of browser extensions. We are talking about YouTube’s options under that constraint.

replies(1): >>44340178 #
6. ranger_danger ◴[21 Jun 25 19:40 UTC] No.44340178{4}[source]▶
I don't think there's any reason the JS would have to know ahead of time, and the server still controls what video fragments are served when, so I don't think JS can be reliably used to skip ads that are embedded in the video stream, especially if the download speed is limited to somewhere close to the playback speed.
replies(1): >>44340372 #
7. layer8 ◴[21 Jun 25 20:05 UTC] No.44340372{5}[source]▶
When the player performs a skip, it waits for stream packages whose timestamps match the new position after the skip. It’s the client who requests a different segment of the video, and waits until it receives the respective segment, as identified by the embedded timestamps. Skipping isn’t a purely server-side operation in that sense, the client side has to cooperate. The server has no control over which timestamps the client wants to play.

The only other alternative is to make the video a live stream of indefinite length where the user can’t skip forward beyond the farthest point they already played.

replies(2): >>44341484 #>>44342217 #
8. ranger_danger ◴[21 Jun 25 23:26 UTC] No.44341484{6}[source]▶
I'm not sure what point you're trying to make, or how it invalidates anything I said already. Not trying to be rude, I just don't understand where you're going with this.
9. jay_kyburz ◴[22 Jun 25 01:16 UTC] No.44342217{6}[source]▶
The server can always just say no, here are the bytes for you, and this is the timestamp, deal with it.