Fwd: Capability Systems and Concurrency

6 of 6


---------- Forwarded message ----------
From: Kris Zyp <[email protected]>
Date: Mon, Mar 3, 2008 at 7:49 PM
Subject: Re: Capability Systems and Concurrency
To: Mark Miller <[email protected]>
Cc: Kevin Reid <[email protected]>


Thanks for explanations, I understand much better now. A few other comments
 inline:



 >>  think the persistence of JavaScript functions in object graphs would be
 >>  particularly interesting to intersect with capability-based security.
 >
 > Indeed! One of the issues the Caja project is currently wrestling with
 > is what to do about persistence.
 Yes, I would love to collaborate on some of this stuff, I will join the Caja
 discussion group, so I can start listening in on the discussions.
 Interestingly, AFAIK, Caja and Persevere are the two most extensive
 projects/efforts in JavaScript translation. Persevere does extensive
 rewriting of property access in order to monitor property changes to achieve
 orthogonal persistence, and detect lazy loaded property access, and does
 translation to facilitate continuations (based on Narrative
 JavaScript/JavaScript Strands) to load persistent properties with
 asynchronous XHR transparently. And from what I understand Caja does some
 similar property access rewriting.


 >
 >
 >> One
 >>  could allow less-trusted sources to store functions, and their
 >> capabilities
 >>  could be appropriately limited.
 >
 > I don't understand this. Can you expand?
 This is really no different than the general goal of capability-based
 system, untrusted code should only be given as much capability as necessary.
 With my project the untrusted code can simply be persisted as well. In
 Persevere, I have adopted a persistence strategy similar to that used by
 some Smalltalk and Lisp implementations, where application data (objects)
 and program code (functions) are not differentiated in their ability to be
 persisted. Basically any JavaScript object can be fully persisted (prototype
 chains, methods, et al) into the central persistent store on the server.
 Persevere also implements security that can be defined for any set of
 objects, and a set of objects can locally managed by user/group without
 requiring access to rest of the persisted object graph. However, I can't
 truly allow full access to persisting functions to users that have limited
 access, because normal JavaScript essentially has unmitigated access to
 everything; unrestrained JavaScript can easily escalate it's own
 priviledges. Right now, I only allow full system-wide superusers access to
 persisting functions, due to this security concern. However, with JavaScript
 with capability-based limits as in Caja or ADsafe, I could safely allow
 functions to be persisted as long as they are properly limited in their
 ability.


 > May I forward this correspondence to e-lang
 > <http://www.eros-os.org/mailman/listinfo/e-lang> and
 > google-caja-discuss
 > <http://groups.google.com/group/google-caja-discuss>? Thanks.
 Yes, absolutely, consider my text public domain as well ;).
 Thanks again,
 Kris




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

    Cheers,
    --MarkM