- cross-posted to:
- piracy@lemmy.dbzer0.com
- cross-posted to:
- piracy@lemmy.dbzer0.com
So many corporate bootlickers here, damn.
This whole thread is a whole lot of hullabaloo about complaining about legality about the way YouTube is running ad block detection, and framing it as though it makes the entire concept of ad block detection illegal.
As much as you may hate YouTube and/or their ad block policies, this whole take is a dead end. Even if by the weird stretch he’s making, the current system is illegal, there are plenty of ways for Google to detect and act on this without going anywhere remotely near that law. The best case scenario here is Google rewrites the way they’re doing it and redeploys the same thing.
This might cost them like weeks of development time. But it doesn’t stop Google from refusing to serve you video until you watch ads. This whole argument is receiving way more weight than it deserves because he’s repeatedly flaunting credentials that don’t change the reality of what Google could do here even if this argument held water.
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.
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
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.
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…