Yt-dlp: External JavaScript runtime now required for full YouTube support

Can you explain in simple terms what would prevent one from running the decryption programmatically posing as the end client?

Here are a couple ideas:

The decryption code could verify that it's only providing decrypted content to an attested-legitimate monitor, using DRM over HDMI (HDCP).

You might try to modify the decryption code to disable the part where it reencrypts the data for the monitor, but it might be heavily obfuscated.

Maybe the decryption key is only provided to a TPM that can attest its legitimacy. Then you would need a hardware vulnerability to crack it.

Maybe the server could provide a datastream that's fed directly to the monitor and decrypted there, without any decryption happening on the computer. Then of course the reverse engineering would target the monitor instead of the code on the computer. The monitor would be a less easily accessible reverse engineering target, and it itself could employ obfuscation and a TPM.

Let's say the only devices you can get that will run YouTube are running i/pad/visionOS or Android and that those will only run on controlled hardware and that the hardware will only run signed code. Now let's say the only way to get the YouTube client is though the controlled app stores on those platforms. You can build a chain of trust tied to something like a TPM in the device at one end and signing keys held by Apple or Google at the other that makes it very difficult to get access to the client implementation and the key material and run something like the client in an environment that would allow it to provide convincing evidence that it is a trusted client. As long as you have the hardware and software in your hands, it's probably not impossible, but it can be made just a few steps shy.

Attestation requiring a hardware TPM 2.0 (or higher), and not being able to extract the private key from the TPM on your system.

TPM is Mathematically Secure and you can't extract what's put in. See, Fritz-Chip.

Yes, it's called: Web Environment Integrity + hardware attestation of some kind

> "the technical means through which WEI will accomplish its ends is relatively simple. Before serving a web page, a server can ask a third-party "verification" service to make sure that the user's browsing environment has not been "tampered" with. A translation of the policy's terminology will help us here: this Google-owned server will be asked to make sure that the browser does not deviate in any way from Google's accepted browser configuration" [1]

https://www.fsf.org/blogs/community/web-environment-integrit...

You don't get access to the decryption code nor the keys - both are hardwired in silicon.

We'll eventually be able to reverse-engineer that and run it programmatically, but it will take a long time.

And when they catch you doing so, they'll ban your (personalized) encryption key so you'll just have to buy another graphics card to get another key.

This is how it already works, not some future thing. But the licensing fees make it so it only gets used for Hollywood-level movies.