The sandboxing features of Deno also seem to have played a role in that choice. I wouldn't overly trust that as a security layer but it's better than nothing.

▲

hyperrail 3 days ago | parent | next [-]

This is the first time I've heard of Deno so I'm only going by their Security & Permissions doc page [1], but it looks like the doc page at the very end recommends using system-level sandboxing as a defense in depth. This suggests that Deno doesn't use system sandboxing itself.

To me this is a bit alarming as IIRC most app runtime libraries that also have this in-runtime-only sandboxing approach are moving away from that idea precisely because it is not resistant to attackers exploiting vulnerabilities in the runtime itself, pushing platform developers instead toward process-level system kernel-enforced sandboxing (Docker containers or other Linux cgroups, Windows AppContainer, macOS sandboxing, etc.).

So for example, .NET dropped its Code Access Security and AppDomain features in recent versions, and Java has now done the same with its SecurityManager. Perl still has taint mode but I wonder if it too will eventually go away.

[1] https://docs.deno.com/runtime/fundamentals/security/

	▲	arbll 3 days ago \| parent [-]
		Deno is a V8 wrapper, the same JS engine as Chrome. Vulnerabilities are very common there, not necessarily because it's poorly designed but more because there's massive financial incentives in findings them. This plus what you mentioned is why I would never trust it to run arbitrary code. Now in the context of yt-dlp it might fine, google isn't going to target them with exploits. I would still prefer if they didn't continue to propagate "DeNo iS SaFe BeCauSe It HaS sAnDbOxInG" because I've seen projets that were actually executing arbitrary JS rely on it thinking it was safe.

▲

CuriouslyC 3 days ago | parent | prev [-]

Deno sandboxing is paper thin, last time I looked they had very simple rules. It's a checkbox feature. If you want isolation use WASM.

▲

ndjddirbrbrbfi 3 days ago | parent | next [-]

It doesn’t have granularity in terms of what parts of the code have what permission - everything in the same process has the same permission, but aside from that I’m not sure what you mean about it being paper thin. Certainly WASM is a great option, and I think it can facilitate a more nuanced capabilities model, but for cases like this AFAIK Deno should be secure (to the extent that V8 is secure, which Chrome’s security depends on).

It being a checkbox feature is a weird way to frame it too, because that typically implies you’re just adding a feature to match your competitors, but their main competitors don’t have that feature.

In what ways does it fall short? If there are major gaps, I’d like to know because I’ve been relying on it (for personal projects only myself, but I’ve recommended it to others for commercial projects).

▲

arbll 3 days ago | parent | next [-]

Chrome does not rely exclusively on V8's security or else it would routinely get exploited (See v8 CVEs if you don't believe me). The hard part of browser exploitation today is escaping from the os-level sandbox put on the processes that run each of your tabs.

Trusting Deno's sandboxing by itself isn't a great idea. An attacker only has to wait for the next V8 exploit to drop, probably a question of a few months at worse.

Now like I mentioned above it's probably ok in yt-dlp context, Google isn't going to target it with an exploit. It's still important that folks reading this don't takeaway "deno sandbox safe" and use it the next time they need to run user-supplied JS.

▲

CuriouslyC 3 days ago | parent | prev [-]

Last I looked it was just very basic pattern matching allow/deny with no real isolation, and there have been multiple real escapes already. It's better than nothing, and probably good enough for bush league security, but I wouldn't pitch it to my milspec customers.

▲

yborg 3 days ago | parent [-]

Why are your milspec customers downloading from YouTube? This is the Deno use case being discussed.

	▲	CuriouslyC 3 days ago \| parent [-]
		Don't be reductive, people reading this aren't going to fence their opinion of Deno to the "use in YTDLP" case.

▲

silverwind 3 days ago | parent | prev [-]

WASM can not run JavaScript unfortunately.

	▲	em-bee 3 days ago \| parent [-]
		WASM can run a javascript interpreter or compiler. if isolation is the goal, that may even make sense.