Another de-facto insecurity we need to fix in ES5
Mark S. Miller
erights at google.com
Wed Jun 17 12:54:49 PDT 2009
On Mon, Jun 15, 2009 at 8:28 PM, Allen Wirfs-Brock <
Allen.Wirfs-Brock at microsoft.com> wrote:
> On the surface, this seems fairly reasonable., of course IE doesn’t have
> any skin in the mutable __proto__ game.
> Would you really associate this with Object.freeze or would you make it a
> characteristic of the [[Extensible]] internal property being false?
> Personally, I’d probably be inclined to go with the latter.
Yes, that seems at least as good. In fact, aesthetically it seems a bit
better, though I can't say why. Let's do that instead. Thanks.
> My one concern also relates to you other message concerning debugging
> APIs. Does no modification of [[Prototype]] really mean never. I certainly
> can envision debugger APIs or other support for incremental/evolutionary
> development tools that could make use of a mutable [[Prototype]] (as well as
> mutability of other immutable states such as a false [[Extensible]] internal
> property) . I’m quite happy to agree that these items should not be
> directly mutable from the internal perspective of an application program but
> I’m less willing to agree that a “privileged” tooling API (including
> possibly a mirrors reflection based API) could never mutate such state.
I'm happy to revisit how never "never" really is as we get into the
discussion of debuggers. Debuggers that allow intervention into running
program state often can bring about mutations that are outside of the
possible semantics of the program. For example
var x = 3;
x++; // only mutation to x.
// breakpoint here
.. x .. // use of x
Static reasoning about the possible states of x in this program would
conclude that x must always be a number greater than or equal to 3. However,
when examined through, for example, an Eclipse-like or Smalltalk-like
debugger, the debugger may very well allow the debugger's user to set the
value to 2. This may very well violate the invariants that the code relies
on -- which is fine. No one should try to write code that defends against
such god-like interventions. To account for these possibilities, the
semantics of the programming language becomes weird. That's part of the
point of stratification -- one can give a separate simpler account of the
programming language in the absence of such interventions. The ES5 spec
should only be trying to give this simpler intervention-free account of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss