This, in turn, will spawn user scripts which work around the detection. Any client-side solution will be an arms race between Google and user script/adblock devs. The only real way to prevent it is to withhold the video stream from the CDN until the client has streamed the full ad and/or bake it into the video stream. My impression is that Twitch does this for its live streams (although not VODs).
given that in-stream ads still have blocking/ignoring methods I think that if this arms race keeps going that ultimately the data (video, whatever) is going to be stuffed behind some hard authentication barrier of some sort -- and then traditional piracy methods will take over like single-user-rebroadcast/etc.
The number of people who will do all the things necessary to play in that arms race gets smaller and smaller with each extra difficulty.
In the end, if the only way to block the ads is to have a setup so complicated that only 1 in 10,000 people would be able and willing to maintain it, that’s basically perfect. The people who will spend hours and hours perfecting and maintaining their ad blocking setup were never going to buy premium anyway and they’re negligible drains on resources.
I look forward to my browser-based TiVo, buffering videos to ship over ads just like in the 00s... TV started as advertising channels, it's not surprising YouTube converges towards the cesspool of cable TV.
Well if they copy Twitch I suspect it will be circumvented very quickly. My adblock works just fine for Twitch, I do not see any adverts (unless I open using incognito).
Another option is to require Chrome for playback outside of authenticated apps, and lock Chrome down.
TBH baking it into the video stream is probably the easiest path. The whole video doesn't have to be re-encoded if the ad is spliced in. This is a "soft lockdown" since the ad can theoretically be manually skipped by the user, but its probably good enough.
I wonder when they’ll completely forgo HTML and will just start serving giant polymorphic/obfuscated WebAssembly blob that would perform all the rendering
baking into the video stream loses their ability to auction off ads in realtime to customize ads per viewer based on all of the analytics they've hoovered up on that viewer. they aren't doing the hoovering to go back to old school pre-determined ad placement
It makes it harder but there’s no technical reason why they couldn’t assemble the video on the fly and splice in ads seamlessly based on the same selection logic they used now.
Personally, I’d just start generating temporal IDs for all content (user or ad) so there was no way to know what the stream contained w/o something prohibitively expensive on the client side. Permalinks, since they’re necessary would just redirects (to a temporal URL).
A temporal URL here uses different random looking values for the each user rather than a fixed one (like a URL shorter), and encode a validity window (not before/after).
The core idea here being that the code in the app doesn’t know the difference between ads and user content, which would make it very difficult for any intermediary to do so. And, if if they did the URL for the “real” content wouldn’t work until the time to play the ad had passed - so what’d be the point in bothering?
Like others have said - ya just have to pay for the things you value. No shame in being thrifty, but as I learned from my first employer: pick great suppliers and never force them out of business.
> This, in turn, will spawn user scripts which work around the detection. Any client-side solution will be an arms race between Google and user script/adblock devs
No, you can't adblock remote attestation. Trust me, the whole idea is cryptographically sound (with a proper implementation of course), people have been building out the remote attestation/TPM space for 20 years now. It is unambiguously possible to use a TPM to detect modification of BIOS, OS, drivers, or anything else in the system, and you effectively cannot modify the TPM at all, and it has minimal attack surface (it just is a key-signing machine, essentially).
Every time it's brought up (like I previously suggested that it could be used by NVIDIA/etc to disrupt mining operations from a VBIOS level) there's people who think there is some easy runaround and if there was the whole idea would be broken from the start. The TPM provides a secure root to start the cryptographic validation from, and while you can mod the software, it will be immediately evident from the attestation, and they will simply not serve the video. Or in the case of a GPU, you can have the PC attest to the drivers being official and unmodified, and if that doesn't happen the GPU refuses to clock up the memory bus, if the workload displays the characteristics of mining (100% memory load, flat and constant and low shader load).
At best it will be an arms race between TPM developers and adblock devs.
There is also the "analog gap", but that's been notionally plugged for years using HDCP. Early implementations were quickly broken, HDCP 2.3 is still doing pretty well, and it provides a massive speedbump to people who think they're just going to plug a capture card in and loop the video through.
Netflix and others have been doing this for years and the tricks are well-known at this point. Netflix doesn't push too hard, but they won't serve you the highest-quality video if you don't have a secure signal path either.
AFAIK at this point most of the "ripping" of decryption keys/etc for streaming content happens not by attacking the TPM, but by using android devices that are allowed to skate with reduced security modes, and just having a giant stack of them so when one device gets banned they throw it away and move onto the next.
>AFAIK at this point most of the "ripping" of decryption keys/etc for streaming content happens not by attacking the TPM, but by using android devices that are allowed to skate with reduced security modes, and just having a giant stack of them so when one device gets banned they throw it away and move onto the next.
Without a TEE (eg. trustzone), you're not going to get anything above 540p, at least with widevine. Note TEE is baked into the SoC itself, so while it's not impossible to find a bug, it's much harder than finding a exploit in android or system apps.
I unfortunately can't find references at the moment, but I've heard that some/most of this is done with nVidia Shield TV boxes which have the same Tegra X1 security flaws used to exploit the early Nintendo Switches.
