--- Explaining it here to cut off tangents
A capability is like a $5 bill.... a stand alone one time access to resources. You can't accidentally give away your house, or drain your bank account when you hand someone that single piece of cotton bond paper. It doesn't require trusting the recipient.
We have no equivalent in Linux, Mac, Windows, etc. Genode might get there soon, and GNU Hurd was supposed to get there in the 1980s.
We need a simple and easy way to run code we never, ever want to trust with a file or folder of our choosing, as users, at run-time, as easily as the wallet example above.
My hope currently is pinned on WebAssembly and WASI[2], which actually implements capabilities correctly (for now, let's hope they can resist calls to make it "developer friendly" or "more efficient", etc.)
See [3] for a way to use WebAssembly/WASI to run x86_64 Linux binaries in the browse.
--- Call for action
What new/different words could we use, to refer to capabilities based security?
[1] https://en.wikipedia.org/wiki/Capability-based_security
[2] https://en.wikipedia.org/wiki/WebAssembly#WASI
[3] https://news.ycombinator.com/item?id=34367767
Capabilities: have you seen CHERI for RISC-V IoT, https://msrc-blog.microsoft.com/2022/09/06/whats-the-smalles...?
Branding: what were some security category brand examples that you consider to be successful?
It's rather not like this. A capability references the resource(s) that it gives access to. Better off with an excerpt from Wikipedia:
> A capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object.
The catch phrase I keep in my head is "possession is ability" and similarly ability requires a capability (token). The capability names the resources, the actions, etc. The system does not have to look up the token somewhere to see what the authorizations cover, it's in the capability itself.
There is some detail in sharing between processes, e.g. the capability being shared has the capability to share it, and use of a mechanism that maintains integrity.
Specifically adding the word "security" for the token itself rather than the system (to me) conflates it with previous security systems that use indirection and security checks based on the 'other' information.
Given that we have "capability-based security" already, I'd say keep it as-is. It's fine if people think they know when they don't as long as they're not the ones creating the systems.
dynamic security? (substitute greek root for latin; also buzzword optimised)
direct security? (because it is not mediated by identities or roles)
demonstrated security? (a capability in a sense carries its proof?)
"I confused the sheriff, but I did not confuse the deputy" security?