Today I filed a formal complaint against #YouTube with the Irish Data Protection Commissioner for their illegal deployment of #adblock detection technologies.
Under Article 5(3) of 2002/58/EC YouTube are legally obligated to obtain consent before storing or accessing information already stored on an end user's terminal equipment unless it is strictly necessary for the provisions of the requested service.
In 2016 the EU Commission confirmed in writing that adblock detection requires consent.
I feel like they’re eventually just going to embed the adverts directly into the video streams. No more automated blocking, even downloading will make you see ads. Sure, you can fast forward the video a bit, but it will be annoying enough that you’ll see and hear a few seconds of ads each time, and you won’t be able to just leave it running while you do other things.
the reason they are not doing it is because the ads are personalized. So if they want to bake an ad onto a video they will end up with countless videos each on with their own unique ads which is not viable logistically. So they can only do it on-the-fly. But re-encoding each video on-the-fly for each user is also a nightmare logistically, if not impossible at all.
I don’t think you’d need to re-encode the whole thing on the fly. More frigging the container data around, than the video/audio codec itself.
That way I could request some_pointless_video.mp4 and it sends me 95% the same thing as is already on their server, with adverts jammed into it at defined intervals.
They probably think they can win for now by messing with individual ad-blockers, but with 3rd party players becoming more popular, I can see that being a catch-all solution.
isn’t this more or less what they’re doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
That’s the difference. The ads are coming from somewhere else and displayed in a different way.
By injecting it into the stream, there’s no way to detect that. To your player it would all look like it’s coming from the same place. Instead of a ten minute video and a couple of 20 second ads, it’s now just 11 minutes of video.
yes. But then they have different problems. Now it is the ad company who is responsible to serve the ads and the personalization comes from there. This is achieved by the client directly “asking” the ad company for ads. If they want the ads to come from the same stream this means that the customer identity is passed to youtube, then youtube requests the ads in behalf of the client, and then serves them mixed in the video stream. I’m not a lawyer but I think that this causes different legal problems for youtube on the part that they will need to ask the ads on behalf of someone else.
Also apart from that, technically, the part of the video that is an ad, will be associated with a call-to-action URL and an overlay on top of the video, since they need that by clicking on the video it will go to a the ad’s call-to-action instead of just pausing the video. This will still make them detectable
Don’t they have standardized resolutions and the file broken into hundreds/thousands of parts anyways? Couldn’t they just add in ads to some of those parts in those same resolutions?
Similar to Apple’s HTTP Live Streaming (HLS) solution, MPEG-DASH works by breaking the content into a sequence of small segments, which are served over HTTP.
isn’t this more or less what they’re doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
That’s why Google is pushing hard their Web Environment Integrity. It’s DRM for the browser! They want the TPM chip in your computer to attest that the code running processing the video stream is authentic. Then you can’t slice out the ads because you do not have physical access to the inside of TPM. With HDCP encryption on the HDMI video output, you gonna need to point a literal video camera at the physical screen to DVR the video and slice out the ads later.
They’ve been working hard for decades to lock down the video pipeline with TPM and HDCP and now WEI. They said “don’t worry about it” and we let them. They are really close to snapping the trap shut!
Now please excuse me, my tongue is falling off with all the acronyms…
If users are crowdsourcing what the embedded ads are, couldn’t this hypothetical situation be solved by a version of sponserblock that just looks at the agreggurate of the non-flagged video runtime, and learns what the content is and then cuts out any aberrations?
You could have an app running in the background that detects ads based on the audio (like Shazam for music) and skips it for you. You could probably analyse all the video slices YT sends you and detect ads that way. I think as long as we are still in control of the playback devices we can find ways to make them skip ads.
We left that territory years ago. There are big community projects and entire companies built on providing adblocking features. People will build it if the need and potential audience is great enough.
I feel like they’re eventually just going to embed the adverts directly into the video streams. No more automated blocking, even downloading will make you see ads. Sure, you can fast forward the video a bit, but it will be annoying enough that you’ll see and hear a few seconds of ads each time, and you won’t be able to just leave it running while you do other things.
the reason they are not doing it is because the ads are personalized. So if they want to bake an ad onto a video they will end up with countless videos each on with their own unique ads which is not viable logistically. So they can only do it on-the-fly. But re-encoding each video on-the-fly for each user is also a nightmare logistically, if not impossible at all.
I don’t think you’d need to re-encode the whole thing on the fly. More frigging the container data around, than the video/audio codec itself.
That way I could request some_pointless_video.mp4 and it sends me 95% the same thing as is already on their server, with adverts jammed into it at defined intervals.
They probably think they can win for now by messing with individual ad-blockers, but with 3rd party players becoming more popular, I can see that being a catch-all solution.
isn’t this more or less what they’re doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
That’s the difference. The ads are coming from somewhere else and displayed in a different way.
By injecting it into the stream, there’s no way to detect that. To your player it would all look like it’s coming from the same place. Instead of a ten minute video and a couple of 20 second ads, it’s now just 11 minutes of video.
yes. But then they have different problems. Now it is the ad company who is responsible to serve the ads and the personalization comes from there. This is achieved by the client directly “asking” the ad company for ads. If they want the ads to come from the same stream this means that the customer identity is passed to youtube, then youtube requests the ads in behalf of the client, and then serves them mixed in the video stream. I’m not a lawyer but I think that this causes different legal problems for youtube on the part that they will need to ask the ads on behalf of someone else.
Also apart from that, technically, the part of the video that is an ad, will be associated with a call-to-action URL and an overlay on top of the video, since they need that by clicking on the video it will go to a the ad’s call-to-action instead of just pausing the video. This will still make them detectable
The ad company is Google, no? So they already have that logic ready to go.
Does anybody actually click the ads in YT videos? The only clickable thing I ever see is “Skip Ad”.
Clicks are a metric that Google/YouTube tracks to determine whether a business has to pay for that ad, so it’s necessary for ads to be clickable.
Don’t they have standardized resolutions and the file broken into hundreds/thousands of parts anyways? Couldn’t they just add in ads to some of those parts in those same resolutions?
e.g: https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
isn’t this more or less what they’re doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
We could build a public database (like SponsorBlock) of known ad video slices and detect them that way.
There will always be a way to detect and block ads.
I’m not worried.
That’s why Google is pushing hard their Web Environment Integrity. It’s DRM for the browser! They want the TPM chip in your computer to attest that the code running processing the video stream is authentic. Then you can’t slice out the ads because you do not have physical access to the inside of TPM. With HDCP encryption on the HDMI video output, you gonna need to point a literal video camera at the physical screen to DVR the video and slice out the ads later.
They’ve been working hard for decades to lock down the video pipeline with TPM and HDCP and now WEI. They said “don’t worry about it” and we let them. They are really close to snapping the trap shut!
Now please excuse me, my tongue is falling off with all the acronyms…
Have you met my friend SponsorBlock?
That only works by users crowdsourcing and flagging the advert sections.
By doing it on the fly, each user could get different ads in different places.
If users are crowdsourcing what the embedded ads are, couldn’t this hypothetical situation be solved by a version of sponserblock that just looks at the agreggurate of the non-flagged video runtime, and learns what the content is and then cuts out any aberrations?
You could have an app running in the background that detects ads based on the audio (like Shazam for music) and skips it for you. You could probably analyse all the video slices YT sends you and detect ads that way. I think as long as we are still in control of the playback devices we can find ways to make them skip ads.
Sure, you could do that.
You could also download the stream multiple times under different profiles, compare them and then strip away differences.
But we’re quickly exiting “one guy with a bit of Javascript” territory.
We left that territory years ago. There are big community projects and entire companies built on providing adblocking features. People will build it if the need and potential audience is great enough.
There even is a project that uses machine learning to detect sponsor segments. https://github.com/xenova/sponsorblock-ml
MythTV has a broadcast television ad detection module and it works pretty damn well.
This goes into a bit of detail on it’s methods:
https://www.mythtv.org/wiki/Commercial_detection
A lot of what it does could be applied to a video stream, although adapting it to useful real-time could be tricky.