Fwd: Capability Systems and Concurrency

1 of 6 in a thread. Forwarded with permission.

I'll post a separate notice on google-caja-discuss that this thread is here.

---------- Forwarded message ----------
From: Kris Zyp <[email protected]>
Date: Mon, Jan 28, 2008 at 5:38 PM
Subject: Capability Systems and Concurrency
To: [email protected], douglas-q6680F7qlBP2eFz/[email protected], [email protected]
Cc: Brendan Eich <[email protected]>




As I was thinking about the concerns in securing JavaScript, I
realized that there is significant overlap between the issues of
capability control and safe concurrency. There are differences, but
both capability control and concurrency are primarily concerned with
the handling and control of shared mutable data. References to shared
data can be controlled for the sake of security and for the sake of
safe concurrency. It is interesting to note that the principle working
implementation (Google Gears) of a shared nothing JavaScript process
(vat) that provides secure containment was actually built for the
purpose of concurrency, not security. It just so happens that the
barriers of shared data that are provided by processes/vats bring the
same benefit to security as they do concurrency. And furthermore, the
fine-grained control of security that we have discussed with a secure
capability system (like Caja{ita} or ADSafe) may also have interesting
implications in fine-grained control of shared mutable data in
respects to concurrency. These also share similiar dangers of easily
shared mutable data. With respect to security, information can easily
be leaked or inappropriate interfaces can be exposed. With respect to
concurrency, race conditions and indeterminism can be introduced. It
is seems quite likely that some of the best solutions may apply to
both arenas. Both concurrency and security can utilize mediating
agents to control access to shared data. In capability system, facets
can enforce policies, in concurrency an agent may mediate with
transaction handling.
Many developers I have talked to list security and concurrency as
their top concerns for the future of JavaScript evolution. The
mega-multi-core future of computing also will increasingly demand
concurrency for efficiency. Today's JS concurrency techniques
(conceptual flow resuming through callbacks) are awkward and do not
compose. I realize that security and concurrency certainly do have
substantial differences. However, in discussing and developing
language approaches to securing ECMAScript, I believe we would be
remiss if we did not consider the potential opportunities for
addressing both concurrency and security needs as we look at
techniques and language constraints for controlling shared and mutable
data.
Anyway, I wasn't sure if these discussions were something that would
be discussed some other forum, but just wanted to share my thoughts
with you.
Kris


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM