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

Re: Growing ADsafe for larger apps?

Expand Messages
  • adam.kumpf
    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
    Message 1 of 11 , 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
      >
    • Douglas Crockford
      ... The source is out there, and you are certainly welcome to adapt it. My energies are now focused on repairing ECMAScript and HTML/DOM, ultimately making
      Message 2 of 11 , May 28, 2010
      • 0 Attachment
        --- In caplet@yahoogroups.com, "adam.kumpf" <adam.kumpf@...> wrote:
        >
        > I've been interested in ADsafe for a few months now as a potential way to allow 3rd parts apps to work within a safe sandbox.
        >
        > However, since ADsafe fundamentally began as a sandbox for safe advertisement (which nicely extends to apps), are there specific things that you would handle differently if the focus was full-scale web applications?
        >
        > Said differently, would it be worthwhile to create a derivative framework (for example, APPsafe) specific for webapps? What would its main differences be? Or is it really all the same thing and we'd be better off just having an add-on library that provides some additional glue for hooking up rich web apps within ADsafe?
        >
        > The reason I ask is because I have found it somewhat difficult to make simple ADsafe apps that uses current web rendering/layout technologies (such as drawing to a canvas or easily animating CSS properties). I'm excited about the potential of ADsafe, but I'm not clear about its intended scale (ads, widgets, entire sites, an ADsafe browser OS, etc).


        The source is out there, and you are certainly welcome to adapt it. My energies are now focused on repairing ECMAScript and HTML/DOM, ultimately making ADsafe completely unnecessary.
      • Mark S. Miller
        ... Hi Adam, we are tracking the ES5 implementations in progress at
        Message 3 of 11 , May 29, 2010
        • 0 Attachment
          On Thu, May 27, 2010 at 5:05 PM, adam.kumpf <adam.kumpf@...> wrote:

          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?


          Hi Adam, we are tracking the ES5 implementations in progress at
           

          Unfortunately, though all of these are advancing rapidly, none of the browser-based ones have all that's needed to run initSES.js. In particular, the core of SES's security rests on Object.freeze and on the static scoping and defensible encapsulation provided by strict mode. None of the browser-based implementations provide either of these yet. But I expect they're coming soon.
           


          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...


          This would indeed be a very cool demo! While we're waiting for SES, you can do everything you suggest above with Caja <http://code.google.com/p/google-caja/>. Please try, and please post any questions you may have or issues you run into to <https://groups.google.com/group/google-caja-discuss>. (You need to subscribe before you can post.) Thanks.


          Cheers,
          Adam



           
          --
              Cheers,
              --MarkM
        Your message has been successfully submitted and would be delivered to recipients shortly.