3 ms·

The code running in my browser isn't a multi-tenant production server, with access to the filesystem and DBs.

yawn 6y ago
From the article: "Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission."
- hombre_fatal 6y ago
  That just means you have to run with the -http -fs, etc. flags. But you are using those when writing any nontrivial Deno app like a webserver anyways. "web browsers already do this ;)" isn't a good comparison.
  - mrkurt 6y ago
    "But I have to turn all that stuff on" is also not a good comparison. Actually, no Deno webserver I've written gets fs access. Some only get --allow-net.
XCSme 6y ago
I think that's the main selling point of deno, sandboxing.
0beah 6y ago
Except that with Deno, everything IO related is turned off by default and has to be granted access before it becomes a process. It's the first bullet point on the landing page. Here is the page with more detail. https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions It can even restrict access down to a specific directory or host. This is cool. Whereas any NPM module can map your subnet, lift your .ssh directory, and yoink environment variables, wily-nily. It's happened before.
- sterlind 6y ago
  That still doesn't prevent imported modules from yoinking anything you did grant access to, though. For instance, if my service connects to a DB then `uuid` can slurp the contents. It'd be nice to have some capability model where modules can only access things through handles passed to them, but probably infeasible for a project like this.
  - mrkurt 6y ago
    You can actually run things as Workers in Deno and get some sandboxing abilities: https://github.com/denoland/deno/blob/master/docs/runtime/workers.md https://github.com/denoland/deno/blob/master/docs/runtime/wo...

yawn 6y ago

From the article: "Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission."

hombre_fatal 6y ago
That just means you have to run with the -http -fs, etc. flags. But you are using those when writing any nontrivial Deno app like a webserver anyways. "web browsers already do this ;)" isn't a good comparison.
- mrkurt 6y ago
  "But I have to turn all that stuff on" is also not a good comparison. Actually, no Deno webserver I've written gets fs access. Some only get --allow-net.

XCSme 6y ago

I think that's the main selling point of deno, sandboxing.

0beah 6y ago

Except that with Deno, everything IO related is turned off by default and has to be granted access before it becomes a process. It's the first bullet point on the landing page. Here is the page with more detail. https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions It can even restrict access down to a specific directory or host. This is cool. Whereas any NPM module can map your subnet, lift your .ssh directory, and yoink environment variables, wily-nily. It's happened before.

sterlind 6y ago
That still doesn't prevent imported modules from yoinking anything you did grant access to, though. For instance, if my service connects to a DB then `uuid` can slurp the contents. It'd be nice to have some capability model where modules can only access things through handles passed to them, but probably infeasible for a project like this.
- mrkurt 6y ago
  You can actually run things as Workers in Deno and get some sandboxing abilities: https://github.com/denoland/deno/blob/master/docs/runtime/workers.md https://github.com/denoland/deno/blob/master/docs/runtime/wo...