Capabilities in production systems

[Alan Karp]

I expect that many of you have heard someone say, "If capabilities are so great, why is nobody using them."

Kenton has just told us that they are being used at Cloudflare.  They are also an important part of the offerings of DigitalBazaar.  Do you know of others?

Does it make sense to put up a web page (I suggest on erights.org) listing these examples and others we learn of?

--------------
Alan Karp

[Kenton Varda]

To be fair capabilities are used in Cloudflare Workers because I designed it that way. ;)

But everyone is pretty happy with the result.

Actually, though, capabilities are everywhere. Android's Binder and Chrome's Mojo (foundational parts of these respective systems) are capability systems. I'd argue capabilities are actually very common in successful systems, they just aren't always labeled as such and aren't always "pure".

-Kenton

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z2OmEmpE0bTieON%3Df3w7hKvTEGsrV%3DS033AsKg1-sPe2Q%40mail.gmail.com.

[John Kemp]

El 09/26/25 a las 12:57, Kenton Varda escribió:

> Actually, though, capabilities are everywhere. Android's Binder and
> Chrome's Mojo (foundational parts of these respective systems) are
> capability systems. I'd argue capabilities are actually very common in
> successful systems, they just aren't always labeled as such and aren't
> always "pure".

Back in the days when I wrote this in the W3C TAG:
https://www.w3.org/2001/tag/2010/06/01-cross-domain.html related to UMP
vs CORS, I was an enthusiastic designer of capability systems while at
Nokia, but I avoided direct use of the term "object capability."

At that time, Google Doc and Dropbox sharing links, Second Life use of
capability URLs and quite a few others, along with Google's Caja project
were all using ocaps in deployed systems around that time.

Jeni Tennison later wrote a nice document about best practices for
capability URLs: https://www.w3.org/2001/tag/doc/capability-urls/ and
https://w3ctag.github.io/presentations/reveal/capability-urls.html

Worth noting that Jonathan Rees and Dan Connolly were also on the TAG at
this time.

- johnk
--
Independent Security Architect
t: +1.413.645.4169
e: stable.p...@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj

[Charlie Landau]

On 9/26/25 10:53 AM, John Kemp wrote:

Google Doc and Dropbox sharing links, ... were all using ocaps

Sharing-links that are text strings can be published to the world, even if you don't have a capability to the world, making confinement impossible. Not what I want in a capability system.

--
Charlie Landau
he/him/his (Why Pronouns Matter)

[Kenton Varda]

I don't use the term "object capability" all that often mostly because I try to use words that the audience knows, and not enough people know it.

But I did make a point of saying that Cap'n Web implements an object-capability model in my blog post on Monday, and then immediately followed it with a list of tangible benefits (not just about security, but expressivity). As far as I can tell, it worked well: people understand this means "this is different from normal RPC systems" and then they see the benefits, and everyone seems universally excited. Well, except one or two trolls on Hacker News who brought up CORBA.

-Kenton

[John Kemp]

El 09/26/25 a las 14:34, Charlie Landau escribió:

> On 9/26/25 10:53 AM, John Kemp wrote:
>> Google Doc and Dropbox sharing links, ... were all using ocaps
> Sharing-links that are text strings can be published to the world, even
> if you don't have a capability to the world, making confinement
> impossible. Not what I want in a capability system.

1. This is why I always hesitate to use the term "object capability"
2. In my experience, many (most?) URLs are _not_ known, or published to
"the world".

Regards, John

>
> --
> Charlie Landau
> he/him/his (Why Pronouns Matter <https://www.mypronouns.org/>)

>
> --
> You received this message because you are subscribed to the Google

> Groups "cap-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send

> an email to cap-talk+u...@googlegroups.com <mailto:cap-
> talk+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/cap-
> talk/5817581f-b262-45e2-b0df-368658122a9c%40charlielandau.com <https://
> groups.google.com/d/msgid/cap-talk/5817581f-b262-45e2-
> b0df-368658122a9c%40charlielandau.com?utm_medium=email&utm_source=footer>.

[Alan Karp]

On Fri, Sep 26, 2025 at 9:57 AM Kenton Varda <temp...@gmail.com> wrote:

To be fair capabilities are used in Cloudflare Workers because I designed it that way. ;)

But everyone is pretty happy with the result.

Actually, though, capabilities are everywhere. Android's Binder and Chrome's Mojo (foundational parts of these respective systems) are capability systems. I'd argue capabilities are actually very common in successful systems, they just aren't always labeled as such and aren't always "pure".

What's "impure" about them? 

--------------
Alan Karp

[Alan Karp]

I've used Google Docs links as an example of capabilities, but they don't properly support attenuated delegation.  

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/57a35174-efc3-4a6e-b522-4dfa6f1f9c7a%40gmail.com.

[Jonathan S. Shapiro]

On Fri, Sep 26, 2025 at 1:26 PM Alan Karp <alan...@gmail.com> wrote:

I've used Google Docs links as an example of capabilities, but they don't properly support attenuated delegation.

That's a criteria that does not seem (to me) intrinsic to capability systems, mainly because there are examples of systems that don't support attenuating operations at all. I suspect you mean that attenuation, where implemented, must be implemented correctly. It may be that a better way to capture this lies in the "no rights amplification" requirement.

One property that really must hold is that there are no rights-amplifying operations (that is: operations by which the authority of a capability can be increased). I'm actually not aware of any system that gets this right in the naive sense, and I'm not aware that any system other than the KeyKOS family gets this right in the more liberal sense - though it's mildly interesting how the KeyKOS family dodges the bullet.

There are two and a half examples of rights amplification in the KeyKOS heritage::

1. The first supports memory fault handlers, in which a segment capability is "upgraded" to its corresponding node capability in the message sent to the fault handler when a memory fault occurs. While common practice, it isn't guaranteed that the memory fault handler fabricated the faulting memory region, so we cannot assume that it had prior access to that node capability. But (a) whoever did create the memory region had the full-strength capability, and (b) they had the ability to set controls that prevent this upgrade behavior if it wasn't desired. Ultimately this is a form of "not amplifying by virtue of demonstrated intention at construction." The main objection to it, I think, is that the current way of stating intention isn't "default safe." And now that I've recognized that I'm going to look to see if there's a more straightforward way to address that in the Coyotos GPT structure.
2. The second allows constructors to deconstruct their yields exactly if they can prove that they created the yield in the first place. As the creator, they could alternatively store a map, so there's a dodgy argument that nothing is amplified in the context where this occurs. Unlike the segment example, this relies on the constructor retaining its brand capability and holding it confidential, which is part of why the constructor is part of the system's primordial TCB.
3. The space bank holds a "range capability" that is used both to create and to destroy objects. Given that it's the range capability, it isn't clear that there is any amplification here at all, but if so a hypothetical map is possible. On top of which, the space bank is part of the system's primordial TCB.

Each of these is a fairly critical optimization whose justification is predicated on context of use. That said, each time a context-dependent optimization of this kind gets introduced, it becomes necessary to prove that the justifying excuse is correct. Because if it isn't you've lost the security induction for the system altogether.

Lest I forget, something like the "weak" access restriction on memory objects is required in oCap systems to sustain confinement and/or isolation. In seL4, something analogous is accomplished by preventing capability transmission in most messages that cross enclave boundaries.

Jonathan

[Alan Karp]

I don't understand what you mean when you say, "One property that really must hold is that there are no rights-amplifying operations (that is: operations by which the authority of a capability can be increased). I'm actually not aware of any system that gets this right in the naive sense,"

All the certificate capability systems I know of have this property as do the unguessable URL systems, such as Waterken and Google docs.  The same is true of OAuth access tokens, although I don't remember if the spec on token exchange says not to increase the scope.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNr9oEBzLNKvQ3mtHk11fPe0zSAoLO_kj2Uudnba6zSjQ%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 11:34 AM Charlie Landau <cha...@charlielandau.com> wrote:

On 9/26/25 10:53 AM, John Kemp wrote:

Google Doc and Dropbox sharing links, ... were all using ocaps

Sharing-links that are text strings can be published to the world, even if you don't have a capability to the world, making confinement impossible. Not what I want in a capability system.

E, Waterken, and Endo all support offline caps i.e., cap-as-strings, and confinement. The trick is a strong distinction between offline caps vs ocaps. And to reify the ability to convert between them as a capability that can be denied. Then, a necessary condition to confine code is to deny that code this conversion cap. IIRC, that's what all these systems do.

Google docs and Dropbox only have offline caps because there are no ocap systems at the endpoints.

Please read http://erights.org/elib/capability/dist-confine.html . It is short but explains a lot.

 

--
Charlie Landau
he/him/his (Why Pronouns Matter)

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/5817581f-b262-45e2-b0df-368658122a9c%40charlielandau.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 11:36 AM Kenton Varda <temp...@gmail.com> wrote:

I don't use the term "object capability" all that often mostly because I try to use words that the audience knows, and not enough people know it.

But I did make a point of saying that Cap'n Web implements an object-capability model in my blog post on Monday, and then immediately followed it with a list of tangible benefits (not just about security, but expressivity). As far as I can tell, it worked well: people understand this means "this is different from normal RPC systems" and then they see the benefits, and everyone seems universally excited. Well, except one or two trolls on Hacker News who brought up CORBA.

Sometimes I like to say that distributed object systems are only possible again because most of the people who remember CORBA have retired ;)

 

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/friam/CAJaLmO4BWz8AAVLCLq-Ljwq5i26_AiFg%3D6ZKkK2xM_hH2QVskw%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 11:41 AM John Kemp <stable.p...@gmail.com> wrote:

El 09/26/25 a las 14:34, Charlie Landau escribió:
> On 9/26/25 10:53 AM, John Kemp wrote:
>> Google Doc and Dropbox sharing links, ... were all using ocaps
> Sharing-links that are text strings can be published to the world, even
> if you don't have a capability to the world, making confinement
> impossible. Not what I want in a capability system.

1. This is why I always hesitate to use the term "object capability"
2. In my experience, many (most?) URLs are _not_ known, or published to
"the world".

I do not use "ocap" when referring to these strings, precisely because of the inability to confine them. E does have "SturdyRefs" which opaquely encapsulates the same info as an offline cap, but also provides the power to turn this one designator into a genuine ocap. By the logic of http://erights.org/elib/capability/dist-confine.html , these *can* be safely given to confined subsystems.

 

Regards, John

>
> --
> Charlie Landau
> he/him/his (Why Pronouns Matter <https://www.mypronouns.org/>)
>
> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cap-talk+u...@googlegroups.com <mailto:cap-
> talk+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/cap-
> talk/5817581f-b262-45e2-b0df-368658122a9c%40charlielandau.com <https://
> groups.google.com/d/msgid/cap-talk/5817581f-b262-45e2-
> b0df-368658122a9c%40charlielandau.com?utm_medium=email&utm_source=footer>.

--
Independent Security Architect
t: +1.413.645.4169
e: stable.p...@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/79cd9763-fe57-428c-b4a8-26397fa7e562%40gmail.com.

[Mark S. Miller]

Kenton, I don't know if you purposely switched from "ocap" to "capability" in making this statement, but I'm glad you did. I coined "object-capability" (ocap) precisely because the term "capability" historically had been stretched so much it became squishy. But leaving aside horrors such as "Linux capabilities", most still share much of the essential idea.* I would agree these other systems are "capability" systems. So when I see "aren't always 'pure'", I read that as "aren't always ocap" which I agree with. Is that a reasonably accurate interpretation?

*Also "reference capabilities". Pony, Fearless, Wyvern have both reference caps and ocaps. Rust, I would argue, has reference caps and a subset of ocaps, even if they call them something different.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1YMWxzhuRy7%2BxJrKDzWDa0q3%2BSUq%2ByHhKeC7Kz2iUt%2Bw%40mail.gmail.com.

[Mark S. Miller]

Every ocap system I've been involved with has had rights amplification. This started for me with sealer/unsealer pairs from James Morris' 1968 ocap Gedanken language. I essentially copied Morris' design into E.

But every system in which an ocap has a testable unforgeable fresh identity (all of them, but not for all ocaps), and some sort of unenumerable key-value weakmap in which these ocaps can be used as keys, supports rights amplification. To get the value associated with a key in a given weakmap, you need the key and the weakmap. The MintMaker needs rights amplification. E's MintMaker does that with sealer/unsealers. All modern MintMaker, including the basis for currency handling in ERTP on the Agoric blockchain, uses weakmaps to do the same rights amplification, which works much better than sealer/unsealer.

Anytime I do rights amplification by any of these means, I know I've introduced a Confused Deputy hazard. But unlike most such hazards, we can successfully review systems like MintMakers for absence of actual confused deputy vulnerabilities.

I suspect none of this is in tension with what you meant, in that systems that are unsafe in the ways you mean are not because of these forms of rights amplification. Would it be fair to call their problem "rights escalation"?

On Fri, Sep 26, 2025 at 3:04 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNr9oEBzLNKvQ3mtHk11fPe0zSAoLO_kj2Uudnba6zSjQ%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 3:04 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Coming from programming languages, and given the relevance of things like weakmaps to this discussion, I'd like to double check: By "weak" here, you mean something like "sensory", right? Why did you turn away from the "sensory" term?

 

Jonathan

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNr9oEBzLNKvQ3mtHk11fPe0zSAoLO_kj2Uudnba6zSjQ%40mail.gmail.com.

[Alan Karp]

I read Jonathan's use of "rights amplification" differently.  He said, "operations by which the authority of a capability can be increased."  Note the use of the word "a" in his definition.  I think that fit the examples he gave.  Rights amplification as you are using it requires a second capability.  Which one did you mean, Jonathan?

I've long had a problem with the term "rights amplification."  People learning about capabilities think it means turning a read capability into a read/write capability.  "Rights escalation" doesn't do it for me either.  At today's friam, I proposed "rights combination" to a bunch of Bronx cheers.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7ZfPtEqf_QzbKNogXzFvC-fZc_xAfbPP%3D1ZFyEvtw22Q%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 4:07 PM Alan Karp <alan...@gmail.com> wrote:

I read Jonathan's use of "rights amplification" differently.  He said, "operations by which the authority of a capability can be increased."  Note the use of the word "a" in his definition.  I think that fit the examples he gave.  Rights amplification as you are using it requires a second capability.

Yes. I define the effect of bringing the two together as "rights amplification" when the authority the combination provides is greater than the sum of the authority each individually provides. Classic can and can-opener. If Alice on the west coast is talking over zoom to Bob on the east coast, and Alice has only a can, and Bob has only a can opener, the Alice+Bob system only has the sum of the authority each individually provides. This Alice+Bob system still cannot get the Tuna.

This is another reason to distinguish ocaps from offline caps (or data caps). A data-only channel is always sufficient to "bring these together". The Alice+Bob system gets the Tuna.

 

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3dr1ZZfGL5iDA7Auk21%3DuPW6Gy%3DFbCQ_ADd6yprstapQ%40mail.gmail.com.

[Matt Rice]

On Fri, Sep 26, 2025 at 10:41 PM 'Mark S. Miller' via cap-talk
<cap-...@googlegroups.com> wrote:
>
>
>
> On Fri, Sep 26, 2025 at 1:19 PM Alan Karp <alan...@gmail.com> wrote:
>>
>> On Fri, Sep 26, 2025 at 9:57 AM Kenton Varda <temp...@gmail.com> wrote:
>>>
>>> To be fair capabilities are used in Cloudflare Workers because I designed it that way. ;)
>>>
>>> But everyone is pretty happy with the result.
>>>
>>> Actually, though, capabilities are everywhere. Android's Binder and Chrome's Mojo (foundational parts of these respective systems) are capability systems. I'd argue capabilities are actually very common in successful systems, they just aren't always labeled as such and aren't always "pure".
>>
>>
>> What's "impure" about them?
>
>
> Kenton, I don't know if you purposely switched from "ocap" to "capability" in making this statement, but I'm glad you did. I coined "object-capability" (ocap) precisely because the term "capability" historically had been stretched so much it became squishy. But leaving aside horrors such as "Linux capabilities", most still share much of the essential idea.* I would agree these other systems are "capability" systems. So when I see "aren't always 'pure'", I read that as "aren't always ocap" which I agree with. Is that a reasonably accurate interpretation?
>

Hopefully I recall correctly and he will clarify, but I believe that
in the past Kenton has said that he rejects that these other horrors
are capabilities,
instead lumping them together as various kinds of "crapabilities" like
"posix crapabilities". Another term which has gone around for projects
like capsicum and cheri is
hybrid capability system, where not all authority is necessarily
isolated to capabilities, not being familiar with binder or mojo I had
assumed by impure that he was also including these hybrids.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 4:30 PM Matt Rice <rat...@gmail.com> wrote:

On Fri, Sep 26, 2025 at 10:41 PM 'Mark S. Miller' via cap-talk
<cap-...@googlegroups.com> wrote:
>
>
>
> On Fri, Sep 26, 2025 at 1:19 PM Alan Karp <alan...@gmail.com> wrote:
>>
>> On Fri, Sep 26, 2025 at 9:57 AM Kenton Varda <temp...@gmail.com> wrote:
>>>
>>> To be fair capabilities are used in Cloudflare Workers because I designed it that way. ;)
>>>
>>> But everyone is pretty happy with the result.
>>>
>>> Actually, though, capabilities are everywhere. Android's Binder and Chrome's Mojo (foundational parts of these respective systems) are capability systems. I'd argue capabilities are actually very common in successful systems, they just aren't always labeled as such and aren't always "pure".
>>
>>
>> What's "impure" about them?
>
>
> Kenton, I don't know if you purposely switched from "ocap" to "capability" in making this statement, but I'm glad you did. I coined "object-capability" (ocap) precisely because the term "capability" historically had been stretched so much it became squishy. But leaving aside horrors such as "Linux capabilities", most still share much of the essential idea.* I would agree these other systems are "capability" systems. So when I see "aren't always 'pure'", I read that as "aren't always ocap" which I agree with. Is that a reasonably accurate interpretation?
>

Hopefully I recall correctly and he will clarify, but I believe that
in the past Kenton has said that he rejects that these other horrors
are capabilities,
instead lumping them together as various kinds of "crapabilities" like
"posix crapabilities". Another term which has gone around for projects
like capsicum and cheri is
hybrid capability system, where not all authority is necessarily
isolated to capabilities,

I like it.

So by this definition, Java, JavaScript, and Scheme are hybrid capability systems? I'd even be happy to call them hybrid ocap systems. Whereas Joe-E, HardenedJS, and W7 are simply ocap systems. Sounds good to me.

 

not being familiar with binder or mojo I had
assumed by impure that he was also including these hybrids.

> *Also "reference capabilities". Pony, Fearless, Wyvern have both reference caps and ocaps. Rust, I would argue, has reference caps and a subset of ocaps, even if they call them something different.
>
>
>>
>> --------------
>> Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFqF6wL2HqLyUjCnyCW1fR-RgNa0Um3G2rjagn3xmWKv0A%40mail.gmail.com.

[Mark S. Miller]

Unix with Unix Domain Sockets is also a hybrid capability system, with file descriptors as the capabilities. File descriptors in OSes and memory-safe object references in PL are by far the most familiar existing uses of ocaps in hybrid ocap systems. In both cases, we all like them because of their capability-nature.

As Norm pointed out, an encryption+signing keys pair in an asymmetric crypto (aka public key crypto) system are offline/data caps, designating the counterparty that knows and uses the corresponding decryption+signature-verification key pair.

So yes, capabilities are everywhere.

[Jonathan S. Shapiro]

On Fri, Sep 26, 2025 at 3:14 PM Alan Karp <alan...@gmail.com> wrote:

I don't understand what you mean when you say, "One property that really must hold is that there are no rights-amplifying operations (that is: operations by which the authority of a capability can be increased). I'm actually not aware of any system that gets this right in the naive sense,"

All the certificate capability systems I know of have this property as do the unguessable URL systems, such as Waterken and Google docs.  The same is true of OAuth access tokens, although I don't remember if the spec on token exchange says not to increase the scope.

I'm much less familiar with the cryptographic capability systems, so I probably overstated the case.

OAuth does provide for increased scopes, but I'd have to dig in to the spec to reconstruct where that's allowed.

[Mark S. Miller]

Asymmetric (aka public) key systems are also rights amplification systems, in that you need both the ciphertext and the decryption key to access the plaintext.

[Jonathan S. Shapiro]

On Fri, Sep 26, 2025 at 5:03 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Unix with Unix Domain Sockets is also a hybrid capability system with file descriptors as the capabilities.

In some implementations, the pipe subsystem also supports this kind of transfer. Traditionally this would have involved the I_SENDFD ioctl, but it wouldn't surprise me if there are more recent, cleaner interfaces.

But leaving aside horrors such as "Linux capabilities"...

Yeah. That - or more precisely, POSIX capabilities - was a horrible misappropriation of a term. Some of the folks involved were explicit that the appropriation was intentional, and in their view OK because "nobody uses the term capability in that other way anymore."

 

Another term which has gone around for projects
like capsicum and cheri is
hybrid capability system, where not all authority is necessarily
isolated to capabilities,

That term is almost 50 years older than either of those systems.

In most cases, the hybrid systems are ones in which holding a capability is necessary but not sufficient. In the ones I'm familiar with, permissions are determined based on the intersection of what the two systems permit. Or put another way: the hybrid system can reduce what the capability system on its own might allow.

Jonathan

[Jonathan S. Shapiro]

On Fri, Sep 26, 2025 at 5:08 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Asymmetric (aka public) key systems are also rights amplification systems, in that you need both the ciphertext and the decryption key to access the plaintext.

Hmm. Wouldn't that depend on the distribution mechanism used for the private key?

A rough analogy for this is a domain that holds text. One oCap to store text into the domain, another to retrieve it. No cryptography involved. This leads me to ponder whether the fact that the ciphertext is a cipher is truly relevant. It seems to me that the functional difference between the two is that transmission of the "read"-authorizing thing is not governed by channels that understand the difference between data payload and authority payload.

There's also no object designation here. The key pair isn't specific to a particular text, which leaves me uncertain that ocap intuitions actually apply in this example.

I'm probably not thinking about this right.

Jonathan

[Mark S. Miller]

Yes, that's correct. System38 aka AS/400 is a hybrid capability system as the term was used. The difference with "where not all authority is necessarily isolated to capabilities" is the difference between intersection and union. I should have noticed, since I put a lot of thought into intersection style hybrid cap systems. Their contrast with Horton is illuminating.

That said, I think it may be worth coining a term for the union style "where not all authority is necessarily isolated to capabilities" systems, since they are everywhere and familiar to everyone, and are in fact examples of many of the virtues of caps and ocaps.

 

Jonathan

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QM5ZctEYzpEU08WsVpn4es%2BaCd2WKNSFYXmi8XcJnWV7A%40mail.gmail.com.

[Mark S. Miller]

You are. That's why these are not examples of ocap rights amplification. The important object designation here would be if the plaintext were another offline/data cap. Given that, I would still say it is an example of rights amplification. In most offline/data cap systems, some distribution is assumed without further mechanism. 

For an ocap system, Morris' (and E's) sealer/unsealer pairs are a perfect analogy with no crypto, and without threatening confinement.

 

Jonathan

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMGrSTy3hKZX-KbGedn2VvhYd9HavrhCu8D2kWSFjVOEA%40mail.gmail.com.

[Mark S. Miller]

On Fri, Sep 26, 2025 at 5:49 PM Mark S. Miller <ma...@agoric.com> wrote:

On Fri, Sep 26, 2025 at 5:27 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

On Fri, Sep 26, 2025 at 5:08 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Asymmetric (aka public) key systems are also rights amplification systems, in that you need both the ciphertext and the decryption key to access the plaintext.

Hmm. Wouldn't that depend on the distribution mechanism used for the private key?

A rough analogy for this is a domain that holds text. One oCap to store text into the domain, another to retrieve it. No cryptography involved. This leads me to ponder whether the fact that the ciphertext is a cipher is truly relevant. It seems to me that the functional difference between the two is that transmission of the "read"-authorizing thing is not governed by channels that understand the difference between data payload and authority payload.

There's also no object designation here. The key pair isn't specific to a particular text, which leaves me uncertain that ocap intuitions actually apply in this example.

I'm probably not thinking about this right.

You are.

Sorry, I misread. I meant you are mostly thinking about this right.

[William ML Leslie]

On Sat, 27 Sept 2025 at 10:03, 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

Unix with Unix Domain Sockets is also a hybrid capability system, with file descriptors as the capabilities. File descriptors in OSes and memory-safe object references in PL are by far the most familiar existing uses of ocaps in hybrid ocap systems. In both cases, we all like them because of their capability-nature.

My favourite hybrid of this sort is Linux' modern graphics stack, version 3 of the Direct Rendering Infrastructure.  Unprivileged applications can create their own DRI render node and pass the descriptor to the display server to be rendered.  There's still legacy APIs and lots of ambient authority when you look at processes as a whole, but I find it comforting that people have been tending toward capabilities here for managing GPU resources and screen space.

--

William ML Leslie

[Jonathan S. Shapiro]

On Fri, Sep 26, 2025 at 5:51 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

On Fri, Sep 26, 2025 at 5:27 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

I'm probably not thinking about this right.

You are.

Sorry, I misread. I meant you are mostly thinking about this right.

:-) Well, that seems more consistent with my sendings of late. Apologies that it's taking some time to get back in the groove.

Jonathan

[Ben Laurie]

On Fri, 26 Sept 2025 at 18:53, John Kemp <stable.p...@gmail.com> wrote:

El 09/26/25 a las 12:57, Kenton Varda escribió:

> Actually, though, capabilities are everywhere. Android's Binder and
> Chrome's Mojo (foundational parts of these respective systems) are
> capability systems. I'd argue capabilities are actually very common in
> successful systems, they just aren't always labeled as such and aren't
> always "pure".

Back in the days when I wrote this in the W3C TAG:
https://www.w3.org/2001/tag/2010/06/01-cross-domain.html related to UMP
vs CORS, I was an enthusiastic designer of capability systems while at
Nokia, but I avoided direct use of the term "object capability."

At that time, Google Doc and Dropbox sharing links, Second Life use of
capability URLs and quite a few others, along with Google's Caja project
were all using ocaps in deployed systems around that time.

I was told Second Life uses capabilities very heavily internally, too. 

Jeni Tennison later wrote a nice document about best practices for
capability URLs: https://www.w3.org/2001/tag/doc/capability-urls/ and
https://w3ctag.github.io/presentations/reveal/capability-urls.html

Worth noting that Jonathan Rees and Dan Connolly were also on the TAG at
this time.

- johnk

--
Independent Security Architect
t: +1.413.645.4169
e: stable.p...@gmail.com

https://www.linkedin.com/in/johnk-am9obmsk/
https://github.com/frumioj

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/57a35174-efc3-4a6e-b522-4dfa6f1f9c7a%40gmail.com.

[Matt Rice]

On Sat, Sep 27, 2025 at 12:39 AM 'Mark S. Miller' via cap-talk

<cap-...@googlegroups.com> wrote:
>
>
>
> On Fri, Sep 26, 2025 at 5:12 PM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:
>>
>> On Fri, Sep 26, 2025 at 5:03 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:
>>>
>>> Unix with Unix Domain Sockets is also a hybrid capability system with file descriptors as the capabilities.
>>
>>
>> In some implementations, the pipe subsystem also supports this kind of transfer. Traditionally this would have involved the I_SENDFD ioctl, but it wouldn't surprise me if there are more recent, cleaner interfaces.
>>
>>>>> But leaving aside horrors such as "Linux capabilities"...
>>
>>
>> Yeah. That - or more precisely, POSIX capabilities - was a horrible misappropriation of a term. Some of the folks involved were explicit that the appropriation was intentional, and in their view OK because "nobody uses the term capability in that other way anymore."
>>
>>>>>
>>>>> Another term which has gone around for projects
>>>>> like capsicum and cheri is
>>>>> hybrid capability system, where not all authority is necessarily
>>>>> isolated to capabilities,
>>
>>
>> That term is almost 50 years older than either of those systems.
>>
>> In most cases, the hybrid systems are ones in which holding a capability is necessary but not sufficient. In the ones I'm familiar with, permissions are determined based on the intersection of what the two systems permit. Or put another way: the hybrid system can reduce what the capability system on its own might allow.
>
>
> Yes, that's correct. System38 aka AS/400 is a hybrid capability system as the term was used. The difference with "where not all authority is necessarily isolated to capabilities" is the difference between intersection and union. I should have noticed, since I put a lot of thought into intersection style hybrid cap systems. Their contrast with Horton is illuminating.
>
> That said, I think it may be worth coining a term for the union style "where not all authority is necessarily isolated to capabilities" systems, since they are everywhere and familiar to everyone, and are in fact examples of many of the virtues of caps and ocaps.
>

Thanks both for correcting my usage of the hybrid terminology, this
intersectional point which weakens capabilities is one I hadn't
considered.
The other set operator to consider here would be disjoint. E.g. I
could imagine something like a "disjoint hybrid capability system" to
be one "where not all authority is necessarily isolated to
capabilities and the set of authorities between capabilities and
non-capabilities does not overlap"

That said, a purist at heart I mostly use hybrid systems as a means to
filter out things I don't particularly care too much about.
So I'm honestly probably not going to be much help in coining a good
term for them.

[Tony Arcieri]

On Fri, Sep 26, 2025 at 4:41 PM 'Mark S. Miller' via cap-talk <cap-...@googlegroups.com> wrote:

But leaving aside horrors such as "Linux capabilities", most still share much of the essential idea.* I would agree these other systems are "capability" systems. So when I see "aren't always 'pure'", I read that as "aren't always ocap" which I agree with.

At least there was Capsicum, which in turn influenced CloudABI, which in turn influenced WASI

--

Tony Arcieri