Re: Capabilities interact nicely with Substructural Types and Reactivity

David Barbour wrote:


è If you know an object isn't stateful - i.e. that it cannot remember its past inputs - then whole classes of security, consistency, and correctness issues can be eliminated. One can prevent time-bomb behaviors that might be resistant to basic testing and analysis. And some implicit optimizations (e.g. parallelization) are feasible.

Got it.  The goal is to guarantee history independent behavior.  I believe that’s less restrictive than fully deterministic behavior.  It sounds like you need that as well.

Is making “new” not be ambient the only solution?  For example, would instantiating a new instance for every invocation achieve the same goal while allowing the object to invoke “new” during that invocation?

________________________
Alan Karp
Principal Scientist
Enterprise Services, Office of the CTO
Hewlett-Packard Company
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp

From: [email protected] [mailto:[email protected]] On Behalf Of David Barbour
Sent: Thursday, September 12, 2013 4:14 PM
To: General discussions concerning capability systems.
Subject: Re: [cap-talk] Capabilities interact nicely with Substructural Types and Reactivity



On Thu, Sep 12, 2013 at 3:40 PM, Karp, Alan H <[email protected]<mailto:[email protected]>> wrote:

==> For example, it may be that we want to forbid the untrusted code from constructing its own local state
OK.  I’ll be the kid in class who asks the question a lot of the other kids are too shy to ask.  What is the value of such a restriction?  It sounds to me like a language that doesn’t allow you to allocate temporary space.  A simple use case would help me understand the requirement.

Temporary space isn't the issue; it's very easy to model temporary space in a pure way.

But controlling *state* is valuable.

If you know an object isn't stateful - i.e. that it cannot remember its past inputs - then whole classes of security, consistency, and correctness issues can be eliminated. One can prevent time-bomb behaviors that might be resistant to basic testing and analysis. And some implicit optimizations (e.g. parallelization) are feasible.

If you can control what state an object uses - i.e. if you provide it through a factory - then it becomes easier to audit that state, plus a bunch of non-security benefits (easier to persist, extend, reset, freeze, rewind, etc. the state).

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk