I don’t see any technical specification in the article, but if they inject the ad at the start of the video, making it part of the video itself, would make possible to just skip it using video controls. To avoid user skippin ad thru video controls there should be client-side script blocking it, so an ad-blocker can use this to tell apart an ad from the video itself.
I believe this describes them altering the ad host at load time for the page. DNS blocking of ad serving hosts only work if the hostname stays predictable, so just having dynamically named hosts that change in the loading of the page would make blocking more difficult.
Example: 1234.youtube-ads.com is blocked by AdBlockerX. 5678.youtube-ads-xyz.com is not on the blocklist, so is let through. All they have to do is cycle host or domain names to beat DNS blocking for the most part.
Previously, injecting hostnames live for EACH page load had two big issues:
DNS propagation is SLOW. Creating a new host or domain and having it live globally on multiple root servers can take hours, sometimes days.
Live form injection of something like this takes compute, and is normally set as part of a static template.
They’re just banking on making more money from increased ad revenue to offset the technical challenges of doing this, and offsetting the extra cost of compute. They’re also betting that the free adblocking tools will not spend the extra effort to constantly update and ship blocklist changes with updated hosts. I guarantee some simple logic will be able to beat this with client-side blocklist updating though (ie: tool to read the page code and block ad hosts). It’ll be tricky, probably have some false positives here and there, but effective.
As long as the naming pattern is distinct from important domains you can still block it based on pattern matching. They need to obfuscate ad domains and other hosting domains the same way.
Creating subdomains is quite fast because the request goes right through when it’s unknown to caches, it’s updates when you reuse existing ones that causes trouble with lag.
I’ve tested making new subdomains, it’s literally minutes in real life. Sure, in some pathological case it might be hours, but it’s not actually going to happen realistically.
It’s not literally part of the video, exactly because of what you describe. They are separate streams that get injected into the player before the normal video. You can’t skip them or interact with them in any way (pretty sure it also breaks any purchase links etc). Piped or Invidious don’t have them, ytdl also doesn’t download them.
As of now, afaik, you won’t see them if your account wasn’t selected for the experiment, if you are in incognito mode (with uBO on) or if you have uBlock Origin (and other adblockers) off (you’ll see the normal ads and then the video).
That sounds correct for me. It is possible for them to switch to a system where everyone can manually skip past the ad in the video stream but adblockers are useless (by not sending and indication of the ad to the client), but I don’t see that happening since most people don’t use adblockers and letting all of them easily skip past every ad is probably bad for profits.
There’s already addons that can recognize in-video sponsored content and skip, if youtube splices in ads into the video stream these addons will still work (although depending on how strict server side logic is, they may have to pause when the buffer runs out until the time of the ad length has passed)
It doesn’t recognize the sponsor sections. The community does that. I don’t believe there is any tool right now that can automatically detect the sponsor sections.
Honestly it would be trivial for them to make the video controls server side too and simply not accept fast forward commands from the client during the ad.
We might be in a “Download and edit to watch ad-free” world with this change.
Seems too much, really. Even if they do such a terrible thing, would they not expose a “report ad” or “see the product” buttons? Video buffer is still locally downloaded.
I don’t see any technical specification in the article, but if they inject the ad at the start of the video, making it part of the video itself, would make possible to just skip it using video controls. To avoid user skippin ad thru video controls there should be client-side script blocking it, so an ad-blocker can use this to tell apart an ad from the video itself.
Can anyone correct me on this?
Also, would this affect piped and invidious too?
I believe this describes them altering the ad host at load time for the page. DNS blocking of ad serving hosts only work if the hostname stays predictable, so just having dynamically named hosts that change in the loading of the page would make blocking more difficult.
Example: 1234.youtube-ads.com is blocked by AdBlockerX. 5678.youtube-ads-xyz.com is not on the blocklist, so is let through. All they have to do is cycle host or domain names to beat DNS blocking for the most part.
Previously, injecting hostnames live for EACH page load had two big issues:
DNS propagation is SLOW. Creating a new host or domain and having it live globally on multiple root servers can take hours, sometimes days.
Live form injection of something like this takes compute, and is normally set as part of a static template.
They’re just banking on making more money from increased ad revenue to offset the technical challenges of doing this, and offsetting the extra cost of compute. They’re also betting that the free adblocking tools will not spend the extra effort to constantly update and ship blocklist changes with updated hosts. I guarantee some simple logic will be able to beat this with client-side blocklist updating though (ie: tool to read the page code and block ad hosts). It’ll be tricky, probably have some false positives here and there, but effective.
As long as the naming pattern is distinct from important domains you can still block it based on pattern matching. They need to obfuscate ad domains and other hosting domains the same way.
Creating subdomains is quite fast because the request goes right through when it’s unknown to caches, it’s updates when you reuse existing ones that causes trouble with lag.
I’ve tested making new subdomains, it’s literally minutes in real life. Sure, in some pathological case it might be hours, but it’s not actually going to happen realistically.
It’s not literally part of the video, exactly because of what you describe. They are separate streams that get injected into the player before the normal video. You can’t skip them or interact with them in any way (pretty sure it also breaks any purchase links etc). Piped or Invidious don’t have them, ytdl also doesn’t download them.
As of now, afaik, you won’t see them if your account wasn’t selected for the experiment, if you are in incognito mode (with uBO on) or if you have uBlock Origin (and other adblockers) off (you’ll see the normal ads and then the video).
Otherwise, apply uBO new script if you get them
How does this actually works? Can you point me to technical documentation about this?
I’ve only found info about SSAI, not about SSAP. Is it the same?
That sounds correct for me. It is possible for them to switch to a system where everyone can manually skip past the ad in the video stream but adblockers are useless (by not sending and indication of the ad to the client), but I don’t see that happening since most people don’t use adblockers and letting all of them easily skip past every ad is probably bad for profits.
There’s already addons that can recognize in-video sponsored content and skip, if youtube splices in ads into the video stream these addons will still work (although depending on how strict server side logic is, they may have to pause when the buffer runs out until the time of the ad length has passed)
It doesn’t recognize the sponsor sections. The community does that. I don’t believe there is any tool right now that can automatically detect the sponsor sections.
Honestly it would be trivial for them to make the video controls server side too and simply not accept fast forward commands from the client during the ad.
We might be in a “Download and edit to watch ad-free” world with this change.
Seems too much, really. Even if they do such a terrible thing, would they not expose a “report ad” or “see the product” buttons? Video buffer is still locally downloaded.
I accept having to wait until the video downloads past the ad. Certainly not going to watch the ad.