Re: ES3.1 questions and issues
On Tue, Mar 17, 2009 at 10:43 PM, Allen Wirfs-Brock allen.wirfs-br...@microsoft.com wrote: You're correct about map. It had previously used [[ThrowingPut]] rather than [[DefineOwnProperty]]. Actually, that's not the issue. Even when map did [[ThrowingPut]], it was (and is) mutating the newly constructed array, not the object it is iterating over. In the case of exceptional exit, the partially constructed result becomes unreachable, and so is unobservable. Over specification of non-essential requirements is not necessarily beneficial. Certainly. By definition. Bad things are bad. The questions are: how much specification is over and which requirements are non-essential? Saying the result is unspecified is not open an invitation for implementation to expose the user's password or to do anything else that would not be normally part of one of these algorithms. No rational implementation is going to do something like that. Unspecified is more a warning to programmers that if an exception is thrown they should not depend upon the state of the involved objects Conventional developers seek only functionality, and stay away from edge conditions. Attackers seek opportunities in edge conditions. So defenders must reason about the limits on the damage that might be caused by these edge conditions. Put another way, conventional developers must code to the intersection semantics of the platforms in question, since a correct program must work across all these platforms. Attackers can seek opportunities in the union semantics, since an attack that works on any platform is still a successful attack. More deterministic specs narrow the gap between these two. So, in attempting to reason about the security of Caja, ADsafe, WebSandbox, FBJS2, or Jacaranda, we must find some precise codification of your No rational implementation is going to do something like that and pray that we got it right. If defenders and implementers read slightly different things into your something like that, holes will happen. Better to codify this in the spec, as that's what the spec is for: an agreed common understanding to serve as a coordination point for implementers, developers, attackers, and defenders. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 questions and issues
On Wed, Mar 18, 2009 at 9:38 AM, Allen Wirfs-Brock allen.wirfs-br...@microsoft.com wrote: First of all, implementers, defenders, and everybody else will always read slightly different things into any specification. If you want perfectly identical behavior then you don't want a standard instead you want a single universally used implementation. That has its own problems---the word monoculture comes to mind... Like all engineering, building a good JavaScript implementation is a matter of making trade-off among multiple dimensions of requirements and objectives. Security is only one of these dimensions. Implementers must determine in the context of their overall objectives and practical limitations the appropriate balance of between security, performance, robustness, features, etc. If a standard over specifies requirements along any of these dimensions those requirements are likely to simply be ignored by implementations and hence are self defeating from a standards perspective. Agreed. I am seeking a good tradeoff that balances these concerns. I am reacting to your Saying the result is unspecified is not open an invitation for implementation to expose the user's password or to do anything else that would not be normally part of one of these algorithms. No rational implementation is going to do something like that. Unspecified is more a warning to programmers that if an exception is thrown they should not depend upon the state of the involved objects which does not. It leaves all security concerns out in the cold. A single unqualified unspecified in the spec makes the spec useless for reasoning about security. When planning a move in an adversarial game, one must reason not only about what one may do, but also about what one's opponent cannot do. See again the language I propose for sort. While leaving the choice of sorting algorithm unspecified, I place bounds on the range of side effects it may cause even under uncooperative conditions. If we really wish to leave the precise algorithm unspecified for these others, the same qualifying language could still be applied. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 questions and issues
On Wed, Mar 18, 2009 at 12:41 PM, John Cowan co...@ccil.org wrote: All you need to do now is put the above disclaimer in ALL CAPS and add it to each function and method in the standard. It is not, after all, actually *specified* anywhere that the result of evaluating 3 + 4 cannot have the side effect of setting the global variable Ludolf to 3.141592653. If your point is that no disclaimer text is needed here at all, as I stated earlier, I would be happy with that. However, the implication would be conformance to the algorithmic spec as written, which Allen objects to as overspecifying. A blanket anything may happen disclaimer as in the current draft spec fatally underspecifies. Allen's text here is a nice compromise. -- Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 questions and issues
Mark Miller wrote:
On Tue, Mar 17, 2009 at 6:56 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
In all other Array.prototype functions (and some other places) where similar
possibilities exist, I have a situational appropriate variation of a
sentence such as The final state of O is unspecified if in the above
algorithm any call to the [[ThrowingPut]] or [[Delete]] internal method of O
throws an exception.
Oh. I see that now. Searching, I see it in
Array.prototype.{pop,push,reverse,shift,splice,unshift,map}
I could find no other examples.
I think the inclusion of map is a mistake. Map does not mutate O.
For the others, I think unspecified is way too broad.
1) These methods must not modify any frozen properties.
2) The only values they may write into these properties should be
those that might have been written had the specified algorithm been
followed up to the point that the error was thrown. Otherwise, a
conforming implementation could react to a failure to pop by writing
the global object or your password into the array.
3) Is there any reason for this looseness at all? If you simply leave
out this qualifier, then the reading of these algorithms consistent
with the rest of the spec is that the side effects that happened up to
the point of the exception remain, while no further side effects
happen. That assumption is pervasive across all other algorithmic
descriptions in the spec. I think we should just drop this qualifier.
I agree completely, and particularly with points 1) and 2). There
should be very good reasons to make behaviour unspecified or
implementation-defined; here there is not.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES3.1 questions and issues
On Mar 18, 2009, at 11:58 AM, Tobie Langel wrote: On Mar 18, 2009, at 17:20 , Allen Wirfs-Brock wrote: Would it be useful if there was a way to determine whether nor not a function was built-in? That would be useful outside of the security concerns expressed by Mark. I'm thinking about performance and robustness concerns in JS libraries, for example. Can you give an example? We're self-hosting native methods that are called built-in by the spec in TraceMonkey, and I know V8 original self-hosted some Array and String methods. With the right isolation to avoid violating the spec, this is a good thing and it should not be prohibited. Self-hosting built-ins also should not be the subject of second- guessing versionitis in JS libraries. Shades of coding C idioms for the microarchitecture of certain revisions of the x86! /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ES3.1 questions and issues
BTW, by built-in I didn't mean to imply anything about how the function was implemented but simply whether or not it was the implementation provided version of a function specified by the standard. It occurred to me that this information might be useful to framework builder as part of a feature detection protocol used to decide whether or not to install framework provided versions of some such methods. Allen -Original Message- From: Brendan Eich [mailto:bren...@mozilla.com] Sent: Wednesday, March 18, 2009 9:22 PM To: Tobie Langel Cc: Allen Wirfs-Brock; Mark Miller; es-discuss Steen Subject: Re: ES3.1 questions and issues On Mar 18, 2009, at 11:58 AM, Tobie Langel wrote: On Mar 18, 2009, at 17:20 , Allen Wirfs-Brock wrote: Would it be useful if there was a way to determine whether nor not a function was built-in? That would be useful outside of the security concerns expressed by Mark. I'm thinking about performance and robustness concerns in JS libraries, for example. Can you give an example? We're self-hosting native methods that are called built-in by the spec in TraceMonkey, and I know V8 original self-hosted some Array and String methods. With the right isolation to avoid violating the spec, this is a good thing and it should not be prohibited. Self-hosting built-ins also should not be the subject of second- guessing versionitis in JS libraries. Shades of coding C idioms for the microarchitecture of certain revisions of the x86! /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
