Deno JS: A safe JS environment in the making?

Safe Modules
#1

Ryan Dahl, the creator of Node.js has begun building a new JavaScript runtime environment intended for secure scripting called Deno.

  • Includes “no permissions by default”, but once permissions are granted, they seem to be granted for the entire dependency graph.
  • Modules are loaded using ESM exclusively using URLs.

Deno may already be too far along to influence, but it is very young, and I can’t help but think Ryan would greatly benefit from a SES/Ocap deep-dive.

Has anyone else looked at this, or considered how it could play into the larger “safe JS” ecosystem?

2 Likes
#2

I don’t believe that (more broadly) other JS runtimes (aside from browsers, node and iot like moddable) have been discussed within the group — sure people must dealt with them at various aspects.

It could be of interest to collate a list in order to contrast them for SES readiness.

Thoughts?

#3

huh, super interesting. I haven’t had time to watch the video yet, but it sounds like something we should be aware of. Does anyone have access to Ryan?

1 Like
#4

I saw this around a year ago, and honestly it was pitched somewhat like why the other guy is bad rather than why this guy is actually worthwhile.

Digging deeper into deno is something that has repeatedly not proven worth keeping on my queue (ie it comes up, I look once, then get busy enough to overcome the excitement of looking a second time).

But I know for sure there are more non-Node.js (just like there was more non-IE) and somehow feel inclined to think deno is not netscape in that story. Netscape is just too cool for deno imho :slight_smile:

Edit: Not saying Node.js is IE or Netscape here though — but deno seemed to pull a page from that book is all. RIP Netscape and I/Edge (not-chromium-based)

#5

I do not have direct access, but Deno has a public twitter account.

2 Likes
#6

I skimmed through the talk. It seems like the only control over permissions happens at the command line via flags, but I might have missed something. Did anyone else see other places that might control permissions?

23%20PM

#7

Yes, the cli flags disable protections for those permissions, and otherwise the scripts request user permission for each one at runtime. I still need to experiment more, but I read others saying this approval applies to the script’s whole dependency graph, breaking ocap, but maybe some properly phrased suggestion could lean them in towards only permitting per requesting scope/realm.

1 Like
#8

I have one somewhere collecting dust — somehow we are still alive :slight_smile:

#9

I think the premise of his model lies in the fact that it reproduces a preemptively configured authority of a <frame csp="…"><script>… over the process.

This thread seems to be where this discussion might not yet be getting the required attention.

1 Like
#11

Having read through that, given that one of Deno’s prime directives is that it basically replicates the browser module system in a system environment, making the modules pure or isolated in global scope would be a large breaking change to the entire initiative.

I’m glad to see they did bring up support for Realms, but the summary in this post and this one seem to make it clear that the basic module system of Deno is unlikely to constrain global scope or authorized capabilities for imported modules by default.

My take then is that “at least they’re constraining script permissions at the root level, and are open to making that system more nuanced”, and if those root-level attenuations can be fine-grained enough, at least entire scripts can have explicit permissions declared. You could probably even have a deno script initialize another one with more limited permissions, which seems like it would achieve a basic kind of ocap, in addition to service workers and realms.

1 Like