←back to thread

856 points bertman | 1 comments | | HN request time: 0.2s | source
Show context
djoldman ◴[] No.45899558[source]
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).

replies(2): >>45900422 #>>45900960 #
arbll ◴[] No.45900422[source]
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.
replies(3): >>45900665 #>>45903690 #>>45907042 #
zahlman ◴[] No.45907042[source]
> 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?

replies(2): >>45907339 #>>45907618 #
franga2000 ◴[] No.45907339[source]
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.
replies(2): >>45907609 #>>45907635 #
NoahZuniga ◴[] No.45907609[source]
Great news! Deno uses the same runtime as chrome, so you benefit from all those found exploits.
replies(1): >>45907707 #
1. arbll ◴[] No.45907707[source]
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.