On Jan 5, 6:42 am, Mark Seaborn <[email protected]> wrote: > On Mon, Jan 4, 2010 at 2:09 PM, Mathias Wagner > <[email protected]>wrote: > > > Hello, > > > I am a student of computer science and want to implement a "jail" for > > java-script or at least gather some information how one could do > > that. > > Have a look at Caja: http://code.google.com/p/google-caja/ > > This allows Javascript to be sandboxed within a web page and it works on > today's browsers. It involves a fair amount of slowdown, but in future > ES5's strict mode will allow faster Caja implementations.
Yes. In fact, our recent gedanken experiments at <http:// code.google.com/p/es-lab/> indicate that, on a Secureable ES5 implementation <http://code.google.com/p/es-lab/wiki/SecureableES5>, we should be able to do a client-side verification-only Caja-like system (which we will propose as the SES standard), with no blacklisting, no runtime whitelisting, and after startup, no runtime overhead and no space overhead. The only heavy piece of the startup is the JavaScript parser (for verification purposes). Parsing JS accurately is *hard*. However, all the browsers have fast JS parsers built in already. On a Secureable ES + an API for parsing JS into ASTs <http://code.google.com/p/es-lab/wiki/JsonMLASTFormat>, the remaining download should be small and fast. In answer to your original question, on a browser also supporting the Uniform Messaging Policy <http://dev.w3.org/2006/waf/UMP/>, safe mashups <http://code.google.com/p/es-lab/wiki/SafeMashups> should be straightforward. Adam, I'm curious in what way the new @sandbox primitives would be better than this at containing advertisements. > There are basically two approaches to sandboxing ES code [1]: > within-Ecmascript language-based approaches (e.g. Caja, ADsafe, WebSandbox, > FBJS) and DOM/browser-based approaches (e.g. iframes). I suspect that the > language-based approaches will win in the long term because they can evolve > more rapidly and have multiple competing implementations. > > Cheers, > Mark > > [1]https://mail.mozilla.org/pipermail/es-discuss/2009-December/010303.html
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
