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

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.

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.