Loading ...
Sorry, an error occurred while loading the content.

328Re: Growing ADsafe for larger apps?

Expand Messages
  • adam.kumpf
    May 27, 2010
    • 0 Attachment
      Mark and Mike,

      This is really a great discussion -- thanks for detailing out the current state of ECMA Script 5, SES, and the overall feel of where things are going.

      I'm particularly intrigued by the SES sketch < http://code.google.com/p/es-lab/source/browse/trunk/src/ses/ > work going on as it seems like a concrete step (although understandably ahead of it's needed conforming ES5 implementation) toward what SES can be.

      I think showcasing the potential of what POLA/SES ECMA Script enables is an important step to getting more people excited (and subsequently more development energy and development perspectives).

      What would it take to get an example together that uses initSES.js to sandbox a a couple of apps on a webpage? Could it work (at least for the most part) as ES5 Strict stands now?

      For example, just having two simple text input boxes of ES5 Strict/SES code that is then dynamically loaded into subsequent divs on a webpage. Ideally, it would demonstrate limited communication between the divs while keeping private information inaccessible to the other (perhaps using the purse example, showing POLA in use). The viewer would then be invited to try to "scam the bank" by hacking the script in any way that choose.

      The banking example is a bit dry, but perhaps with a little finessing it (or something like it) could be a compelling demo to get more people on-board and involved in making SES happen. I'm in awe of the potential of what the web can become as sites become un-siloed via the concepts behind SES. I think you guys are on to something really big here...

      Cheers,
      Adam










      --- In caplet@yahoogroups.com, "Mark S. Miller" <erights@...> wrote:
      >
      > Caution: I tend to err on the side of too much detail. Apologies in advance.
      >
      >
      > On Wed, May 26, 2010 at 4:29 PM, Mike Samuel <mikesamuel@...> wrote:
      >
      > >
      > >
      > > 2010/5/26 adam.kumpf <adam.kumpf@... <adam.kumpf%40yahoo.com>>
      > > > Thanks for the additional clarity of the evolving ADsafe/Caja landscape.
      > > You and Doug are both on to a fundamental shift in how the web works, and
      > > more specifically, how apps/functionality can be re-imagined when they can
      > > be securely combined as never before.
      > >
      >
      > We are always very happy to hear when others come think in these terms as
      > well. Thanks!
      >
      >
      >
      > > >
      > > > I came upon some ongoing dialog about ECMAScript 5 Strict and SES as a
      > > way to merge/rebuild the ADsafe, Caja, and FBJS approaches. I saw at the end
      > > of the SES page on the ECMAScript wiki that Doug suggested a competition
      > > approach to help this happen.
      > > >
      > > > http://wiki.ecmascript.org/doku.php?id=ses:ses
      > >
      >
      > That page has not been updated in a long time. Much of what's there is still
      > accurate, but some of it is stale.
      >
      > A lot of the most recent material on SES is at <
      > http://code.google.com/p/es-lab/>. At <
      > http://code.google.com/p/es-lab/downloads/detail?name=et.pdf> is a
      > presentation I did on Monday to the EcmaScript committee. It's mostly about
      > Ephemeron Tables but does include a short summary of SES. At <
      > http://code.google.com/p/es-lab/wiki/SecureEcmaScript> is a more complete
      > statement, but is more in terms of what we can build from a "friendly" ES5
      > implementation (<http://code.google.com/p/es-lab/wiki/SecureableES5>) than
      > as a specification delta from ES5.
      >
      > Crock and I do believe this achieves the best of ADsafe (simple static
      > verification rather than transformation) and Caja (purely whitelisting, not
      > blacklisting. Supports full object-capability model. Supports almost the
      > entire language and browser API[*].). Given the absence of controversy on
      > the current proposal, we are no longer planning a competition.
      >
      > *Note that the browser API taming is outside the definition of SES but is of
      > course part of any Caja deployment of SES.
      >
      >
      > > >
      > > > What's the current status of it all? I'm scouring the web in search of
      > > better understanding how to navigate the ADsafe/Caja/SES initiatives. Is
      > > there a definitive place that things are being discussed and archived
      > > outside of this forum and the ECMAScript wiki?
      > > >
      > > > I ask because I'd really like to start using it toward something that
      > > could scale and showcase some of the benefits of the POLA javascript
      > > approach.
      > >
      >
      > The implementation sketch at <
      > http://code.google.com/p/es-lab/source/browse/trunk/src/ses/> is just a
      > sketch. Until there's an adequately conforming ES5 implementation to try it
      > on, we cannot run it and so cannot test it.
      >
      > The immediately exciting development effort is ES5/3 and SES5/3, that Mike
      > Stay (cc'ed) is working on, that Mike Samuel comments on below.
      >
      >
      >
      >
      > >
      > > Mark (CCed) can correct me if I say anything wrong.
      > >
      > > ECMA approved EcmaScript 5 which has a strict mode removes a lot of
      > > the problems around "this".
      > >
      > > EcmaScript 6 is almost certain to include ephemeron tables and proxies
      > > (http://code.google.com/p/es-lab/) that make it easy to write
      > > membranes, and all of EcmaScript 6 will likely be built on top of the
      > > strict mode.
      > >
      >
      > Yes. All of these statements reflect current committee agreements and
      > consensus.
      > <http://wiki.ecmascript.org/doku.php?id=harmony:proposals> lists the
      > proposals which the committee has agreed to move from "strawman" to
      > "proposal" status, meaning we expect this functionality in ES6, but the
      > detail may differ arbitrarily. The proxy proposal (by Tom Van Cutsem, cc'ed)
      > as it appears there is the official one.
      >
      >
      > >
      > > Given EcmaScript 6, hopefully Caja will become much simpler gaining
      > > much of the elegance of AdSafe while still being able to preserve API
      > > compatibility for web applications.
      > >
      >
      > > Getting there from the mass of browsers running ES3 is the trick.
      > >
      > > Mark and Mike Stay are working on ES 5 over 3 (
      > > http://code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5
      > > ) which aims to implement ES5 strict mode on ES3.
      > >
      > > Getting from ES5 to the as yet unstandardized ES6 is a tougher problem
      > > since it's a moving target. Mark, can you comment on that?
      > >
      >
      > Sure. There is an interesting transition issue. With the restrictions listed
      > on that page, ES5/3 will support proxies as well. However, a verify-only SES
      > implementation on top of a friendly ES5 without proxies cannot emulate
      > proxies. To preserve the proxy emulation, we may need to preserve the
      > translation strategy for browsers that don't support proxies. Btw, Andreas
      > Gal (cc'ed) of Mozilla has already implemented Proxies and made them
      > available in the Firefox nightlies. They are currently expected to ship,
      > alongside ES5, in Firefox 4. In which case, no problem going with a full
      > verify-only strategy on FF4 (even without Ephemeron Tables).
      >
      > Cajita already emulates ephemeron tables as well as we can without having
      > them be primitively provided, and we will be carrying this technique forward
      > to ES5/3. This is good enough to give us identity preserving membranes, but
      > does result in a storage leak: while a membrane is unrevoked, all objects
      > passed through it are retained. Once the membrane is revoked, the revocation
      > is as fully effective at cleaning up the objects in the compartment as it
      > would be with full ephemeron tables.
      >
      > Of the other items *currently* listed at <
      > http://wiki.ecmascript.org/doku.php?id=harmony:proposals>, all of these can
      > be emulated straightforwardly by incremental improvements to the ES5/3
      > translator. Should this remain the case, (ES5/3,SES5/3) will gradually
      > improve into (ES6/3,SES6/3). We will upgrade the Differences page with any
      > further caveats we find we need in the process.
      >
      >
      > >
      > >
      > > > Thanks again -- this is a very exciting space.
      > >
      >
      > Indeed!
      >
      >
      >
      > > > Cheers,
      > > > Adam
      > > >
      > >
      > >
      > >
      > --
      > Cheers,
      > --MarkM
      >
    • Show all 11 messages in this topic