YouTube has found a new way to bypass ad blockers by integrating ads directly into video content via "server-side ad insertion," complicating the detection and blocking of ads. How will ad blockers respond?
Why would that be the case? The player can simply be locked into ad mode till it gets the cue from the server all of the ads have been streamed. Only then will the player unlock. When watching what amounts to a video stream, this doesn’t have to be handled clientside.
and making them server site, while possible would introduce tremendous amounts of lag, and put that much more load on the servers. Imagine a server that has to handle playback of billions of users all at once. That’s probably quite a bit worse than most average, or even high-level DDoS attacks.
I’m not talking about the player or the controls being server-side. I’m talking about the player being locked into a streaming mode where it does nothing but stream the ads. After the ads are streamed, the player returns to normal video mode and the server sends the actual video data.
This means no metadata about the ads are required on the player side about the ads.
Sure you can hack the player into not being locked during the streaming of the ads. But that won’t get you very far, since it’s a live stream. You can’t skip forward, because the data isn’t sent yet. You can skip backwards if you’d like, with what’s in the current buffer, but why would you want to? You can have the player not display the ads, but that means staring at a blank screen till the ads are over. And that’s always the case, one can simply walk away during the ads.
Technically I can think of several ways to implement this, without the client having meta data about the ads. And with little to none ways of getting around the ads. Once the video starts it’s business as usual, so it doesn’t impact regular viewing.
Still user watches video. Ad avoidance skips forward to buffer barrier to play ad in the background. Streamed ad is thrown away and new buffer data is received. User does not notice if the video is long enough.
A user opens a session to watch a video, the user is assigned a token to watch the requested video. When the user isn’t a premium subscriber and the video is monetized the token is used to enforce ads. To get video data from the server, the user needs to supply the token. That token contains a “credit” with how many seconds (or whatever they use internally) the user can watch for that video.
In order to get seconds credited to the token, the user needs to stream ad content to their player. New ad content is only available to stream, once the number of seconds they were credited have been elapsed.
One way to get around this is to have something in the background “watch” the video for you, invisible, including the ads. Then records the video data, so it’s available for you to watch without ads. But it would be easy to rate limit the number of tokens a user can have. There’s ways to get around that as well. But this seems to me well beyond what a simple browser plugin can do, this would require a dedicated client.
The idea is to make it harder for users to get around the ads, so they’ll watch them instead of looking for a way to block ads. In the end there isn’t anything to be done, users can get around the ads. Big streaming services use DRM and everything and their content gets ripped and shared. With YouTube it would be easy for someone to have a Premium account, rip the vids and share them. But by putting up a barrier, people watch the ads. YouTube doesn’t care if a percentage of users doesn’t watch the ads, as long as most of them do.
My point was, there’s ways to implement the ads without sending metadata about the ads to the client.
Small buffer AND can’t skip ahead on a boring video because you can only get served the ads to unlock further video after time equal to the served video duration has passed.
That is not YouTube, it’s online TV and there will be an impact on the product.
Preloading a video via a 3rd party client will still easily beat this scheme. Just get a headstart equal to the first ad break.
No, you misunderstand. You get seconds assigned to your token. It doesn’t matter where in the video you use those seconds.
So if you watch an ad you get say 60 secs of video until you need to watch an ad again. You can watch 30 secs, then skip 2 minutes ahead and watch another 30 secs, then you get an ad. In reality the times would be larger, but to illustrate a point.
In the current setup YT uses, if you watch an ad, watch 2 secs of video, then skip ahead of the next adbreak, you get more ads.
And yes as stated, a separate client can get around this. But as also stated there will always be ways around it, it’s just a matter of making it harder. If it’s beyond what a simple browser plugin can do, it’s good enough. And YT has been banning 3rd party clients anyways, so that makes it even harder.
Sure if you fundamentally change what YouTube you can make it work.
You need very small buffers or complete disablement of seeking even outside of ads. Otherwise a client can reconstruct the video without viewer interruption.
People however expect to be able to skip ahead in YouTube videos, otherwise its just TV.
Nope that’s not necessary at all, the client experience can be the same as it’s always been. See my other response for what I was thinking of.
Also, this doesn’t work very well in the current YT implementation. If you skip around a video with ads, sometime you’ll get ads even though you’ve just watched a pre-roll for example.
Why would that be the case? The player can simply be locked into ad mode till it gets the cue from the server all of the ads have been streamed. Only then will the player unlock. When watching what amounts to a video stream, this doesn’t have to be handled clientside.
Well the player and its controls are client side.
and making them server site, while possible would introduce tremendous amounts of lag, and put that much more load on the servers. Imagine a server that has to handle playback of billions of users all at once. That’s probably quite a bit worse than most average, or even high-level DDoS attacks.
I’m not talking about the player or the controls being server-side. I’m talking about the player being locked into a streaming mode where it does nothing but stream the ads. After the ads are streamed, the player returns to normal video mode and the server sends the actual video data.
This means no metadata about the ads are required on the player side about the ads.
Sure you can hack the player into not being locked during the streaming of the ads. But that won’t get you very far, since it’s a live stream. You can’t skip forward, because the data isn’t sent yet. You can skip backwards if you’d like, with what’s in the current buffer, but why would you want to? You can have the player not display the ads, but that means staring at a blank screen till the ads are over. And that’s always the case, one can simply walk away during the ads.
Technically I can think of several ways to implement this, without the client having meta data about the ads. And with little to none ways of getting around the ads. Once the video starts it’s business as usual, so it doesn’t impact regular viewing.
So you would need buffer barrieres essentially.
Still user watches video. Ad avoidance skips forward to buffer barrier to play ad in the background. Streamed ad is thrown away and new buffer data is received. User does not notice if the video is long enough.
In this case the buffer limit is the metadata.
Yeah I’m thinking of a system like this:
A user opens a session to watch a video, the user is assigned a token to watch the requested video. When the user isn’t a premium subscriber and the video is monetized the token is used to enforce ads. To get video data from the server, the user needs to supply the token. That token contains a “credit” with how many seconds (or whatever they use internally) the user can watch for that video. In order to get seconds credited to the token, the user needs to stream ad content to their player. New ad content is only available to stream, once the number of seconds they were credited have been elapsed.
One way to get around this is to have something in the background “watch” the video for you, invisible, including the ads. Then records the video data, so it’s available for you to watch without ads. But it would be easy to rate limit the number of tokens a user can have. There’s ways to get around that as well. But this seems to me well beyond what a simple browser plugin can do, this would require a dedicated client.
The idea is to make it harder for users to get around the ads, so they’ll watch them instead of looking for a way to block ads. In the end there isn’t anything to be done, users can get around the ads. Big streaming services use DRM and everything and their content gets ripped and shared. With YouTube it would be easy for someone to have a Premium account, rip the vids and share them. But by putting up a barrier, people watch the ads. YouTube doesn’t care if a percentage of users doesn’t watch the ads, as long as most of them do.
My point was, there’s ways to implement the ads without sending metadata about the ads to the client.
I just read your list and it confirms mine.
Small buffer AND can’t skip ahead on a boring video because you can only get served the ads to unlock further video after time equal to the served video duration has passed.
That is not YouTube, it’s online TV and there will be an impact on the product. Preloading a video via a 3rd party client will still easily beat this scheme. Just get a headstart equal to the first ad break.
No, you misunderstand. You get seconds assigned to your token. It doesn’t matter where in the video you use those seconds.
So if you watch an ad you get say 60 secs of video until you need to watch an ad again. You can watch 30 secs, then skip 2 minutes ahead and watch another 30 secs, then you get an ad. In reality the times would be larger, but to illustrate a point.
In the current setup YT uses, if you watch an ad, watch 2 secs of video, then skip ahead of the next adbreak, you get more ads.
And yes as stated, a separate client can get around this. But as also stated there will always be ways around it, it’s just a matter of making it harder. If it’s beyond what a simple browser plugin can do, it’s good enough. And YT has been banning 3rd party clients anyways, so that makes it even harder.
Sure if you fundamentally change what YouTube you can make it work.
You need very small buffers or complete disablement of seeking even outside of ads. Otherwise a client can reconstruct the video without viewer interruption.
People however expect to be able to skip ahead in YouTube videos, otherwise its just TV.
Nope that’s not necessary at all, the client experience can be the same as it’s always been. See my other response for what I was thinking of.
Also, this doesn’t work very well in the current YT implementation. If you skip around a video with ads, sometime you’ll get ads even though you’ve just watched a pre-roll for example.