W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

Re: comment on distributed capabilities

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Fri, 12 Feb 2010 15:28:44 -0800
Message-ID: <4B75E42C.70700@oracle.com>
To: Jonathan Rees <jar@creativecommons.org>
CC: noah_mendelsohn@us.ibm.com, www-tag@w3.org
Yeah!  Better to avoid the C-word!
All the best, Ashok

Jonathan Rees wrote:
> I wanted to recognize and address a point you raised on the call
> yesterday, which is that "distributed capabilities" in the web-key
> sense are not the same as "distributed capabilities" in the sense used
> in some capability systems from the 1970s and 1980s. This is true. I
> think you were referring to systems in which each node in the network
> has a trusted capability kernel that all other nodes can trust. In
> this situation it is possible to some extent to limit copying by
> treating the right to copy as one of the rights controlled by
> capability discipline. Clearly this regime cannot apply in a web
> context where such general trust isn't available: an attacker can just
> run a kernel that ignores the directive not to copy.
> Even where you have trusted kernels, copy prevention may help prevent
> accidental leaks, but it can't really prevent attacks. (Suppose A
> shares a copy-limited capability X with an attacker B. B can share X
> with crony C just by setting up a proxy Y that forwards messages to
> and from X, and sharing Y with C.) Limits on copying only have
> significant effect in the total absence of side communication channels
> that would let B and C communicate, and that kind of confinement is
> too... confining to be useful in the computing contexts we've been
> talking about. Limits on the ability to copy individual capabilities
> have fallen out of favor in the capability community, with attention
> instead being shifted to more general mechanisms for leak control.
> Because of the de-emphasis of confinement and copy limitation, many
> people have been happy to drop the distinction between traditional
> capabilities and string-representable keys and use "capability"
> generically.
> We could argue about what is the proper application of the term
> "capability" but that's not important. I don't think anyone is trying
> to pull a fast one by using the word "capability", but if it's a
> sticking point for you we can agree to say that secret URIs such as
> web-keys are used analogously with capabilities (as opposed to being
> capabilities), or that the secret URI pattern is analogous to the
> capability pattern (as opposed to being an instance of it).
> The question of how easy it is to copy a key, either by mistake or by
> attack or a combination, is relevant and we'll continue talking about
> it.
> Jonathan
Received on Friday, 12 February 2010 23:31:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:05 UTC