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

Towards standardization

Expand Messages
  • Mark Miller
    At http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft is posted a very rough first draft for a Secure ECMAScript standard, derived from
    Message 1 of 3 , Jan 20, 2009
    • 0 Attachment
      At

      http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft

      is posted a very rough first draft for a "Secure ECMAScript" standard,
      derived from the "Mountain View draft" of ES3.1
      <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>
      and from Cajita. I hope and believe that we can resolve differences
      between this and other contenders for the Cajita-like layer: ADsafe,
      Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
      and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
      no need for a separate standard for that layer.)

      Further discussion of SES specifically should proceed on the "caplet
      group" list.

      --
      Text by me above is hereby placed in the public domain

      Cheers,
      --MarkM
    • Kris Zyp
      ... Hash: SHA1 Do you have an overview of the differences between SES and ES3.1 (or maybe it is easier to define the differences between SES and Cajita)? I see
      Message 2 of 3 , Jan 21, 2009
      • 0 Attachment
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1

        Do you have an overview of the differences between SES and ES3.1 (or
        maybe it is easier to define the differences between SES and Cajita)?
        I see a lot of [[Prototype]] -> [[Parent]] changes, but maybe you
        could summarize the important differences?
        Kris

        Mark Miller wrote:
        >
        > At
        >
        > http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft
        > <http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft>
        >
        > is posted a very rough first draft for a "Secure ECMAScript" standard,
        > derived from the "Mountain View draft" of ES3.1
        > <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
        > <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>>
        > and from Cajita. I hope and believe that we can resolve differences
        > between this and other contenders for the Cajita-like layer: ADsafe,
        > Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
        > and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
        > no need for a separate standard for that layer.)
        >
        > Further discussion of SES specifically should proceed on the "caplet
        > group" list.
        >
        > --
        > Text by me above is hereby placed in the public domain
        >
        > Cheers,
        > --MarkM
        >
        > <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
        > Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
        > 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
        > font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
        > #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; }
        > #ygrp-mkp .ad a{ color: #0000ff; text-decoration: none; } --> <!--
        > #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
        > #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
        > line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:
        > 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px;
        > font-family:
        > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
        > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
        > input, textarea {font:99% arial,helvetica,clean,sans-serif;}
        > #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
        > #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:
        > Georgia; } #ygrp-text p{ margin: 0 0 1em 0; } #ygrp-tpmsgs{
        > font-family: Arial; clear: both; } #ygrp-vitnav{ padding-top: 10px;
        > font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
        > padding: 0 1px; } #ygrp-actbar{ clear: both; margin: 25px 0;
        > white-space:nowrap; color: #666; text-align: right; } #ygrp-actbar
        > .left{ float: left; white-space:nowrap; } .bld{font-weight:bold;}
        > #ygrp-grft{ font-family: Verdana; font-size: 77%; padding: 15px 0; }
        > #ygrp-ft{ font-family: verdana; font-size: 77%; border-top: 1px
        > solid #666; padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom:
        > 10px; } #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
        > #reco-head { font-weight: bold; color: #ff7900; } #reco-grpname{
        > font-weight: bold; margin-top: 10px; } #reco-category{ font-size:
        > 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital{ background-color:
        > #e0ecee; margin-bottom: 20px; padding: 2px 0 8px 8px; } #ygrp-vital
        > #vithd{ font-size: 77%; font-family: Verdana; font-weight: bold;
        > color: #333; text-transform: uppercase; } #ygrp-vital ul{ padding:
        > 0; margin: 2px 0; } #ygrp-vital ul li{ list-style-type: none; clear:
        > both; border: 1px solid #e0ecee; } #ygrp-vital ul li .ct{
        > font-weight: bold; color: #ff7900; float: right; width: 2em;
        > text-align:right; padding-right: .5em; } #ygrp-vital ul li .cat{
        > font-weight: bold; } #ygrp-vital a{ text-decoration: none; }
        > #ygrp-vital a:hover{ text-decoration: underline; } #ygrp-sponsor
        > #hd{ color: #999; font-size: 77%; } #ygrp-sponsor #ov{ padding: 6px
        > 13px; background-color: #e0ecee; margin-bottom: 20px; }
        > #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; } #ygrp-sponsor
        > #ov li{ list-style-type: square; padding: 6px 0; font-size: 77%; }
        > #ygrp-sponsor #ov li a{ text-decoration: none; font-size: 130%; }
        > #ygrp-sponsor #nc{ background-color: #eee; margin-bottom: 20px;
        > padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px 0; } #ygrp-sponsor
        > .ad #hd1{ font-family: Arial; font-weight: bold; color: #628c2a;
        > font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad a{
        > text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
        > underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
        > .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
        > blockquote{margin: 0 0 0 4px;} .replbq{margin:4} -->

        - --
        Kris Zyp
        SitePen
        (503) 806-1841
        http://sitepen.com
        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.4.9 (MingW32)
        Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

        iEYEARECAAYFAkl3OrQACgkQ9VpNnHc4zAxUrQCgsxAlxVfj/52zM1hTXGVXTHQA
        D2gAoLK5u2/l7pHEv/Kcbyc6WnPpQTj7
        =fLQe
        -----END PGP SIGNATURE-----
      • Mark S. Miller
        ... Three synergies between ES3.1 strict and SES: * Better target: Easy to translate SES to ES3.1-strict * Better source: Easier to translate ES3.1-strict to
        Message 3 of 3 , Jan 24, 2009
        • 0 Attachment
          On Wed, Jan 21, 2009 at 7:09 AM, Kris Zyp <kris@...> wrote:
          > Do you have an overview of the differences between SES and ES3.1

          Three synergies between ES3.1 strict and SES:

          * Better target: Easy to translate SES to ES3.1-strict
          * Better source: Easier to translate ES3.1-strict to SES
          * Better neighbor: ES3.1 code can't violate SES objects.


          First, SES is a subset of ES3.1-strict, so I'll start with that.

          * Most important: all primordial state -- all objects and all state reachable from the global scope -- is frozen. In other words, the global object itself, as seen from SES, is immutable (deeply frozen). Only by imposing this rule can the global object be safely shared by separate protection domains that must remain isolated from each other.
          ** global eval() evals SES,
          ** Function constructor is suppressed.
          ** Math.random(), new Date(), and Date.now() are suppressed.
          ** for/in loops in deterministic order.

          * No "this"
          ** foo(..) equiv to (true && foo)(..)
          * no override of Function.prototype.(call/bind/apply)
          ** for functions, foo(..) equiv foo.call(??, ..) equiv foo.apply(??, [..])

          * All functions are frozen before first use or escaping occurrence:
          ** Anonymous functions are born frozen.
          ** If "foo" is a named function, one can initialize "foo.prop" in straight line code between its definition and first non-initializing use.
          ** Function names define unassignable variables (as if with const, but with function-like hoisting rather than a read barrier)

          * Only built-in functions have function prototypes
          ** Function prototypes are not first class: <function>.prototype and <prototype>.constructor are not whitelisted.

          * No RegExp literals -- use RegExp constructor.
          * No semicolon insertion.

          SES code can only define records, arrays, and functions. Objects other than these but represent pre-existing libraries (and other tamed legacy). All such objects are sealed.

          > (or
          > maybe it is easier to define the differences between SES and Cajita)?

          Current Cajita does not allow control of the attributes of individual properties. Rather, a record or an array is either frozen or not. If it's not frozen, then all of its properties are mutable.

          Likewise, one cannot define new getter/setter properties within Cajita code.


          > I see a lot of [[Prototype]] -> [[Parent]] changes, but maybe you
          > could summarize the important differences?

          That one is only cosmetic. Since the ES3.1 explicit "prototype" property is not whitelisted, but is still needed to account for the semantics of built-in libraries and tamed legacy, it will be explained as an internal property. To prevent confusion, I am rephrasing to avoid the term where another term would do as well.


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