I was a fan of deno because at least they tried, its not that there was an alternative runtime that tries to do permissions right or that there is an operating system tool that allows async(!) permissions with user interaction. We really need a simple to use "productised" but true open source solution that allows halting any software and evaluating policies for run, fs and network etc and can reason on process and context level.
Deno is a dead man walking, they cashed out being useful to CF and other than that, they tried parity with nodejs, which was naive, I am not going to redo my backend just for that.
> It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
The permission model is more of a "help developers not accidentally "rm -rf /" their local machine than it is something that helps end users.
You're better off relying on OS-level security mechanisms. Not only is it more likely to be much safer/secure, but it also means you don't have to worry about compatibility, missing features, etc. when you switch runtimes/software stacks.
If you like having something for security — even in Node — check out something I invented, called SafeScript.
It’s for executing untrusted code written by others… a large subset of Javascript which guarantees the code can only call the Facades you inject, and you can hook and intercept anything. It works with callbacks and promises.
What’s more is that it runs in WebWorker sandboxes on the web, and uses a proxy to transparently make existing code make same method calls, or use existing objects, like window.document, but to safer versions, which only allow eg createElement.
And because SafeScript automatically awaits every async function, your synchronous calls to HTMLElement methods etc. will be proxied asynchronously and “just work” without changing the original JS code. SafeScript is robust enough that most existing JS components will simply work without changes when ported to SafeScript.
PS: It can also be embedded in PHP, so you can run untrusted handlers there, too, without worrying about PHP’s large security surface.
PPS: SafeScript is deterministic by default, so you can also get the same results across all environments or runs. You can set the random number generator seed yourself, or inject Date.now() as one of your APIs if you want.
I actually have a terminal program that needs to ask for sensitive inputs from the user sometimes, potentially after attacker data has been printed. I've been trying to figure out how I should handle that!
My plan was to encode to Unicode (lossily), strip out control characters, and add some visual framing. Anything else I should be considering? Is there a standard approach? Haven't actually done the research on this yet, but since it came up here, I figure someone might know.
It was a neat idea but they didn't take it far enough. It would have been neat if you could restrict dependencies from network/FS access, but they didn't make it that granular.
I was a fan of Deno from the beginning, but not targeting NodeJS compatibility at the beginning turned out to be the wrong move. Now Bun gets to be Anthropic's testbed for the future of software development. (Which includes the wholesale plagiarism and optimization of Oxc into its codebase, wowza.)
Side note: `deno fmt` is a great Markdown formatter. I might get around to extracting out just that part of it.
> the permission prompt is “partially visible” (you can see an emoji)
Terminals can be configured to render emoji in text presentation form where they become monochrome glyphs that can be colored like ordinary text with escape sequences. Not something to hinge your security model on.
I'm not a fan of opinions in titles. (there I did it)
It is self-centered and narcissistic. Why? WTFRU. An opinion isn't an argument. You have to have reasons beyond your opinions and those are what matter. Lead with those, and your opinion is implied by the fact you are talking about it.
Deno's Security Model is a False Sense of Security
Deno's Permissions Are Not a Sandbox
The Illusion of Deno's "Secure by Default" Model
Why --allow-run and Permission Prompts Don't Make Deno Safe
The title weakens an otherwise pretty good article.
I was a fan of deno because at least they tried, its not that there was an alternative runtime that tries to do permissions right or that there is an operating system tool that allows async(!) permissions with user interaction. We really need a simple to use "productised" but true open source solution that allows halting any software and evaluating policies for run, fs and network etc and can reason on process and context level.
Deno is a dead man walking, they cashed out being useful to CF and other than that, they tried parity with nodejs, which was naive, I am not going to redo my backend just for that.
Deno has 1 year of official support left...
I liked the security model because at least they had something, unlike node.
Node actually took that from Deno, they do have a permission model now: https://nodejs.org/api/permissions.html
From their documentation:
> It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
The permission model is more of a "help developers not accidentally "rm -rf /" their local machine than it is something that helps end users.
But doesn’t preventing accidents help end users too?
Something can be worse than nothing when it tricks users into thinking it provides meanigful security guarentees.
You're better off relying on OS-level security mechanisms. Not only is it more likely to be much safer/secure, but it also means you don't have to worry about compatibility, missing features, etc. when you switch runtimes/software stacks.
If you like having something for security — even in Node — check out something I invented, called SafeScript.
It’s for executing untrusted code written by others… a large subset of Javascript which guarantees the code can only call the Facades you inject, and you can hook and intercept anything. It works with callbacks and promises.
What’s more is that it runs in WebWorker sandboxes on the web, and uses a proxy to transparently make existing code make same method calls, or use existing objects, like window.document, but to safer versions, which only allow eg createElement.
And because SafeScript automatically awaits every async function, your synchronous calls to HTMLElement methods etc. will be proxied asynchronously and “just work” without changing the original JS code. SafeScript is robust enough that most existing JS components will simply work without changes when ported to SafeScript.
PS: It can also be embedded in PHP, so you can run untrusted handlers there, too, without worrying about PHP’s large security surface.
PPS: SafeScript is deterministic by default, so you can also get the same results across all environments or runs. You can set the random number generator seed yourself, or inject Date.now() as one of your APIs if you want.
Here it is. Should I do a Show HN?
https://github.com/SafeScript/Safescript
I actually have a terminal program that needs to ask for sensitive inputs from the user sometimes, potentially after attacker data has been printed. I've been trying to figure out how I should handle that!
My plan was to encode to Unicode (lossily), strip out control characters, and add some visual framing. Anything else I should be considering? Is there a standard approach? Haven't actually done the research on this yet, but since it came up here, I figure someone might know.
(This is https://codeberg.org/timmc/breakmancer if anyone is interested.)
I don't understand the UX you have in mind, just do it like SSH used to do, a non-echo input field?
It was a neat idea but they didn't take it far enough. It would have been neat if you could restrict dependencies from network/FS access, but they didn't make it that granular.
I was a fan of Deno from the beginning, but not targeting NodeJS compatibility at the beginning turned out to be the wrong move. Now Bun gets to be Anthropic's testbed for the future of software development. (Which includes the wholesale plagiarism and optimization of Oxc into its codebase, wowza.)
Side note: `deno fmt` is a great Markdown formatter. I might get around to extracting out just that part of it.
> the permission prompt is “partially visible” (you can see an emoji)
Terminals can be configured to render emoji in text presentation form where they become monochrome glyphs that can be colored like ordinary text with escape sequences. Not something to hinge your security model on.
Lucky for them. Deno is dead.
Very well written, and excellent points! Thank you.
I'm not a fan of opinions in titles. (there I did it)
It is self-centered and narcissistic. Why? WTFRU. An opinion isn't an argument. You have to have reasons beyond your opinions and those are what matter. Lead with those, and your opinion is implied by the fact you are talking about it.
Deno's Security Model is a False Sense of Security
Deno's Permissions Are Not a Sandbox
The Illusion of Deno's "Secure by Default" Model
Why --allow-run and Permission Prompts Don't Make Deno Safe
The title weakens an otherwise pretty good article.