[cap-talk] Confused Deputies in Capability Systems

Toby Murray toby.murray at comlab.ox.ac.uk
Tue Feb 10 10:53:17 EST 2009


On Tue, 2009-02-10 at 14:26 +0100, Marcus Brinkmann wrote:
>  A confused deputy can also arise in capability systems
> if a capability is designated by a symbolic name rather than a capability.
> Any service that translates names to capabilities can potentially have a
> confused deputy problem.

Agreed.

> The capability community has not yet demonstrated
> that they can build interesting real world systems that do not rely on such
> services.

Let me expand on this in the hope that I take your meaning correctly.
Any capability system necessarily must handle
non-authority-carrying-designations that come from external services
etc. A good example would be a web browser running atop a
capability-based OS that handles URLs. A network service might map each
URL into a capability to a Stream object that contains the results of an
HTTP GET sent to that URL, for example. Doing so would turn the network
service into a confused deputy. 

I'm having difficulty seeing how to eliminate the confused deputy here.
One approach would be to rewrite URLs contained in the Streams to
instead be some capability representation (e.g. a small positive integer
giving an index into a CList or whatever). This fails to work, however,
when URLs are constructed by executable code, e.g. JavaScript. So the
problem is intractable in general. 

Is that the sort of thing you had in mind?

In that case, I'd agree and argue that
non-authority-carrying-designations are somewhat poisonous when trying
to avoid confused deputies.

Cheers

Toby


More information about the cap-talk mailing list