[cap-talk] Old talk & interview on ES5, Caja, SES now up

[Mark S. Miller]

http://www.infoq.com/presentations/From-E-to-EcmaScript

http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security

Enjoy!

--
    Cheers,
    --MarkM

[Rob Meijer]

On Sat, February 26, 2011 01:12, Mark S. Miller wrote:
> http://www.infoq.com/presentations/From-E-to-EcmaScript
> http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security

Mark, in the second talk at about 14:20 you speak about a new
interposition patterns 'proxies' framework that will be shipped as part of
FF4. This sounds very interesting indeed. Is there already any
documentation available on this?

_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[Viswanathan, Kapaleeswaran (HP Labs India)]

Hi Mark:

That was a great talk. Thanks for sharing the links.

I have the following queries and comments.

1. You mentioned that mechanisms exist so that normal javascript code can interact securely with secure javascript code in ECMAScript 5. Please an you send pointers for the same?

2. Would ECMAScript5 expect current javascript programmers to be retrained? (Is it *something* like a move from C to C++ or from C++ to Java?)

3. What is the source for initSES.js? Is it the local machine or a remote server? If it is a remote server, what is the trust assumption? Now, what are the implications on cross-site-script restrictions -- would they be relaxed due to added security features to the Javascript VM?

4. With the arrival of XMPP/BOSH, we would like to work with JSON and XMPP in addition to JSON with REST. XMPP is message passing approach to distributed computing while REST is a RPC like approach. Does ECMAScript 5 somehow prevent non-REST naming and behaviours for Dr. SES?

5. In the "Distributed Secure Currency" slides: should the deposit message from Alice go to the payment purse or to her account purse? I feel that is should go to her account purse because it is not shared with anyone and more trustable than the payment purse, which shall be shared with Bob. I think that a safer and simpler interface can be as follows. This would keep Alice's myPurse to be in full control. The thesis is: Alice should not provide reference to her purse (myPurse) to any object. Note that this is precisely what Bob is doing: he sends the deposit message to his purse and not to the payment purse from Alice. Thus, Bob's purse is protected well.

var paymentP = myPurse!makePurse($10);
bob!buy(....,paymentP);

6. I think that the distributed currency protocol will work only if Alice, Bob, and Bank are all on-line. Is this thinking correct? If yes, I feel that the protocol is an electronic funds transfer system. It is not a currency system, which has an implication for off-line banks.

Regards,
Kapali

Kapali Viswanathan
Research Scientist, HPL India
http://www.hpl.hp.com/people/kapali/

Knowledge may be some model of things that are visible to intellect. Wisdom may be something that includes even those that are invisible.

[Mark S. Miller]

[+tvcutsem, +gal, +brendan]

On Mon, Feb 28, 2011 at 12:47 AM, Rob Meijer <capi...@xs4all.nl> wrote:

On Sat, February 26, 2011 01:12, Mark S. Miller wrote:
> http://www.infoq.com/presentations/From-E-to-EcmaScript
> http://www.infoq.com/interviews/ecmascript-5-caja-retrofitting-security

Mark, in the second talk at about 14:20 you speak about a new
interposition patterns 'proxies' framework that will be shipped as part of
FF4. This sounds very interesting indeed. Is there already any
documentation available on this?

Hi Rob,

Tom (cc'ed) & I presented "Proxies: Design Principles for Robust Object-oriented Intercession APIs" <http://research.google.com/pubs/archive/36574.pdf> at DLS2010, the Dynamic Languages Symposium. I think it's the best place to start.

The precise Proxies spec is evolving and is being maintained at 

http://wiki.ecmascript.org/doku.php?id=harmony:proxies

http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics

http://wiki.ecmascript.org/doku.php?id=harmony:proxy_defaulthandler

Thanks to the efforts of Andreas Gal (cc'ed), Brendan Eich (cc'ed), and others at Mozilla, all of this already works in the Firefox 4 beta and will shortly be shipping, along with all of ES5/strict, in the first FF4 release.

--
    Cheers,
    --MarkM

[Mark S. Miller]

[+google-caja-discuss, +ataly]

On Mon, Feb 28, 2011 at 2:07 AM, Viswanathan, Kapaleeswaran (HP Labs India) <kap...@hp.com> wrote:

Hi Mark:

That was a great talk. Thanks for sharing the links.

I have the following queries and comments.

1. You mentioned that mechanisms exist so that normal javascript code can interact securely with secure javascript code in ECMAScript 5. Please an you send pointers for the same?

I don't remember mentioning that, but it is true. The guarantees that SES (secure EcmaScript) code relies on to defend itself are essentially that

1) Its own frozen records are tamper proof

2) Its own strict functions are statically scoped and really encapsulated

3) Its own primordial objects are transitively frozen

Under EcmaScript 5, if two "frames" (or "same origin frames" in Browser-speak) are in contact, both are ES5, and one is SES built on ES5, the protections of the SES frame from the ES5 frame depend only on ES5 enforcement mechanisms that they are both subject too. Outside the browser, this should all work fine.

Of course, in the browser, this won't quite do because if the frames are same origin then they start with all the same ambient authority. So instead, in the same way we build SES from ES5, we will also build CES5 (confined ES5) from ES5 by having our initialization script take all the same steps as <http://code.google.com/p/es-lab/downloads/detail?name=securing-es5.pdf>, but leaving off the last freezing step providing property #3 above. 

This leaves the CES5 frame in an indefensible state, but that's the tradeoff: either freeze primordials, in which case you can defend youself, or don't, and stay compat with ES5/strict.

Ankur Taly (cc'ed) has a wonderful draft paper in the works formalizing and proving security properties of SES. We'll post this when we can.

 

2. Would ECMAScript5 expect current javascript programmers to be retrained? (Is it *something* like a move from C to C++ or from C++ to Java?)

Not at all. It's more like the change from the cacophony of similar but slightly different pre-ANSI-Cs to ANSI-C. Virtually all old code should just work. Some large number of people regularly browse the web using the FF4 beta which has a complete ES5 implementation and have reported problems that they found. We found one problem that caused a minor spec revision. All the other web compatibility problems, less than 5 IIRC, we've been able to revise by informing the website author.

 

3. What is the source for initSES.js?

The current experiment is at <http://code.google.com/p/es-lab/source/browse/trunk/src/ses/>.

Now that FF4 is in such good shape, we're about to redo this for production as we migrate it into the Caja source tree.

 

Is it the local machine or a remote server?

remote server.

 

If it is a remote server, what is the trust assumption? Now, what are the implications on cross-site-script restrictions -- would they be relaxed due to added security features to the Javascript VM?

All the major browsers other than IE6, yes including even IE7, support doing XHR both within and between origins -- given that the serving site includes an 

    Access-Control-Allow-Origin: *

header in its responses. Combined with SES's confining eval, you can mostly ignore the dreaded same origin policy and just program to object-capability rules. (My upcoming <http://qconlondon.com/london-2011/presentations/show_presentation.jsp?oid=2796> talk will be making these points. I just found out that it will be recorded and posted. But don't wait!)

 

4. With the arrival of XMPP/BOSH, we would like to work with JSON and XMPP in addition to JSON with REST. XMPP is message passing approach to distributed computing while REST is a RPC like approach. Does ECMAScript 5 somehow prevent non-REST naming and behaviours for Dr. SES?

Not at all.

Answers to the rest later.

 

5. In the "Distributed Secure Currency" slides: should the deposit message from Alice go to the payment purse or to her account purse? I feel that is should go to her account purse because it is not shared with anyone and more trustable than the payment purse, which shall be shared with Bob. I think that a safer and simpler interface can be as follows. This would keep Alice's myPurse to be in full control. The thesis is: Alice should not provide reference to her purse (myPurse) to any object. Note that this is precisely what Bob is doing: he sends the deposit message to his purse and not to the payment purse from Alice. Thus, Bob's purse is protected well.

var paymentP = myPurse!makePurse($10);
bob!buy(....,paymentP);

6. I think that the distributed currency protocol will work only if Alice, Bob, and Bank are all on-line. Is this thinking correct? If yes, I feel that the protocol is an electronic funds transfer system. It is not a currency system, which has an implication for off-line banks.

Regards,
Kapali


Kapali Viswanathan
Research Scientist, HPL India
http://www.hpl.hp.com/people/kapali/

Knowledge may be some model of things that are visible to intellect. Wisdom may be something that includes even those that are invisible.

_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

--
    Cheers,
    --MarkM