[mborch]

> A program run with Deno has no file, network, or environment access unless explicitly enabled.

You can do this using containerization technology, no need to invent this per language runtime.

[ravenstine]

Not all software is shipped using containers. For example, with Deno, you can compile your application into a single executable binary. By having permissions built into the runtime, this means you can import a third-party package but only allow network requests to go to specific URLs; this way, even if malicious code is referenced in the app, it can't phone home.

[fabiospampinato]

Yes but now in non-linux systems you have the pretty large overhead of that.

[mborch]

On MacOS, you have built-in sandboxing via "sandbox-exec" which shouldn't incur any noticeable overhead. It's used by Chrome, Bazel, etc.

Not sure what's available on Windows.

[int_19h]

Windows has a lot of things in this department. https://github.com/microsoft/Windows-Sandbox-Utilities sounds similar to what you describe, but there are also finer-grained APIs: https://learn.microsoft.com/en-us/windows/win32/secauthz/app...

[papruapap]

Agree. This feature just make it worse as a script language, which are supposed to have rapid development.

[Leokuma]

You just add a flag to the command line to give permissions. It won't harm your productivity.

[Kinrany]

Even without flags, it will ask to allow access interactively instead of silently aborting.

[ravenstine]

Why? `--allow-all` is the epitome of trivial. You can even wrap the deno executable in a script that passes that to it every time if that's what you really need.

[Kyiro]

Even better, you can do `-A`

[ravenstine]

Yes!