Object capabilities represent a shift in the way we think about access control and security in software systems. Rather than relying on traditional user-based or role-based access control mechanisms, object capabilities grant access based on the specific capabilities an object possesses. Object capabilities are first class and can be narrowed down to arbitrary granularity by the programmer. • What are the implications of object capabilities for the design and architecture of software systems? How do they impact the modularity, flexibility, and scalability of these systems, and how do they influence our understanding of software architecture more generally? • How can we best leverage object capabilities to promote the development of more secure and resilient software systems? What are the potential pitfalls and challenges associated with this approach, and how can we address them? • How do object capabilities relate to broader philosophical debates about the nature of objects and their properties? Do these capabilities represent a fundamentally new way of thinking about the relationship between objects and their properties, or are they simply a new instantiation of existing concepts?

Hi Joakim, do you have a link to quickly and clearly summarise "object capabilities", esp comparing to traditional, for those of us who don't know?

@Duncan Cragg 3 minutes:

Ah, OK, I'm still waiting for my Ah-ha! moment on this... I get the ACL Bad part now, just struggling with the Capabilities Good, or even the What are They?! So tokens for a permission for, the bearer? to do something?

Yes, you can view them as unforgable tokens that lets you do specific things, such as reading a certain file.

Is "you" the bearer in the code or is "you" a type of thing in the system, presumably it's not the user?

Here's a code example. You'll have to excuse I'm using my own language Firefly here. In Firefly,

main

receives

System

, which is an object representing access to "everything". It contains other capabilities, such as the

FileSystem

, which represents access to the file system. You can further wrap such capabilities yourself to narrow them down, e.g. to only allow access to files in a particular directory.

OK, so still, what is the agent that has the capability, that's checked when the filesystem is asked to do something? Is it simply the bearer, or is the token cross-checked to a user, or to an executable?

The token is an imperfect analogy in this case. It's simply an object that's able to access the file system. The constructor is private, which is how the language enforces that it's unforgable (togehter with a strict type system).

Ah I see

To some degree, browsers and phones employ a form of object capabilities when it comes to accessing the users files or devices.

I was going to ask you about Android's quite fine-grained permission model

For example, the File object in JS represents read-only access to a single file: https://developer.mozilla.org/en-US/docs/Web/API/File

An object capability, conceptually, is pretty much a pointer that is (a) unforgeable (no casting integers or whatever) and (b) revokable. If you're doing this at the OS level, the process would be given some capabilities at startup or via IPC. The kernel will keep track of what capabilities a process has and what they're linked to. IIUC it's also keeping track of capabilities that point to the process, e.g. cases where the process wants to offer an IPC interface to other processes; you can think of the those as virtual objects hosted in the process. So yeah, pretty much bearer tokens. The idea is that a "user" only ever possesses capabilities to files they're allowed to delete, so they can only ever pass those files to the delete command. (by this philosophy, I find the idea of a System capability dubious; it sort of works if it's just your main function not trusting its libraries and your language/runtime is fully reference secure and you've disabled opening files by name, but why settle?).

I agree. The answer to "why settle" is to be part of the near future rather than the far future. It's simply a tradeoff to fit into the existing popular operating systems.

Yes, it was a rhetorical "why settle".