Comment by marcosdumay

3 months ago

> This is not a new idea, so I won’t go deeply into what it is

So, no, the author claims it too.

Capabilities are a way to do access control where the client holds the key to access something, instead of the server holds a list of what is allowed based on the clients identities.

But when people use that word, they are usually talking about fine-grained access control. On a language level, that would mean not granting access for example for a library to do network connections, even though your program as a whole has that kind of access.

1 comment

marcosdumay

chriswarbo 3 months ago

Kind of. At a more fundamental level, it's applying the idea that "invalid states should be unrepresentable" (e.g. https://hugotunius.se/2020/05/16/making-invalid-state-unrepr... ) but to our code itself.

For example, consider a simple function to copy files. We could implement it like this:

    def copy(fs: Filesystem, in: Path, out: Path) {
      inH: HandleRead = fs.openRead(in);
      outH: HandleWrite = fs.openWrite("/tmp/TEST_OUTPUT");
      finished: Boolean = false;
      while (!finished) {
        match (inH.read()) {
          case None: finished = true;
          case Some(data) = outH.write(data);
        }
      }
      inH.close();
      outH.close();
    }

However, there are many ways that things could go awry when writing code like this; e.g. it will write to the wrong file, since I forgot to put the real `out` value back after testing (oops!). Such problems are only possible because we've given this function the capability to call `fs.open` (in many languages the situation's even worse, since that capability is "ambient": available everywhere, without having to be passed in like `fs` above). There are also other capabilities/permissions/authorities implicit in this code, since any call to `fs.open` has to have the right permissions to read/write those files.

In contrast, consider this alternative implementation:

    def copy(inH: HandleRead, outH: HandleWrite) {
      finished: Boolean = false;
      while (!finished) {
        match (inH.read()) {
          case None: finished = true;
          case Some(data) = outH.write(data);
        }
      }
      inH.close();
      outH.close();
    }

This version can't use the wrong files, since it doesn't have any access to the filesystem: there's literally nothing we could write here that would mean "open a file"; it's unrepresentable. This code also can't mix up the input/output, since only `inH` has a `.read()` method and only `outH` has a `.write()` method. The `fs.open` calls will still need to be made somewhere, but there's no reason to give our `copy` function that capability.

In fact, we can see the same thing on the CLI:

- The first version is like `cp oldPath newPath`. Here, the `cp` command needs access to the filesystem, it needs permission to open files, and we have to trust that it won't open the wrong files.

- The second version is like `cat < oldPath > newPath`. The `cat` command doesn't need any filesystem access or permissions, it just dumps data from stdin to stdout; and there's no way it can get them mixed up.

The fundamental idea is that trying to choose whether an action should be allowed or not (e.g. based on permissions) is too late. It's better if those who shouldn't be allowed to do an action, aren't even able to express it at all.

You're right that this can often involve "keys", but that's quite artificial: it's like adding extra arguments to each function, and limiting which code is scoped to see the values that need to be passed as those arguments (e.g. `fs.openRead(inPath, keyThatAllowsAccess)`), when we could have instead scoped our code to limit access to the functions themselves (though for HTTP APIs, everything is a URL; so "unguessable function endpoint URL" is essentially the same as "URL with secret key in it")