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

Growing ADsafe for larger apps?

Expand Messages
  • adam.kumpf
    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
    Message 1 of 11 , May 24, 2010
    View Source
    • 0 Attachment
      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).

      Keep up the great work!

      Thanks,
      Adam
    • Mike Samuel
      2010/5/24 adam.kumpf ... Caja ( http://code.google.com/p/google-caja/ ) is meant for larger scale apps. It does not currently tame
      Message 2 of 11 , May 24, 2010
      View Source
      • 0 Attachment
        2010/5/24 adam.kumpf <adam.kumpf@...>
         

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

        Keep up the great work!

        Caja ( http://code.google.com/p/google-caja/ ) is meant for larger scale apps.  It does not currently tame canvas, but it does deal with most of CSS 2.1 and parts of CSS 3.

         

        Thanks,
        Adam


      • adam.kumpf
        ... Caja is a great idea, but it has some large fundamental limitations. As I see it, since the code is transformed irreversibly it is significantly harder to
        Message 3 of 11 , May 24, 2010
        View Source
        • 0 Attachment
          --- In caplet@yahoogroups.com, Mike Samuel <mikesamuel@...> wrote:
          >
          > 2010/5/24 adam.kumpf <adam.kumpf@...>
          >
          > >
          > >
          > > 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).
          > >
          > > Keep up the great work!
          > >
          > Caja ( http://code.google.com/p/google-caja/ ) is meant for larger scale
          > apps. It does not currently tame canvas, but it does deal with most of CSS 2.1 and parts of CSS 3.
          >

          Caja is a great idea, but it has some large fundamental limitations. As I see it, since the code is transformed irreversibly it is significantly harder to debug, maintain, and verify at runtime. ADsafe seems so straight-forward and elegant in its simplicity; am I missing something bigger here?

          ADsafe is great for integrating code without transformation, I'm just not sure how large it can scale (I don't see any real hard limits, but I'd like to hear some other voices on this).

          Are there any large scale sites that use ADsafe for more than advertisements? The demo widgets (sudoku, etc) definitely show the possibility of more than ads, but I haven't found much online with ADsafe being used explicitly.

          Cheers,
          Adam
        • Marcel Laverdet
          I don t think the transformation has that big of a cost. Debugging isn t that bad since you can debug before transformation, and transformation doesn t affect
          Message 4 of 11 , May 25, 2010
          View Source
          • 0 Attachment
            I don't think the transformation has that big of a cost. Debugging isn't that bad since you can debug before transformation, and transformation doesn't affect line numbers (is this still true?) so thrown exceptions will have reasonable stack traces. Maintenance is the same, running the transformation should just be part of your makefile.

            As for verification, is it possible to create a process which can certify that a program has been cajoled? That could be a very valuable tool...
          • Mike Samuel
            2010/5/24 adam.kumpf ... ADsafe is a beautiful piece of work and you are right about transformation having downsides. Our strategy thus
            Message 5 of 11 , May 26, 2010
            View Source
            • 0 Attachment
              2010/5/24 adam.kumpf <adam.kumpf@...>
               



              --- In caplet@yahoogroups.com, Mike Samuel <mikesamuel@...> wrote:
              >
              > 2010/5/24 adam.kumpf <adam.kumpf@...>


              >
              > >
              > >
              > > 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).
              > >
              > > Keep up the great work!
              > >
              > Caja ( http://code.google.com/p/google-caja/ ) is meant for larger scale
              > apps. It does not currently tame canvas, but it does deal with most of CSS 2.1 and parts of CSS 3.
              >

              Caja is a great idea, but it has some large fundamental limitations. As I see it, since the code is transformed irreversibly it is significantly harder to debug, maintain, and verify at runtime. ADsafe seems so straight-forward and elegant in its simplicity; am I missing something bigger here?

              ADsafe is a beautiful piece of work and you are right about transformation having downsides.  Our strategy thus far has been to mitigate those upsides by integrating with debuggers like lavabug.

              There are some upsides to too though.
              Consider code like
                  x[+y]
              If you think this is safe initially but realize later that it is unsafe, then with a verifier approach you have to reject it, possibly requiring a large number of developers to rewrite their code.  With a rewriter, you can rewrite it to something safer.

              I think the reason we and Doug took different approaches was different design goals.  We wanted something that would support common coding practices and legacy code where possible.  Doug made the operating assumption that for certain niches, developers would be willing to learn new APIs and libraries.  To the degree to which a language's core libraries/APIs define the language, ADsafe is a new language.


               
              ADsafe is great for integrating code without transformation, I'm just not sure how large it can scale (I don't see any real hard limits, but I'd like to hear some other voices on this). 
               
              Are there any large scale sites that use ADsafe for more than advertisements? The demo widgets (sudoku, etc) definitely show the possibility of more than ads, but I haven't found much online with ADsafe being used explicitly.

              Cheers,
              Adam


            • adam.kumpf
              ... 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
              Message 6 of 11 , May 26, 2010
              View Source
              • 0 Attachment
                > >
                > > Caja is a great idea, but it has some large fundamental limitations. As I
                > > see it, since the code is transformed irreversibly it is significantly
                > > harder to debug, maintain, and verify at runtime. ADsafe seems so
                > > straight-forward and elegant in its simplicity; am I missing something
                > > bigger here?
                > >
                >
                > ADsafe is a beautiful piece of work and you are right about transformation
                > having downsides. Our strategy thus far has been to mitigate those upsides
                > by integrating with debuggers like lavabug.
                >
                > There are some upsides to too though.
                > Consider code like
                > x[+y]
                > If you think this is safe initially but realize later that it is unsafe,
                > then with a verifier approach you have to reject it, possibly requiring a
                > large number of developers to rewrite their code. With a rewriter, you can
                > rewrite it to something safer.
                >
                > I think the reason we and Doug took different approaches was different
                > design goals. We wanted something that would support common coding
                > practices and legacy code where possible. Doug made the operating
                > assumption that for certain niches, developers would be willing to learn new
                > APIs and libraries. To the degree to which a language's core libraries/APIs
                > define the language, ADsafe is a new language.
                >
                >


                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.

                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

                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.

                Thanks again -- this is a very exciting space.

                Cheers,
                Adam
              • Mike Samuel
                2010/5/26 adam.kumpf ... Mark (CCed) can correct me if I say anything wrong. ECMA approved EcmaScript 5 which has a strict mode removes
                Message 7 of 11 , May 26, 2010
                View Source
                • 0 Attachment
                  2010/5/26 adam.kumpf <adam.kumpf@...>
                  >
                  >
                  >
                  > > >
                  > > > Caja is a great idea, but it has some large fundamental limitations. As I
                  > > > see it, since the code is transformed irreversibly it is significantly
                  > > > harder to debug, maintain, and verify at runtime. ADsafe seems so
                  > > > straight-forward and elegant in its simplicity; am I missing something
                  > > > bigger here?
                  > > >
                  > >
                  > > ADsafe is a beautiful piece of work and you are right about transformation
                  > > having downsides. Our strategy thus far has been to mitigate those upsides
                  > > by integrating with debuggers like lavabug.
                  > >
                  > > There are some upsides to too though.
                  > > Consider code like
                  > > x[+y]
                  > > If you think this is safe initially but realize later that it is unsafe,
                  > > then with a verifier approach you have to reject it, possibly requiring a
                  > > large number of developers to rewrite their code. With a rewriter, you can
                  > > rewrite it to something safer.
                  > >
                  > > I think the reason we and Doug took different approaches was different
                  > > design goals. We wanted something that would support common coding
                  > > practices and legacy code where possible. Doug made the operating
                  > > assumption that for certain niches, developers would be willing to learn new
                  > > APIs and libraries. To the degree to which a language's core libraries/APIs
                  > > define the language, ADsafe is a new language.
                  > >
                  > >
                  >
                  > 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.
                  >
                  > 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
                  >
                  > 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.

                  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.

                  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?


                  > Thanks again -- this is a very exciting space.
                  >
                  > Cheers,
                  > Adam
                  >
                • Mark S. Miller
                  Caution: I tend to err on the side of too much detail. Apologies in advance. ... We are always very happy to hear when others come think in these terms as
                  Message 8 of 11 , May 26, 2010
                  View Source
                  • 0 Attachment
                    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@...>

                    > 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
                  • 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 9 of 11 , May 27, 2010
                    View Source
                    • 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 10 of 11 , May 28, 2010
                      View Source
                      • 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 11 of 11 , May 29, 2010
                        View Source
                        • 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.