Another de-facto insecurity we need to fix in ES5

[Mark S. Miller-2]

As I just mentioned on the debugging API thread, at the last EcmaScript meeting we agreed

On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...> wrote:

Rather than describing the evil things that implementations do with F.caller, we agreed to just impose a blanket prohibition of code peeking into the environment records or identity of strict functions on the stack.  This way a test suite can ensure that F.caller does nnot reveal strict functions without us having to introduce the evil things into the standard.  I'll write up proposed wording.

This is an example of a more general principle. The language we're evolving from isn't ES3, it's ES3 as currently practiced. When browser vendors implement ES5, they won't actually implement ES5 as speced. They will implement ES5 as extended to preserve some of the defacto practices they currently support. When these likely future defacto extensions would lose some of the integrity or security gains we're trying to achieve with ES5, then we should find an adjustment to the ES5 spec that does not break these defacto practices for old code but still allows new code to defend itself from attackers using these defacto extensions.

The ES3 and ES5 specs both specify the implicit [[Prototype]] property as something that is initialized once and then unchanged. All major browsers today but IE alias this to the name "__proto__" (as if that's a named property) and allow it to be mutated. None of the rest of the ES5 semantics has been critically examined in light of the possibility that an implementation may allow this mutation. So long as [[Prototype]] is pervasively mutable, then most interesting behavior of an ES5 object won't be stable as well. I recommend:

Object.freeze(foo) guarantees not only that all of foo's named properties be frozen and that foo is non-extensible, but also that foo's [[Prototype]] will not be changed.

For non-frozen objects, we continue not to specify that [[Prototype]] can be mutated or explain any means for mutating it. But neither can we prohibit such mutations unless FF, Safari, and Opera are willing to give up this feature. The proposal above won't break any old code that depends on mutating __proto__ but will enable new code to protect itself. I would like to propose something stronger, but don't know of anything stronger compatible with this constraint.

--
   Cheers,
   --MarkM

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

[Douglas Crockford]

Mark S. Miller wrote:

> As I just mentioned on the debugging API thread, at the last EcmaScript
> meeting we agreed
>
> On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...
> <mailto:waldemar@...>> wrote:
>
>     Rather than describing the evil things that implementations do with
>     F.caller, we agreed to just impose a blanket prohibition of code
>     peeking into the environment records or identity of strict functions
>     on the stack.  This way a test suite can ensure that F.caller does
>     nnot reveal strict functions without us having to introduce the evil
>     things into the standard.  I'll write up proposed wording.
>
>
> This is an example of a more general principle. The language we're
> evolving from isn't ES3, it's ES3 as currently practiced. When browser
> vendors implement ES5, they won't actually implement ES5 as speced. They
> will implement ES5 as extended to preserve some of the defacto practices
> they currently support. When these likely future defacto extensions
> would lose some of the integrity or security gains we're trying to
> achieve with ES5, then we should find an adjustment to the ES5 spec that
> does not break these defacto practices for old code but still allows new
> code to defend itself from attackers using these defacto extensions.
>
> The ES3 and ES5 specs both specify the implicit [[Prototype]] property
> as something that is initialized once and then unchanged. All major
> browsers today but IE alias this to the name "__proto__" (as if that's a
> named property) and allow it to be mutated. None of the rest of the ES5
> semantics has been critically examined in light of the possibility that
> an implementation may allow this mutation. So long as [[Prototype]] is
> pervasively mutable, then most interesting behavior of an ES5 object
> won't be stable as well. I recommend:
>
> Object.freeze(foo) guarantees not only that all of foo's named
> properties be frozen and that foo is non-extensible, but also that foo's
> [[Prototype]] will not be changed.
>
> For non-frozen objects, we continue not to specify that [[Prototype]]
> can be mutated or explain any means for mutating it. But neither can we
> prohibit such mutations unless FF, Safari, and Opera are willing to give
> up this feature. The proposal above won't break any old code that
> depends on mutating __proto__ but will enable new code to protect
> itself. I would like to propose something stronger, but don't know of
> anything stronger compatible with this constraint.

Is this something the market can fix? Browsers with __proto__ will be unsafe for
mashups. Sites that care about their users' safety will recommend sans __proto__
browsers. Parents who care about the safety of their families will install only
sans __proto__ browsers. The share of the dangerous browsers falls to nothing
and the safer browsers prevail. Problem solved.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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.

 

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.  

 

From: es-discuss-bounces@... [mailto:es-discuss-bounces@...] On Behalf Of Mark S. Miller
Sent: Monday, June 15, 2009 7:52 PM
To: es-discuss; es5-discuss@...
Subject: Another de-facto insecurity we need to fix in ES5

 

As I just mentioned on the debugging API thread, at the last EcmaScript meeting we agreed

On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...> wrote:

Rather than describing the evil things that implementations do with F.caller, we agreed to just impose a blanket prohibition of code peeking into the environment records or identity of strict functions on the stack.  This way a test suite can ensure that F.caller does nnot reveal strict functions without us having to introduce the evil things into the standard.  I'll write up proposed wording.

This is an example of a more general principle. The language we're evolving from isn't ES3, it's ES3 as currently practiced. When browser vendors implement ES5, they won't actually implement ES5 as speced. They will implement ES5 as extended to preserve some of the defacto practices they currently support. When these likely future defacto extensions would lose some of the integrity or security gains we're trying to achieve with ES5, then we should find an adjustment to the ES5 spec that does not break these defacto practices for old code but still allows new code to defend itself from attackers using these defacto extensions.

The ES3 and ES5 specs both specify the implicit [[Prototype]] property as something that is initialized once and then unchanged. All major browsers today but IE alias this to the name "__proto__" (as if that's a named property) and allow it to be mutated. None of the rest of the ES5 semantics has been critically examined in light of the possibility that an implementation may allow this mutation. So long as [[Prototype]] is pervasively mutable, then most interesting behavior of an ES5 object won't be stable as well. I recommend:

Object.freeze(foo) guarantees not only that all of foo's named properties be frozen and that foo is non-extensible, but also that foo's [[Prototype]] will not be changed.

For non-frozen objects, we continue not to specify that [[Prototype]] can be mutated or explain any means for mutating it. But neither can we prohibit such mutations unless FF, Safari, and Opera are willing to give up this feature. The proposal above won't break any old code that depends on mutating __proto__ but will enable new code to protect itself. I would like to propose something stronger, but don't know of anything stronger compatible with this constraint.

--
   Cheers,
   --MarkM

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

[Brendan Eich-3]

For ES5, this is a tempest in a teapot.

We at Mozilla are trying to remove assignable __proto__ in a near-term release, except in these two useful and (AFAIK) safe cases:

* A newborn with no other properties.

* A recent-born in the midst of initialization via evaluation of its object initialiser syntax, where the baby object can't escape, can't be referenced to make a cycle, etc.

We really don't want to continue supporting mutating __proto__ in other cases. Assignable __proto__ is a hugely expensive operation that breaks all sorts of optimizations, requiring fairly expensive deoptimization effort.

ES5's Object.create relieves the need for any of this, but legacy code won't be rewritten all at once, so we're probably going to support the above two bulleted cases.

The idea that the ES5 spec suddenly makes the world more secure by trying circuitously to address old extensions such as __proto__ seems optimistic to me. Better to get rid of the offending extension than try to fence it while not speaking its (I mean ES-unspecififed __proto__'s) name.

But this is a job for implementors, not the spec. Implementors jumped in when the standards process stalled after ES3. Blame them for trying, or failing to design high-integrity APIs, but it's all spilled milk. They need to clean it up, 'sall (I say this as one of "them").

The bigger picture must involve implementations as well as the spec, and de-facto standards that may precede de-jure replacements or adoptions of de-facto standards. It isn't as if ES5 is the last time there will be a de-facto mess to clean up, although members of the committee are making good promises and progress in sharing intentions and prototypes. I suspect we'll see some de-facto stuff come out of one or two vendors who aren't active in TC39 (Apple, Google V8).

Beyond this point, implementations will have bugs, whether in would-be de-facto extensions to the standard, or in standardized components -- forever. Attempts to inject security by code transformations (which of course can themselves be buggy) will simply have to try to work around browser JS engine bugs.

Security is never done, because it consists of end-to-end and many-layers property enforcement problems, where the evolving system and economic scarcity mean the bad guys always have a new layer or middle-man that's under-defended to attack. Denning said this in her 1999 Infosec award speech, and it seems unassailable, even if it outrages some of my academic research friends.

Better JS security will have to come from the browsers fixing bugs and breaking compatibility, where the alternative is an ongoing security hazard that's actually exploited. When it comes to both bad old default security policies, and some of the extensions added over the years, I say: break the web, or at least bend it! My new mantra. Shocking, I know, but with minority-share browsers now getting close to modern-IE by-version market share, isn't it time?

/be

On Jun 15, 2009, at 8:28 PM, 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.

 

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.  

 

From: es-discuss-bounces@... [es-discuss-bounces@...] On Behalf Of Mark S. Miller
Sent: Monday, June 15, 2009 7:52 PM
To: es-discuss; es5-discuss@...
Subject: Another de-facto insecurity we need to fix in ES5

 

As I just mentioned on the debugging API thread, at the last EcmaScript meeting we agreed

On Mon, Jun 1, 2009 at 5:11 PM, Waldemar Horwat <waldemar@...> wrote:

Rather than describing the evil things that implementations do with F.caller, we agreed to just impose a blanket prohibition of code peeking into the environment records or identity of strict functions on the stack.  This way a test suite can ensure that F.caller does nnot reveal strict functions without us having to introduce the evil things into the standard.  I'll write up proposed wording.

This is an example of a more general principle. The language we're evolving from isn't ES3, it's ES3 as currently practiced. When browser vendors implement ES5, they won't actually implement ES5 as speced. They will implement ES5 as extended to preserve some of the defacto practices they currently support. When these likely future defacto extensions would lose some of the integrity or security gains we're trying to achieve with ES5, then we should find an adjustment to the ES5 spec that does not break these defacto practices for old code but still allows new code to defend itself from attackers using these defacto extensions.

The ES3 and ES5 specs both specify the implicit [[Prototype]] property as something that is initialized once and then unchanged. All major browsers today but IE alias this to the name "__proto__" (as if that's a named property) and allow it to be mutated. None of the rest of the ES5 semantics has been critically examined in light of the possibility that an implementation may allow this mutation. So long as [[Prototype]] is pervasively mutable, then most interesting behavior of an ES5 object won't be stable as well. I recommend:

Object.freeze(foo) guarantees not only that all of foo's named properties be frozen and that foo is non-extensible, but also that foo's [[Prototype]] will not be changed.

For non-frozen objects, we continue not to specify that [[Prototype]] can be mutated or explain any means for mutating it. But neither can we prohibit such mutations unless FF, Safari, and Opera are willing to give up this feature. The proposal above won't break any old code that depends on mutating __proto__ but will enable new code to protect itself. I would like to propose something stronger, but don't know of anything stronger compatible with this constraint.

-- 
   Cheers,
   --MarkM

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

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

[Mark S. Miller-2]

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

[Mark S. Miller-2]

On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich <brendan@...> wrote:

For ES5, this is a tempest in a teapot.

We at Mozilla are trying to remove assignable __proto__ in a near-term release,

Hi Brendan, this is wonderful news!

As reason for skepticism, our v8 folk cite

<http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript>
 
Nevertheless, I'm pleased to report that our v8 folks agree that if Mozilla does this and does not back off because of compatibility problems, they will do so as well. Thanks for being brave enough to jump into this pool first!

 

except in these two useful and (AFAIK) safe cases:

* A newborn with no other properties.

For an object that never comes to have any own properties, when is it no longer a newborn?  For example

    function Token() {}
    var tok = new Token();

Is the newly created object still a newborn by the time it gets assigned to tok?
 
 

* A recent-born in the midst of initialization via evaluation of its object initialiser syntax, where the baby object can't escape, can't be referenced to make a cycle, etc.

How does this arise?

In both cases, would it be true that by the time Object.freeze(x) or Object.preventExtensions(x) returns that x no longer has a mutable [[Prototype]]? If so, then you're plans are already conformant to either my original suggestion or Allen's improved version.

We really don't want to continue supporting mutating __proto__ in other cases. Assignable __proto__ is a hugely expensive operation that breaks all sorts of optimizations, requiring fairly expensive deoptimization effort.

I love it when performance, integrity, and security all line up on the same side of an issue ;).
 

ES5's Object.create relieves the need for any of this, but legacy code won't be rewritten all at once, so we're probably going to support the above two bulleted cases.

Given that this already isn't a problem for IE and Opera, that v8 follows your lead, and assuming that Apple does as well -- so that these two remain the only exceptions -- do you recommend that the spec adopt stronger wording? (I would find this attractive as well.) Any suggestions for what this stronger wording might be?
 

The idea that the ES5 spec suddenly makes the world more secure by trying circuitously to address old extensions such as __proto__ seems optimistic to me. Better to get rid of the offending extension than try to fence it while not speaking its (I mean ES-unspecififed __proto__'s) name.

Certainly! But until we see how your experiment goes (best of luck!) I am proceeding under the pessimistic assumption that we can't get rid of the offending extension from all ES5 implementations. I'd love to be proven wrong.
 

But this is a job for implementors, not the spec. Implementors jumped in when the standards process stalled after ES3. Blame them for trying, or failing to design high-integrity APIs, but it's all spilled milk. They need to clean it up, 'sall (I say this as one of "them").

The bigger picture must involve implementations as well as the spec, and de-facto standards that may precede de-jure replacements or adoptions of de-facto standards. It isn't as if ES5 is the last time there will be a de-facto mess to clean up, although members of the committee are making good promises and progress in sharing intentions and prototypes.

When implementations have bad features in common with each other, as
with F.caller, then some cross-browser code will have come to rely on
that feature. Then, even if each browser vendor individually believes that the web
would be better off without that feature, they are in the normal
browser competitive bind removing the feature. That's one of the major
purposes of standards committees -- to get de-jure agreement on
changes that all would like to make but that each would be punished
for making by themselves. I think this accurately describes why we
needed a de-jure poison pill for F.caller.
 

I suspect we'll see some de-facto stuff come out of one or two vendors who aren't active in TC39 (Apple, Google V8).

Google is quite active in TC39. Google's representatives to TC39 (including me) are now in close coordination with our v8 team. However, v8 remains committed to following WebKit. Fortunately, AFAIK, WebKit has not yet taken any stance on whether [[Prototype]] will be mutable in their ES5 implementation. Maciej?

Beyond this point, implementations will have bugs, whether in would-be de-facto extensions to the standard, or in standardized components -- forever. Attempts to inject security by code transformations (which of course can themselves be buggy) will simply have to try to work around browser JS engine bugs.

Sure. However, some such bugs can cause severe problems. I am trying to catch as many as I notice in ES5 before ES5 is set in stone. Given the expanded threat model ES5 seems to enable (see the "Future defensibility from untranslated code" section at the bottom of <http://code.google.com/p/google-caja/wiki/NiceNeighbor>), the F.caller issue, had it not been caught in time, would have cost us a factor of two in performance. The present issue, if unfixed, may well preclude this expansion of our threat model except on ES5 implementations that happen not to have this problem.
 

Security is never done, because it consists of end-to-end and many-layers property enforcement problems, where the evolving system and economic scarcity mean the bad guys always have a new layer or middle-man that's under-defended to attack. Denning said this in her 1999 Infosec award speech, and it seems unassailable, even if it outrages some of my academic research friends.

Btw, here's an academic paper you may enjoy that agrees with you and Denning on the layering point <http://www.erights.org/talks/no-sep/> ;).
 

Better JS security will have to come from the browsers fixing bugs and breaking compatibility, where the alternative is an ongoing security hazard that's actually exploited. When it comes to both bad old default security policies, and some of the extensions added over the years, I say: break the web, or at least bend it! My new mantra. Shocking, I know, but with minority-share browsers now getting close to modern-IE by-version market share, isn't it time?

I sincerely applaud this bold stance. If Mozilla proceeds in this manner successfully, then the present issue becomes a non-concern; as probably do several more we haven't stumbled across yet. Please let us know what we can do to help you succeed on this quest. Really. And thanks again!

--
   Cheers,
   --MarkM

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

[Maciej Stachowiak]

On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:

>
> I suspect we'll see some de-facto stuff come out of one or two  
> vendors who aren't active in TC39 (Apple, Google V8).
>
>
> Google is quite active in TC39. Google's representatives to TC39  
> (including me) are now in close coordination with our v8 team.  
> However, v8 remains committed to following WebKit. Fortunately,  
> AFAIK, WebKit has not yet taken any stance on whether [[Prototype]]  
> will be mutable in their ES5 implementation. Maciej?

Your phrasing of the question strikes me as odd, because changing  
behavior of de facto extensions like this seems orthogonal to  
supporting a new version of the spec. If getting rid of or restricting  
mutable __proto__ turns out to be feasible and a good idea, then we  
would not tie it to implementation timeline for ES5 features.

As to the substantive issue: mutable __proto__ is something we would  
prefer not to have, but we are concerned about the compatibility  
issues. We look forward to hearing about Mozilla's experience with  
changing it.

Personally, I think leaving "distasteful" but cross-browser features  
like this out of the spec in the hopes that they will wither away from  
neglect is a poor approach. If browsers feel pressured to implement  
such extensions for Web compatibility then we are not doing anyone any  
favors by leaving them in the domain of mutual reverse-engineering. I  
would prefer to see such features explicitly specified (with suitable  
restrictions) or explicitly forbidden, and perhaps explicitly  
deprecate them with the plan for further limits or outright removal in  
future versions of the spec. But it seems too late to make big changes  
in this regard for ES5. Maybe in the next version.

Regards,
Maciej

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

[Maciej Stachowiak]

On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:

On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich <brendan@...> wrote:

For ES5, this is a tempest in a teapot.

We at Mozilla are trying to remove assignable __proto__ in a near-term release,

Hi Brendan, this is wonderful news!

As reason for skepticism, our v8 folk cite

<http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript>
  

Seems like a fair chunk of those examples are in JS code that's not deployed on public Web sites.

 - Maciej

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

[Mark S. Miller-2]

On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs@...> wrote:

On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:

I suspect we'll see some de-facto stuff come out of one or two vendors who aren't active in TC39 (Apple, Google V8).


Google is quite active in TC39. Google's representatives to TC39 (including me) are now in close coordination with our v8 team. However, v8 remains committed to following WebKit. Fortunately, AFAIK, WebKit has not yet taken any stance on whether [[Prototype]] will be mutable in their ES5 implementation. Maciej?

Your phrasing of the question strikes me as odd, because changing behavior of de facto extensions like this seems orthogonal to supporting a new version of the spec. If getting rid of or restricting mutable __proto__ turns out to be feasible and a good idea, then we would not tie it to implementation timeline for ES5 features.

The tie to ES5 is that ES5 introduces the notion of frozen objects. Together with ES5/Strict function's encapsulation being protected even from non-strict code, this enables the creation of tamper-proof objects. But only if frozen objects cannot have their [[Prototype]] property changed out from under them.

 

As to the substantive issue: mutable __proto__ is something we would prefer not to have, but we are concerned about the compatibility issues. We look forward to hearing about Mozilla's experience with changing it.

In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code.
 

Personally, I think leaving "distasteful" but cross-browser features like this out of the spec in the hopes that they will wither away from neglect is a poor approach. If browsers feel pressured to implement such extensions for Web compatibility then we are not doing anyone any favors by leaving them in the domain of mutual reverse-engineering. I would prefer to see such features explicitly specified (with suitable restrictions) or explicitly forbidden, and perhaps explicitly deprecate them with the plan for further limits or outright removal in future versions of the spec. But it seems too late to make big changes in this regard for ES5.

Agreed.
 

Maybe in the next version.

+100. An exhaustive list of such features should at least be enumerated in a non-normative appendix. If they had, it wouldn't have taken us so long to catch the mutable [[Prototype]] and F.caller issues. What other such issues might we have missed?

In a closely related matter, we also need to tighten the Chapter 16 exemptions, as the presence of these exemptions precludes *any* sound reasoning about JavaScript security. However, I have no clever ideas of what such tighter language should say. Suggestions appreciated.

--
   Cheers,
   --MarkM

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

[Maciej Stachowiak]

On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:

On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs@...> wrote:

 

As to the substantive issue: mutable __proto__ is something we would prefer not to have, but we are concerned about the compatibility issues. We look forward to hearing about Mozilla's experience with changing it.

In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code.

I think that would be a reasonable restriction to apply in light of freezing. I think it would be weird for the spec to require it without specifying __proto__ in the first place, but I think it would be a good idea for browsers that implement mutable __proto__ to do it, if other options do not pan out.

Perhaps to avoid the somewhat nonsensical state of imposing conformance requirements on features that the spec doesn't actually define, ideas of this sort could be provided in the form of non-normative implementation advice.

Regards,

Maciej

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

[Alex Russell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 17, 2009, at 7:34 PM, Mark S. Miller wrote:

> On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs@...>  
> wrote:
>
>>
>> On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
>>
>>
>>> I suspect we'll see some de-facto stuff come out of one or two  
>>> vendors who
>>> aren't active in TC39 (Apple, Google V8).
>>>
>>>
>>> Google is quite active in TC39. Google's representatives to TC39
>>> (including me) are now in close coordination with our v8 team.  
>>> However, v8
>>> remains committed to following WebKit. Fortunately, AFAIK, WebKit  
>>> has not
>>> yet taken any stance on whether [[Prototype]] will be mutable in  
>>> their ES5
>>> implementation. Maciej?
>>>
>>
>> Your phrasing of the question strikes me as odd, because changing  
>> behavior
>> of de facto extensions like this seems orthogonal to supporting a new
>> version of the spec. If getting rid of or restricting mutable  
>> __proto__
>> turns out to be feasible and a good idea, then we would not tie it to
>> implementation timeline for ES5 features.
>>
>
> The tie to ES5 is that ES5 introduces the notion of frozen objects.  
> Together
> with ES5/Strict function's encapsulation being protected even from
> non-strict code, this enables the creation of tamper-proof objects.  
> But only
> if frozen objects cannot have their [[Prototype]] property changed  
> out from
> under them.

The fact that ES5 has the provision for frozen objects doesn't mean  
that all (or substantially most) objects in the system will be frozen.  
I think it's worth considering how useful killing __proto__ will be  
should the Harmony class system NOT freeze objects by default. I  
suspect not very.

Regards

>>
>> As to the substantive issue: mutable __proto__ is something we  
>> would prefer
>> not to have, but we are concerned about the compatibility issues.  
>> We look
>> forward to hearing about Mozilla's experience with changing it.
>>
>
> In case this experiment does run into problems, what do you think  
> about
> Allen's proposed restriction: "That [[Prototype]] is guaranteed not to
> change on an object for which [[Extensible]] is false."? This takes  
> care of
> the security issue I'm concerned about and won't break any old code.
>
>
>>
>> Personally, I think leaving "distasteful" but cross-browser  
>> features like
>> this out of the spec in the hopes that they will wither away from  
>> neglect is
>> a poor approach. If browsers feel pressured to implement such  
>> extensions for
>> Web compatibility then we are not doing anyone any favors by  
>> leaving them in
>> the domain of mutual reverse-engineering. I would prefer to see such
>> features explicitly specified (with suitable restrictions) or  
>> explicitly
>> forbidden, and perhaps explicitly deprecate them with the plan for  
>> further
>> limits or outright removal in future versions of the spec. But it  
>> seems too
>> late to make big changes in this regard for ES5.
>
>
> Agreed.
>
>
>> Maybe in the next version.
>>
>
> +100. An exhaustive list of such features should at least be  
> enumerated in a
> non-normative appendix. If they had, it wouldn't have taken us so  
> long to
> catch the mutable [[Prototype]] and F.caller issues. What other such  
> issues
> might we have missed?
>
> In a closely related matter, we also need to tighten the Chapter 16
> exemptions, as the presence of these exemptions precludes *any* sound
> reasoning about JavaScript security. However, I have no clever ideas  
> of what
> such tighter language should say. Suggestions appreciated.
>
> --
>   Cheers,
>   --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

- --
Alex Russell
slightlyoff@...
alex@... BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFKOb3Mz3jiQlnDlyMRAjs4AKDGJVIMRmDbidcLxHcLh3abwlEtjACgsyty
76mkqqKjDCJNmK0du23n0aE=
=DPv/
-----END PGP SIGNATURE-----
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>
>Personally, I think leaving "distasteful" but cross-browser features
>like this out of the spec in the hopes that they will wither away from
>neglect is a poor approach. If browsers feel pressured to implement
>such extensions for Web compatibility then we are not doing anyone any
>favors by leaving them in the domain of mutual reverse-engineering. I
>would prefer to see such features explicitly specified (with suitable
>restrictions) or explicitly forbidden, and perhaps explicitly
>deprecate them with the plan for further limits or outright removal in
>future versions of the spec. But it seems too late to make big changes
>in this regard for ES5. Maybe in the next version.
>

TC39 provides a venue where I would hope we can do exactly this sort of work.  In addition to actually creating new editions of the standard, there's no reason we can't create and public roadmaps, deprecation plans, specifications for common extensions that are candidates for inclusion in future editions, recommendations for implementers, or whatever we think will be helpful in evolving the language in a way that will maximize interoperability. The main thing necessary for this to happen is a agreement among the members and a commitment from them (us...) to do the work to get it done.

I would think a good initial item would be a TC39 technical report that surveys common browser JavaScript extensions that were not adopted for ES5l, why they weren't, and what their prospects are for inclusion in future versions of the standard. My sense is that collectively we have a pretty good feel for this information and I think such a document could be an influential guide for both implementers and the more sophisticated developers who are most likely to propagate the use of these extensions.  I have a fairly up to date spreadsheet that inventories the Mozilla extensions that I'm aware of that we might use as a starting point.

Allen

 











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

[Mike Shaver]

On Wed, Jun 17, 2009 at 6:34 PM, Mark S. Miller<erights@...> wrote:
> I sincerely applaud this bold stance. If Mozilla proceeds in this manner
> successfully, then the present issue becomes a non-concern; as probably do
> several more we haven't stumbled across yet. Please let us know what we can
> do to help you succeed on this quest. Really. And thanks again!

I suspect that it would be _very_ helpful to have access to data from
Google's shadow copy of the web on where __proto__ appears in web JS.
As Maciej points out, the comp.lang.javascript search doesn't really
help us see how much breakage we would see in the web -- we know there
are certain patterns that would break (that's sort of the point!), but
understanding more about the "live" ones would be a big help.

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

[Allen Wirfs-Brock-2]

>From: es-discuss-bounces@... [mailto:es-discuss-bounces@...] On Behalf Of Maciej Stachowiak

>>In case this experiment does run into problems, what do you think about Allen's proposed restriction: "That [[Prototype]] is guaranteed not to change on an object for which [[Extensible]] is false."? This takes care of the security issue I'm concerned about and won't break any old code.

>I think that would be a reasonable restriction to apply in light of freezing. I think it would be weird for the spec to require it without specifying __proto__ in the first place, but I think it would be a good idea for browsers that implement mutable __proto__ to do it, if other options do not pan out.

>Perhaps to avoid the somewhat nonsensical state of imposing conformance requirements on features that the spec doesn't actually define, ideas of this sort could be provided in the form of non-normative implementation advice.


I agree that it is problematic to spec. things related to extensions that are not part of the spec. In this particular case I wouldn't talk about __proto__ at all. What I would do is specify that the value of an object's [[Prototype]] internal property many not be modified if the value of its [[Extensible]] property is false.

BTW, I haven't yet perceived that we have consensus on putting this into ES5.  My interpretation of  Brendan's initial comments on the matter was that he was opposed to it for ES5.  (I'm sure he'll let us know whether or not that is correct). Personally, while it is a quite plausible embellishment of what we already have specified, I think it is very late for such additions and I'm somewhat skeptical of the actual impact of such prophylactic requirement on implementers who think they have a good idea that collides with the restriction.

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

[Christian Plesner Hansen-3]

> As reason for skepticism, our v8 folk cite
>
> <http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript>
>
>
> Seems like a fair chunk of those examples are in JS code that's not deployed
> on public Web sites.

Much of it is extension and browser implementation code, true. That
would still have to be rewritten unless we go for a model where we
disallow [[Prototype]] changes only for external js.

If you ignore internal js code there still seems to be a fair amount
left: code that runs in all browsers but checks that __proto__ is
present before writing to it or code that is only ever served to or
used with certain implementations (including rhino server-side).

But as Mark said, if these turn out to be non-problems or if we can
work around them then we're very sympathetic to the idea of a
read-only [[Prototype]].


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

[Brendan Eich-3]

On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:

On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich <brendan@...> wrote:

For ES5, this is a tempest in a teapot.

We at Mozilla are trying to remove assignable __proto__ in a near-term release,

Hi Brendan, this is wonderful news!

As reason for skepticism, our v8 folk cite

<http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript>

First page has a lot of Mozilla-only code, of course; I see caja.js at top of second page. We both should evangelize ES5 Object.create when it's ready.

Nevertheless, I'm pleased to report that our v8 folks agree that if Mozilla does this and does not back off because of compatibility problems, they will do so as well. Thanks for being brave enough to jump into this pool first!

Water's fine, really!

* A newborn with no other properties.

For an object that never comes to have any own properties, when is it no longer a newborn?  For example

    function Token() {}
    var tok = new Token();

I didn't define that case fully, but what I had in mind was an object that has not yet gained "own" properties. Such an object might be accessible outside of a lexical scope, though, you're right. If that's a problem then escape analysis, which we are looking at for stack-based GC, might rescue this idea.

* A recent-born in the midst of initialization via evaluation of its object initialiser syntax, where the baby object can't escape, can't be referenced to make a cycle, etc.

How does this arise?

var obj = {foo: 42, __proto__: bar};

Here the object has own properties, foo in this case. But it can't be referenced until after the entire initialiser has been evaluated.

In both cases, would it be true that by the time Object.freeze(x) or Object.preventExtensions(x) returns that x no longer has a mutable [[Prototype]]?

Yes, I agree with you about false [[Extensible]] making [[Prototype]] immutable. Nothing else makes sense.

ES5's Object.create relieves the need for any of this, but legacy code won't be rewritten all at once, so we're probably going to support the above two bulleted cases.

Given that this already isn't a problem for IE and Opera, that v8 follows your lead, and assuming that Apple does as well -- so that these two remain the only exceptions -- do you recommend that the spec adopt stronger wording? (I would find this attractive as well.) Any suggestions for what this stronger wording might be?

It's too late for ES5. It would not necessarily have the effect we hope for, anyway. We need to try restricting assignments to __proto__ and see how that flies.

The idea that the ES5 spec suddenly makes the world more secure by trying circuitously to address old extensions such as __proto__ seems optimistic to me. Better to get rid of the offending extension than try to fence it while not speaking its (I mean ES-unspecififed __proto__'s) name.

Certainly! But until we see how your experiment goes (best of luck!) I am proceeding under the pessimistic assumption that we can't get rid of the offending extension from all ES5 implementations. I'd love to be proven wrong.

We seem to agree, then. This is a matter of implementors reforming implementations, then the spec can follow.

When implementations have bad features in common with each other,

First, there are bad features in ES1-3 not in all implementations of those specs' eras. Nothing in the spec process magically precludes "bad", alas.

Second, bad de-facto standards may be too expensive to codify in a given period (including ES5, especially now). But that doesn't mean implementors can't launch reform initiatives, or web developers can't start reform movements.

Third, even if we could afford to simultaneously specify and deprecate or restrict (e.g., ban from strict mode) bad old forms in a next-gen de-jure standard, if there's no better way for developers to solve the problems they solved with the bad old forms, at least until the next-gen standard is adopted widely, then developers won't tolerate browser vendors breaking the platform the devs built upon, which the browser vendors purveyed.

I've written about using the carrot, then the stick. But the metaphor's wrong: TC39 or another standards body is no horse trainer, and developers are not horses. The mistakes made everywhere should motivate greater humility, in addition to staging of de-jure standards based on de-facto work.

as

with F.caller, then some cross-browser code will have come to rely on
that feature. Then, even if each browser vendor individually believes that the web
would be better off without that feature, they are in the normal
browser competitive bind removing the feature. That's one of the major
purposes of standards committees -- to get de-jure agreement on
changes that all would like to make but that each would be punished
for making by themselves. I think this accurately describes why we
needed a de-jure poison pill for F.caller.

It's plausible; I've talked about the Prisoner's DIlemma at work in the browser market.

However, until widely adopted, a "reformist" de-jure standard is toothless. In the present case it is Mozilla (and others who'll join us) who must take risk in the market trying to restrict assignable __proto__. Ecma TC39 via ES5 (even if it had started the effort in time) couldn't credibly ban assignable __proto__ in non-strict mode.

Given the expanded threat model ES5 seems to enable (see the "Future defensibility from untranslated code" section at the bottom of <http://code.google.com/p/google-caja/wiki/NiceNeighbor>), the F.caller issue, had it not been caught in time, would have cost us a factor of two in performance. The present issue, if unfixed, may well preclude this expansion of our threat model except on ES5 implementations that happen not to have this problem.

I'm glad this was caught. We're just getting into strict mode implementation now, and we have an old access check in the SpiderMonkey F.caller code (Norris Boyd added this in the late '90s, for Netscape's signed script/applet security model), as I mentioned at the TC39 meeting. This suggests reviewing all access checks for strict mode relevance.

/be

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

[Brendan Eich-3]

On Jun 17, 2009, at 9:54 PM, Allen Wirfs-Brock wrote:

> I agree that it is problematic to spec. things related to extensions  
> that are not part of the spec. In this particular case I wouldn't  
> talk about __proto__ at all. What I would do is specify that the  
> value of an object's [[Prototype]] internal property many not be  
> modified if the value of its [[Extensible]] property is false.

As I just wrote in reply to Mark, I'm good with this.


> BTW, I haven't yet perceived that we have consensus on putting this  
> into ES5.  My interpretation of  Brendan's initial comments on the  
> matter was that he was opposed to it for ES5.  (I'm sure he'll let  
> us know whether or not that is correct).

It's late in the game, but a sentence about [[Prototype]] seems  
doable. I defer to you on this, since you're Editor and it'll fall  
upon you to draft the change.


> Personally, while it is a quite plausible embellishment of what we  
> already have specified, I think it is very late for such additions  
> and I'm somewhat skeptical of the actual impact of such prophylactic  
> requirement on implementers who think they have a good idea that  
> collides with the restriction.

This was where I voiced more general skepticism about "security", but  
we can still fix what's known to be broken, if there's time. And I  
foresee no problem for implementors or developers with new ES5 APIs,  
all of which are "opt in", breaking assignable __proto__.

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

[P T Withington]

On 2009-06-18, at 04:06EDT, Brendan Eich wrote:

>>
>> Nevertheless, I'm pleased to report that our v8 folks agree that if  
>> Mozilla does this and does not back off because of compatibility  
>> problems, they will do so as well. Thanks for being brave enough to  
>> jump into this pool first!
>
> Water's fine, really!

Client data point:  OpenLaszlo's class system relied on writable  
__proto__ back in the day.  We eliminated that dependency about 4  
years ago to make our code more portable across browsers (and in  
anticipation of utilizing "real" classes for runtimes that supported  
them, such as Actionscript 3 and the late Javascript 2).

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

[Allen Wirfs-Brock-2]

>-----Original Message-----
>From: Brendan Eich [mailto:brendan@...]
>
>> BTW, I haven't yet perceived that we have consensus on putting this
>> into ES5.  My interpretation of  Brendan's initial comments on the
>> matter was that he was opposed to it for ES5.  (I'm sure he'll let
>> us know whether or not that is correct).
>
>It's late in the game, but a sentence about [[Prototype]] seems
>doable. I defer to you on this, since you're Editor and it'll fall
>upon you to draft the change.
>

OK, I'll put it in.  Here is what I am inserting into section 8.6.2 following the paragraph about [[Prototype]] that comes immediately after table 4:

Every ECMAScript object has a Boolean-valued [[Extensible]] internal property that controls whether or not named properties may be added to the object. If the value of the [[Extensible]] internal property is false then additional named properties may not be added to the object.  In addition, if [[Extensible]] is false the value of the [[Prototype]] internal property of the object may not be modified.  Once the value of an [[Extensible]] internal property has been set to false if may not be subsequently changed to true.

NOTE
This specification defines no ECMAScript language operators or built-in functions that permit a program to modify an object's [[Prototype]] internal property or to change the value of [[Extensible]] from false to true. Implementation specific extensions that modify [[Prototype]] or [[Extensible]] must not violate the invariants defined in the preceding paragraph.



Notice that I also made sure that [[Extensible]] cannot go from false to true which was also previously unstated in the specification.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[P T Withington]

Does making an object not extensible imply/require than the object's  
prototype is also not extensible?

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