A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio (opens in new tab)

Curious about deno's development stage: can the brave already run it in production, or there are probably too many breaking changes in the pipe that it's better to wait?

fyi the sound gets much better at the 3 minute mark

You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect atm)

We have also discussed about possibilities of implementing an in-memory file system. (Maybe we will also bring sessionStorage to Deno)

Flags per module is slightly trickier, while whitelisting of certain feature is trivial to implement.

Package signing is indeed a topic that Deno contributors need to discuss further and possibly finding a solution.

Yes it’s a real shame it isn’t based on object capability security. The resource ID concept makes it really hard to do per-module restrictions, because resources provide global ambient access to anything. And it sounds to me like the dispatch model based on typed arrays means that this is baked in on a fundamental level (unless there are some unforgeable handles that Ryan didn’t mention in his talk).

It's not even 1.0 yet.

>Dies on uncaught errors

how can JS programmers deal with this?

It is very interesting although I didn't really understand the 'security' part. The motivation seems to be twofold - some bad things have happened because of compromised npm packages and v8 happens to have a robust sandbox. This sounds like a solution looking for a vaguely defined problem. The illustrative example he gives is 'malicious linter'. Is malicious linter that important a threat?

> Access between V8 (unprivileged) and Rust (privileged) is only done via serialized messages defined in this flatbuffer.

Expect to see this in "n things I regret about deno"

SES builds on capability theory to let you run "adversarial" code together with your trusted code safely.

Deno is a runtime that aims to isolate the code from the system amongst other issues.

SES uses a proof over the JS grammar with induction, Deno does isolation by not giving any OS level access to your code.

Neither are particularly complete and are mostly orthogonal. Both are looking for people to help with them :]

It is being actively developed. Has a large pool of active contributors.

Nobody's support strictly matches a specific ECMAScript version.

No, it is about how v8 is sandboxed

V8 provides some protections against spectre-like attacks, but that's not specific to deno, as Node.js uses V8 as well.

"Secure" in this case refers to being able to not give deno access to the network or filesystem.

That's just FUD through a synthetic benchmark by the person who wrote uWS after he approached Ryan and Ryan wouldn't do everything he asked for...

That bench has deno at 0.2, it's now at 0.10, though I have no idea how much performance work has been done.

Performance should improve over time, there's no fundamental reason from what I understand that it shouldn't be as fast or faster than node.

node has had 10 years of work and performance effort from so many people and organisations.

You mean JavaScript implementation in Rust. V8 is one of the many implementations that is written in C++.

You can post your opinion here: https://github.com/ansuz/RIIR/issues/

Instead I would rather a SpiderMonkey written in Rust.