<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Le 17/06/2011 18:45, Mark S. Miller a écrit :<br>
    <blockquote
      cite="mid:BANLkTinkKk1S=k46F6M9gna0g8-ASK1T0Q@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div> </div>
        <blockquote class="gmail_quote" style="margin: 0px 0px 0px
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div bgcolor="#ffffff" text="#000000">What is the rational
            behind each of these?</div>
        </blockquote>
      </div>
      <div class="gmail_quote"><br>
      </div>
      <div class="gmail_quote">One of JavaScript's great virtues is that
        it is a highly reflective language, leading programmers and
        framework builders to engage in a wide range of meta-programming
        patterns. One of JavaScript's great flaws is that its property
        state space is complex, leading such meta-programmers into a
        case explosion. Prior to ES5, there were so few guarantees of
        any stability properties over this state space, especially for
        non-native ("host") objects, that robust programming was almost
        impossible. </div>
      <div class="gmail_quote"><br>
      </div>
      <div class="gmail_quote">For example, Caja on ES3, to uphold its
        own invariants, must handle non-native objects very carefully.
        (...). To diminish the cases we need to worry about, Caja pays
        substantial costs to ensure that untrusted code never gets a
        direct reference to any non-native object, not even "alert".
        This ice is too thin.</div>
    </blockquote>
    It may be a naive question, but why should untrusted code be
    prevented from getting a reference to a non-native object? Do you
    have a concrete example of threat this protects from?<br>
    ... well... if untrusted code has access to "alert", it can do
    "while(1) alert();" and prevent trusted code from running. But all
    other non-native objects?<br>
    <br>
    How did each of the 4 "Universal property constraints" made Caja's
    work easier?<br>
    <br>
    <br>
    For NodeLists proxy emulation, the "length" property cannot be
    changed manually (as far as I know), so I'd say that its writable
    has to be false (tell me if I'm wrong to think that). The "length"
    value can however change due to DOM tree transformations. For this
    reason, configurable has to be true as per Universal property
    constraints 1) a). However you cannot really configure it in the
    sense that you can't neither delete it nor re-configure it.
    "configurable" does not really mean that the property is
    configurable (not quote) on host objects.<br>
    <br>
    I'm just puzzled by the wording I think. "configurable:true" on
    normal native objects means "this property is configurable (delete +
    Object.defineProperty with any property descriptor)".<br>
    However, for abnormal+non-native objects, the semantics of
    "configurable" is constrainted to the Universal property
    constraints, but does not give any insight on what you can do with
    the property. Exact semantics (what you can do with the property) is
    left at the discretion of the object implementor.<br>
    The confusing part for me is probably the "-able" suffix which
    sounds like giving me an information on what I can do with the
    property (like "enumerable" do), but this is actually not the case
    at all for abnormal+non-native objects. It's not that big of a deal
    for abnormal native objects since I can read the spec to know what
    to expect from these.<br>
    <br>
    <br>
    On a last note, array.length already do respect all Universal
    property constraints since writable is true. Or am I missing
    something?<br>
    <br>
    Thanks for your explanations,<br>
    <br>
    David<br>
  </body>
</html>