1. 20
  1.  

  2. 3

    Barriers are thus an important subject in the design of malleable systems. Their social counterpart is the division of responsibility between the system’s designers, its end users, and the authors of published add-ons. It’s not obvious how to find the right balance between empowering and protecting users, plus making sure that they understand clearly what they are expected to do themselves for their own protection.

    In object-capability theory, though, it is obvious: A user may do anything that they are empowered to do. More generally, an agent, or an object, may invoke any capability that they currently may reference. To quote Chip’s introduction to capabilities for a definition:

    A capability is single thing that both designates a resource and authorizes some kind of access to it. … By “resource” we just mean something the access control mechanism controls access to. … In the same vein, when we talk about “access,” we just mean actually doing something that can be done with the resource. … By “designation,” we mean indicating, somehow, specifically which resource we’re talking about. And by “authorizing” we mean that we are allowing the access to happen.

    Chip continues, and neatly connects the dots:

    Because the capability combines designation with authority, the possessor of the capability exercises their authority – that is, does whatever it is they are allowed to do with the resource the capability is a capability to – by wielding the capability itself.

    So, now we know exactly how to answer the implicit questions in the first quote. The right balance between empowering and protecting users is precisely a collection of capabilities which the user always has. The understanding that users must have in order to protect themselves is precisely an understanding of the interfaces of the capabilities which they have.

    Of course, the task of API design is no simpler merely because we have a nice formal philosophy. But it does help us focus on the important parts. In an object-capability system, every scope is a barrier, and every object has a right to privacy. We do not look at our barriers as unnatural or planned, but as structural guidelines which help us maintain order, sanity, and security.

    We commonly talk of the analogy of the water balloon and the sponge; both leak water when stabbed with a knife, but one more than the other, due to structural differences. From a water-balloon perspective, barriers are unnatural; water is cohesive and adhesive and rejects foreign objects, and really isn’t the purpose of a water balloon to slosh and jiggle and be a big ball of water? But from a sponge perspective, barriers are essential to life; water might be what animates the structure, but the structure is what allows a sponge to be stiff and to interact with its environment and to live a long stable life.

    1. 2

      From a water-balloon perspective, barriers are unnatural; water is cohesive and adhesive and rejects foreign objects, and really isn’t the purpose of a water balloon to slosh and jiggle and be a big ball of water? But from a sponge perspective, barriers are essential to life; water might be what animates the structure, but the structure is what allows a sponge to be stiff and to interact with its environment and to live a long stable life.

      And, of course, the real point is that the sponge is full of water balloons and sponges, recursively, each of which has some level of connection to the others but all of which have some rigid separation from everything else. The VM philosophy, in other words; a way to implement strong notions of scope which encourage nesting, as you can run one copy of VM as a guest inside another VM, and run an OS as a guest-in-a-guest, getting some separation and scoping at each layer.

    2. 1

      Doesn’t Linux fulfill all the requirements of malleable systems? If so (it looks like to me), why isn’t it the most malleable system in history? Being younger than emacs?

      1. 3

        Doesn’t Linux fulfill all the requirements of malleable systems?

        From the definition in the Mission Statement, Linux arguably falls down on the first one:

        1. Easy to change

        Software must be as easy to change as it is to use it.

        I see this as a Sorities Paradox, of which the classic example is the “heap” where, if one grain of sand isn’t a heap of sand, and adding one grain of sand to something which isn’t a heap doesn’t make something a heap, at what point do you have a heap of sand? In this case, it’s a matter of “how easy is easy”: Linux is easily changeable in shell and Python, at least if you consider Emacs and Lisp Machines to be easy to change, but making deeper changes requires languages like C and a less-interactive development process, making it harder to iterate quickly.

        It’s a demarcation problem. I agree that there’s something here, some concept which is interesting and worth discussing, even if we can’t define it absolutely without drawing some arbitrary lines. I think it’s a continuum: Emacs is more dynamically reprogrammable than other editors, like Linux is more malleable than, say, macOS or Windows, in terms of being able to choose your working environment.