SES prototype mostly working on latest Minefield, WebKit, and Chromium betas
On Mon, Aug 30, 2010 at 3:12 PM, Mark S. Miller <erights at google.com> wrote:
May crash your browser or page: es-lab.googlecode.com/svn/trunk/src/ses/index.html
es-lab.googlecode.com/svn/trunk/src/ses/index.htmlSources at code.google.com/p/es-lab/source/browse/trunk/src/ses
This has only been lightly tested and should not be relied on to have any security properties yet.
The claim I working up to is that, on a securable ES5 implementation (< code.google.com/p/es-lab/wiki/SecureableES5>), these scripts create an SES environment (code.google.com/p/es-lab/wiki/SecureEcmaScript) implementing the object-capability security model and solving the safe mashup problem (code.google.com/p/es-lab/wiki/SafeMashups).
Unfortunately, since there is not yet any full browser-based implementations of ES5, the present state of these scripts have various compromises that preserves their functionality but loses security. These are documented in the various files under "KLUDGE SWITCHES". With these kludges, from extremely light testing, it seems to work on the latest
- Firefox Minefield 4.0b5pre,
- Safari WebKit Nightly Version 5.0.1 (5533.17.8, r66356), and
- Chromium beta 6.0.490.0 (3135). As soon as I get my VMWare installation fixed, I'll test on the IE9 preview as well. Opera 10.61.8429 does not yet implement Object.getOwnPropertyNames, so I can't even test there.
This implementation of SES cannot run on ES5/3 (< code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5>) as is because of the lack of a client side eval. The current plan is to support SES5/3 directly, rather than porting these scripts to run on ES5/3.
Like ADsafe, this is all implemented by a lightweight client-side library, with no server-side support need. Minified, the total size of the download comes in under 5k.
Minified and gzipped that is.
May crash your browser or page: es-lab.googlecode.com/svn/trunk/src/ses/index.html
es-lab.googlecode.com/svn/trunk/src/ses/index.htmlSources at
code.google.com/p/es-lab/source/browse/trunk/src/ses
This has only been lightly tested and should not be relied on to have any security properties yet.
The claim I working up to is that, on a securable ES5 implementation (< code.google.com/p/es-lab/wiki/SecureableES5>), these scripts create
an SES environment (code.google.com/p/es-lab/wiki/SecureEcmaScript)
implementing the object-capability security model and solving the safe mashup problem (code.google.com/p/es-lab/wiki/SafeMashups).
Unfortunately, since there is not yet any full browser-based implementations of ES5, the present state of these scripts have various compromises that preserves their functionality but loses security. These are documented in the various files under "KLUDGE SWITCHES". With these kludges, from extremely light testing, it seems to work on the latest
This implementation of SES cannot run on ES5/3 (< code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5>)
as is because of the lack of a client side eval. The current plan is to support SES5/3 directly, rather than porting these scripts to run on ES5/3.
Like ADsafe, this is all implemented by a lightweight client-side library, with no server-side support need. Minified, the total size of the download comes in under 5k. Because it does not parse or transform code, aside from calls to "eval" or the "Function" constructor, the untrusted code runs at full speed and with no code expansion. Due to various transient problems, the safe eval is currently called "eval2" and "eval" remains unsafe.
Interestingly, this library contains a surprising faithful emulation of WeakMaps on ES5 browsers that don't support WeakMaps directly (< code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js#326
May crash your browser or page: http://es-lab.googlecode.com/svn/trunk/src/ses/index.html <http://es-lab.googlecode.com/svn/trunk/src/ses/index.html>Sources at http://code.google.com/p/es-lab/source/browse/trunk/src/ses/ This has only been lightly tested and should **not** be relied on to have any security properties yet. The claim I working up to is that, on a securable ES5 implementation (< http://code.google.com/p/es-lab/wiki/SecureableES5>), these scripts create an SES environment (<http://code.google.com/p/es-lab/wiki/SecureEcmaScript>) implementing the object-capability security model and solving the safe mashup problem (<http://code.google.com/p/es-lab/wiki/SafeMashups>). Unfortunately, since there is not yet any full browser-based implementations of ES5, the present state of these scripts have various compromises that preserves their functionality but loses security. These are documented in the various files under "KLUDGE SWITCHES". With these kludges, from *extremely* light testing, it seems to work on the latest * Firefox Minefield 4.0b5pre, * Safari WebKit Nightly Version 5.0.1 (5533.17.8, r66356), and * Chromium beta 6.0.490.0 (3135). As soon as I get my VMWare installation fixed, I'll test on the IE9 preview as well. Opera 10.61.8429 does not yet implement Object.getOwnPropertyNames, so I can't even test there. This implementation of SES cannot run on ES5/3 (< http://code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5>) as is because of the lack of a client side eval. The current plan is to support SES5/3 directly, rather than porting these scripts to run on ES5/3. Like ADsafe, this is all implemented by a lightweight client-side library, with no server-side support need. Minified, the total size of the download comes in under 5k. Because it does not parse or transform code, aside from calls to "eval" or the "Function" constructor, the untrusted code runs at full speed and with no code expansion. Due to various transient problems, the safe eval is currently called "eval2" and "eval" remains unsafe. Interestingly, this library contains a surprising faithful emulation of WeakMaps on ES5 browsers that don't support WeakMaps directly (< http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js#326 >). -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100830/e93096d8/attachment.html>