Safety without trust: capabilities versus the rest

The most important thing Norscode does differently is not about syntax, but about trust. Let us compare how different runtimes handle what a program is allowed to do.

The usual model: full trust

In most languages — Python, Ruby, Go, and traditionally JavaScript on Node — a program inherits the access of the user who starts it. If it is to read one file, it can in practice read all of them. If it is to go online, it can call anywhere. That means a dependency deep down in the tree, which you have never read, has the same access as your own code. The vast majority of security incidents in modern software are precisely about something being allowed to do more than it needed.

A growing movement

Norscode is not alone in taking this seriously. Deno, made by the same person who started Node, came with a permission system where you explicitly grant --allow-read, --allow-net and the like. Newer Node versions have begun to offer something similar. The direction is clear: access should be granted, not assumed.

Where Norscode goes further

In Norscode, capabilities are not a flag you can remember to switch on, but the core of the runtime. A program starts with nothing, and you specify precisely what it gets: which area of the disk, which host on the network, whether it may read environment variables. The program cannot ask for more along the way — the boundary is set by whoever starts it, and cannot be negotiated away by the code.

What does it mean for you?

If the security model matters a lot to you, both Deno and Norscode are worth looking at. Norscode adds Norwegian syntax and a broad standard library on top of the same basic idea: that safety should be the starting point, not an afterthought.

Back to the overview