« Return to Thread: Another de-facto insecurity we need to fix in ES5

Re: Another de-facto insecurity we need to fix in ES5

by Mark S. Miller-2 :: Rate this Message:

On Mon, Jun 15, 2009 at 8:28 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock@...> 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 ES5's semantics.

--
Cheers,
--MarkM

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: Another de-facto insecurity we need to fix in ES5