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

From

https://github.com/yt-dlp/yt-dlp/wiki/EJS

it looks like deno is recommended for these reasons:

> Notes

> * Code is run with restricted permissions (e.g, no file system or network access)

> * Supports downloading EJS script dependencies from npm (--remote-components ejs:npm).

It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code. Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.

i wonder if it would be legal if they did, as an anti-circumvention counter-measure.

For a long time, yt-dlp worked completely with Python. They implemented a lightweight JavaScript interpreter that could run basic scripts. But as the runtime requirements became more sophisticated it struggled to scale

> It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp

yt-dlp supports a huge list of websites other than youtube

Is there a full list? I struggled to find one

> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.

... Isn't the web browser's sandboxing runtime-level?

Yes, and it's only reasonably secure because of years of exploits being found and fixed by some of the best (and very well-funded) software security engineers out there.

There's a supportedsites.md file in the base directory of the git repo.

Great news! Deno uses the same runtime as chrome, so you benefit from all those found exploits.

It used to be 100% runtime-level and it was the golden age of browser exploits. Each of your tabs are now a separate process that the OS sandboxes. They can only access a specific API over IPC for anything that goes beyond js/rendering (cookie management, etc...). An exploit in V8 today only gives access to this API. A second exploit is needed in this API to escape the sandbox and do anything meaningful on the target system.

That's not true. It's secure because they are stacking OS-sandboxing on top, forcing attackers to find a chain of exploits instead of a single issue in V8

While you benefit from the V8 fixes it lacks OS-level sandboxing (see above). Chrome is safe because it stacks security layers. Runtime sandboxing is just one of them and arguably the weakest one.

I assumed they only use this setup for youtube, that might be wrong