ES3.1 questions and issues

Mark S. Miller erights at
Wed Mar 18 10:26:45 PDT 2009

On Wed, Mar 18, 2009 at 9:38 AM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at> 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.


More information about the Es-discuss mailing list