<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 24/08/2012 20:15, Mark S. Miller a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CABHxS9hnKx2ga1J8XSMfvc0pZyuF4K0cuBHTdGQEit1au-k+yA@mail.gmail.com"
      type="cite"><br>
      On Fri, Aug 24, 2012 at 10:51 AM, Brendan Eich <span dir="ltr"><<a
          moz-do-not-send="true" href="mailto:brendan@mozilla.org"
          target="_blank">brendan@mozilla.org</a>></span> wrote:<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="im">Kris Kowal wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              On Fri, Aug 24, 2012 at 10:41 AM, Brendan Eich<<a
                moz-do-not-send="true" href="mailto:brendan@mozilla.org"
                target="_blank">brendan@mozilla.org</a>>  wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                I'm not sure what the problem is -- I read the old
                thread, and noticed the<br>
                solution:<br>
                var global = Function("return this")();<br>
                This is good for any code mode, strict or non-strict.
                Does CSP ban Function<br>
                as well as eval?<br>
              </blockquote>
              <br>
              CSP does forbid the Function constructor, by the edict
              “Code will not<br>
              be created from strings”.<br>
              <br>
              <a moz-do-not-send="true" href="http://www.w3.org/TR/CSP/"
                target="_blank">http://www.w3.org/TR/CSP/</a> Section
              4.2 “If unsafe-eval is not allowed…”<br>
            </blockquote>
            <br>
          </div>
          Sure, makes sense (I think I even knew that once -- have to
          catch up on CSP when I have some time, next millennium :-P).<br>
          <br>
          Is it common to want an expression, usable in any context
          (non-strict, strict, CSP, deep in a function nest with
          potentially many names in scope, some of which might shadow
          globals), that evaluates to "the current global object"?<br>
          <br>
          JS libraries do things like<br>
          <br>
          (funciton (global) {<br>
            // all the code here<br>
          })(this);<br>
          <br>
          and that works, as well as the brute force<br>
          <br>
          var global = this;<br>
          <br>
          approach. But one must take care not to shadow the name.<br>
          <br>
          Could ES6 add a predefined global property named 'global', set
          to reference the global object? I suppose maybe - it would be
          writable or (to use WebIDL's term) [Replaceable]. We can't
          just make a const global, we will break extant code.<br>
          <br>
          Is this global global important to standardize?</blockquote>
        <div><br>
        </div>
        <div>It is important to not standardize. The global provides
          essentially the full authority provided by that frame. CSP
          restricts eval and Function presumably for some security
          reason ;). ES5/strict prevents ambient access to the global
          because it leads both to bad software engineering and to
          security holes. SES makes use of that inability to provide a
          virtualized global to untrusted code executing within the
          frame. SES virtualizes Function and eval at the same time,
          which prevents backdoor access to the real global.<br>
        </div>
      </div>
    </blockquote>
    Not saying that I'm in favor of a global global, but SES could
    provide a virtualized global when untrusted code asks for the free
    variable "global" as it certainly does with the "window" and
    "frames" variable.<br>
    <br>
    When it'll be possible to have the virtualized global as a proxy, it
    will be possible to even dynamically replace accesses to the global
    object with the vitualized object regardless of how it's been
    aliased.<br>
    <br>
    My point being that adding a global global does not increase the
    security hazard.<br>
    I however agree it sort of sends the wrong message.<br>
    <br>
    David<br>
  </body>
</html>