Safe by default, not as an afterthought

Most programs get far more access than they need. A little script that is only supposed to read one file can in practice read your entire home directory, open network connections and send data out into the world — because it inherits everything the operating system gives the user who started it.

Flip the default

Norscode does the opposite. A program starts with no access to anything at all. Want it to read files, you give it disk.read. Should it go online, you give it net.tcp. Everything else is closed, and the program cannot ask for more along the way — the boundary is set by whoever starts it, not by the code itself.

That means you can run code you have not read every line of, and still know what it can do at most. A dependency deep down in your library cannot steal keys it was never given access to.

Why it is worth the extra lines

The model costs something. You have to think through what your service actually needs, and write it down when you start it. In return, you have a concise, honest list of the program's permissions — readable by a human, not hidden in a thousand lines of code.

In an age where most security holes are about something being allowed to do more than it should, we believe safety must be the starting point, not something you remember to switch on at the end.

Capabilities are not an extra feature in Norscode. They are part of how the language sees the world.

A stance, not just a feature

What sets Norscode apart here is not that it is possible to restrict a program — that can be done in many systems. The difference is that it is the starting point. Most languages start with full trust and let you tighten up if you bother; Norscode starts with zero trust and lets you open exactly what is needed. That order changes everything, because the safe state is the one you get for free, not the one you have to remember to choose.

Why the default decides

Security that requires extra work often does not get done — not out of ill will, but because there is a rush, and what works, works. When the safe thing is the default, it flips: now you have to actively do something unsafe for it to become unsafe, and then it becomes visible. The vast majority of security incidents in modern software are about something being allowed to do more than it needed. A model where nothing is allowed to do anything at all unless you said so attacks precisely that root.

Worth the extra lines

Specifying what a program is allowed to do costs a few lines when you start the service. In return, you have a short, honest list of the program's permissions — readable by a human, not hidden in a thousand lines of code. Safety is not an afterthought you add when something has gone wrong. In Norscode, it is there from the very first moment.

Back to the overview