Hacker News Reader

Comment by adzm | Hacker News Reader

I was surprised they went with Deno instead of Node, but since Deno has a readily available single-exe distribution that removes a lot of potential pain. This was pretty much just a matter of time, though; the original interpreter in Python was a brilliant hack but limited in capability. It was discussed a few years ago for the YouTube-dl project here https://news.ycombinator.com/item?id=32793061

View on HN

Node does not have the concept of security and isolation like the Deno has. There is maintainer comment in the same thread.

What evidence is there that Deno's "security and isolation" works?

It's their application, yt-dlp can use whatever it wants. But they made their choices for stylistic/aesthetic reasons.

What evidence is telling the opposite?

Scripts use V8 isolation, identical to Chrome. What comes to rest, we can only trust or review by ourself, but it is certainly better than nothing in this context.

Identical to Chrome except the part where Chrome uses os-level sandboxing on top. V8 exploits are common, Deno sandboxing by itself is not a good idea if you are executing arbitrary code.

We are comparing to situation where the alternative is nothing. Maybe we just should remove locks from the doors because someone has lockpicked door somewhere.

I never said it was a poor choice in this specific context but propagating the idea that Deno's sandboxing is safe and "basically the same security as chrome" is wrong and can easily do damage the next time someone that has read this thread needs a way to execute untrusted JS.

Someone who understands what V8 isolation means, knows that it means process-level memory and garbage collectors. I didn't claim that it includes Chrome's OS sandbox features too.

But the usage of V8 means that Deno must explicitly provide the access (for V8) for networking and filesystem - the foundations for sandboxing are there.

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.

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.

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).

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.

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

Don't be reductive, people reading this aren't going to fence their opinion of Deno to the "use in YTDLP" case.

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.

WASM can not run JavaScript unfortunately.

WASM can run a javascript interpreter or compiler. if isolation is the goal, that may even make sense.

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/

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.

Keep in mind that yt-dlp doesn't just support YouTube, which-- notwithstanding the claims of "all DRM is malware" etc.-- probably won't download actively harmful code to your computer: it also supports a huge number of video streaming sites, including some fairly obscure and sketchy ones. Sandboxing in the interpreter that's at least as good as what you'd get in a browser is a must, because by design this is doing untrusted code execution.

Reply on news.ycombinator.com