Full TC39 and SES meeting notes

Waldemar Horwat waldemar at google.com
Thu Jan 29 16:05:07 PST 2009

Here are my meeting notes from all three days of the meeting.


SES meeting Jan 27 2009:

ES3.1 opens up the possibility of exposing protected objects to unprotected code and have the protected objects stay safe.  Maybe not:  toSource, watch (to set watchpoints on properties), Mozilla's two-argument eval, debugging interfaces, ES3.1 code deliberately causing a stack overflow in a specific place in secure code, ...?

If foo is a function stored into myProtectedObject, myProtectedObject.foo(args) can leak myProtectedObject to foo.  Fixes:
1.  (true && myProtectedObject.foo)(args)
2.  Wrap foo when storing it into a property of myProtectedObject

Lots of practical security trouble caused by called methods re-entering the calling object, doing recursive calls.

ES3.1 Object.getOwnProperties can enumerate all properties, including non-enumerable ones.  This may allow blacklisting runtimes to delete properties they don't know about, as long as they're deletable.

Allen: Things will stay confusing unless we define the behavior of multiple global objects and how objects interact between them.

The trouble with proxies:  We can write a proxy for some of the things that JavaScript does, but proxying the proxy itself is problematic.  The analogue to microprocessor instruction set virtualization breaks down because for microprocessors there is a clear boundary between instructions and software: emulating all supervisor instructions is sufficient, with libraries running virtualized.  With JavaScript the DOM would not be running virtualized, and it's problematic to locate all places where property lookups could show through.

Proxying a property with a getter/setter pair -> need to resolve the problem of someone setting an expando in a derived object (behavior differs for setters) -> need to resolve the problem of someone calling getOwnProperty, hasProperty, for-in, etc. -> ...

W3C:   Need to work with W3C to make the DOM secure.
All DOM nodes are connected via parents to document root, which then allows access to the network.
Style sheets are in a single global namespace -- problem for ads, mashups.  Can use iframes, but want some inheritance for backgrounds and such.

- A frame-like thing within a document that comes from the source
- Modifications in the way events bubble
- Looking up elements by id in a subtree (but may also need to exclude virtualized subtrees to avoid inadvertent or deliberate id collisions)
- Impact of the DOM model on Caja-like isolation
- Feeling of the DOM being too complicated (of course, discussing such generic feeling won't go anywhere)

Adoption Agency algorithm:
<b><i>foo</b>bar</i> -> <b><i>foo</i></b><i>bar</i>
Problem is that it can clone unique id's:
<b><i id=100>foo</b>bar</i> -> <b><i id=100>foo</i></b><i id=100>bar</i>

Clever history attack that works even on DOMs that masquerade programmatic queries to visited links as though they were non-visited:
Set the height of visited links to 100; then query the position of some element after the link to see how high on the page the browser layout put it.

HTML names and id's are reflected as properties of the global object (but won't shadow existing globals).

Microsoft Web Sandbox:  websandbox.livelabs.com:  ~300K of JavaScript source for the sandbox, ~28K compressed minimized, almost all of which is policy rules and emulators on DOM calls and such.  Apache open source.

TC39 meeting Wed Jan 28 2009:

John and Allen want a flag date to issue s press release about a candidate spec.  Change control may be locked down after that?
Waldemar:  ECMA should not be the editor.  Changes need to be made by a technically savvy editor.
Waldemar's concern:  document has been evolving too quickly, and each time he reviews the document he needs to re-read the whole thing which takes a long time.  Proposed two levels of change bars after a settle-down date, with changes from ES3 -> settle-down date tracked with a different color from changes settle-down date -> head revision.

New schedule:
March 1st: proposed candidate specification
sometome between March and May:  Candidate specification
Web testing through July
Wording/typo/etc. fixing through September
Submitted to December GA

Need to remove ToObject from base when making references:
function foo() {return this}  (in strict mode)
foo.call(3) -> returns a primitive (i.e. non-wrapped) 3
String.prototype.foo = foo
"bar".foo() -> needs to return a primitive too

Question:  what if the function does:
function foo() {this.x = 5}
Answer:  in non-strict mode, works as before.  In strict mode, throws an exception due to an attempt to set a property on a primitive.

Use a ::: instead of : grammar to describe use directive syntax in chapter 14.  There are other examples of such usage in chapter 15 that can be used as a guideline.  Also should describe white space using the lexar grammar, not the syntactic grammar.

[[Class]] == "String", "Date", "RegExp", "Array", "Function", ...
Need [[IsArray]]?  Is [[Class]] trustworthy?
Should we enforce constraints on host objects of these classes?
Strawman:  Host objects should only be able to do what native objects can do -- doesn't work for host functions that can access data outside the ECMAScript environment.
Many of the invariants are enforced by native constructors' behavior, not by constraints on native objects.
+ Change instances of "is an Array object" to "[[Class]] is "Array"", etc.
+ Write specifications on invariants that host objects must ssatisfy in order to use one of the above [[Class]] values.  Who will do it?

Dealing with multiple global objects:  Informative annex to 3.1?  A Technical Report would be more appropriate.

Should bind curry over [[Construct]]?
- Agreed to use option 2 from Allen's list:  bind will curry over [[Call]] and [[Construct]].  The bound closure will not have a prototype property -- [[Construct]] will use the prototype of the original function just as it normally would.

Should bind result in a frozen function?
- Agreed that bind does not result in a frozen function.

When is eval direct?  Strict?
- Agreed to keep the current two conditions of a direct call named "eval" and the function actually evaluating to the built-in eval function.
- Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
- Agreed that indirect eval is strict if and only if the eval'd string starts with a use strict directive.  Direct eval is strict if the calling context is strict or ir the eval'd string starts with a use strict directive.
- Agreed that indirect eval calls will use their own little private scope for newly introduced bindings in strict mode (as determined by whether the eval'd string starts with a use directive), even if they're called at the global level.

Should apply be specified like an array generic?
- Agreed that it should be generic.  This will also make it explicit what happens if there are holes in an array.

Should numerically named properties of strings be enumerable?
- Yes.

Parse time error reporting ("strict")
- "detection does not require program execution" is too vague.  Agreed to retain the "must" as long as individual cases are listed instead of "detection does not require program execution".

Regexp lookahead
- Rejected the ticket.  Rejecting quantifiers syntactically would be a breaking change and make grammar syntax more complicated.  There is a use for quantifiers after lookaheads -- executing a quantifier zero times is different from executing it once, and the differences can be observed via capturing parentheses.

Name properties of getter/setter functions defined in object literals.
- Property values for function <name> are "get <name>", "set <name>", "bind <name>".  They do not show up on the scope chain.

Multiline comments:
See http://bugs.ecmascript.org/ticket/414
- Agreed to retain the specified ECMAScript behavior:  a multiline comment counts as if it were a line terminator.

11.1.4:  Replace [[Put]] of length with DefineOwnProperty.  Generic array algorithms will continue to be done using [[Get]] and [[Put]] (this is important for folks who define length properties as getter-setter pairs).

JSON throws a SyntaxError when it detects a problem with the input.  This is the first instance of throwing a SyntaxError based on what's typically user input data.  Suggestions were made for using a FormatError or JSONError.  Reluctantly we decided to keep SyntaxError, mainly due to compatibility with existing JSON libraries.  This means that users who catch SyntaxErrors hoping to catch JSON errors will catch things that are not user data errors as well if, for example, the ECMAScript program constructs faulty regular expressions or eval's code with syntax errors.

What causes the arguments object to get un-joined with local argument variables?
- Allen's current approach (changing enumerability or configurability doesn't matter, changing value breaks joining) seems like the right approach.
- Agreed that in strict mode there is no joining of arguments objects to local variables.
- Agreed that arguments objects are *not* frozen in strict mode.  There are important use cases for mutating them, such as stripping off initial arguments using shift and passing the rest to another function.

TC39 meeting Thu Jan 29 2009:

Trying to make a liaison with W3C.  Lawyers complaining about intellectual property requirements mismatch -- royalty-free (W3C) vs. rand (ECMA).  The intersection of these is royalty-free.  There is precedent for doing this in ECMA -- Microsoft made a rand-z (zero royalty) commitment for their C# work in ECMA.

W3C interested in colocating an ECMA TC39 meeting with their large meeting in Santa Clara in early November.

Sam Ruby is the co-chair of the HTML Working Group.

There is a W3C group working on an ECMAScript binding for the DOM (WebAPI Working Group).

We scheduled the rest of the 2009 meeting dates:
  Mar 24-26  Yahoo, Sunnyvale CA
  May 27-29  Mozilla, Mountain View CA
  Jul 28-30  Microsoft, Redmond WA
  Sep 15-17  bay area
  Nov 3-5    Santa Clara CA, colocated with W3C

Pratap demoed a modified IE8 implementation of a number of ES3.1 features: bind, attribute reflection, and a preliminary strict mode.  He also has about 200 tests; the intent is to make these available.  There was much rejoicing among the natives.

Ihab and Kris's module system strawman presentation (see documents Ihab sent out).  Interesting proposal.  Provoked much debate:
- HATE is all we need?
- Module identifier issues:  If these are executable, they can cause trouble.  On the other hand, don't want to limit their expressivity.
- The claim that the loader can be left unspecified is unsafe.  This can enable cookie-stealing and other nefarious activities.
- Hermetic eval slide issues:  If you don't verify the syntax of the eval'd code, it can jump out of the boilerplate opening parentheses and then return something that closes over its own state.  Two invocations of the resulting function could then talk to each other.
- Primordial environment issue:  If hermetic eval provides its own definitions of Array, etc., how does instanceof behave when communicating with hermetic eval'd code?  Having differing notions of arrayness causes all kinds of trouble in practice.
- Cannot intern modules if there is no equality defined on module names.  Would be easy if they were constrained to be strings, but Kris doesn't want to constrain them to such.  The other possible test is the object identity test, but that's impractical to use and leads to exploitable loaders.
- Don't want to have sugar for module names as identifiers because that would encourage short module names which would collide.
- Why have different mechanisms for getting definitions from the environment and from imported modules?  Why not make everything into a module?  Part of the argument for separating them is that modules are compute-only and cannot do i/o, but we may also have prepopulated modules that do have i/o capabilities.  The argument against separating them is that it makes versioning of things in the environment hard; implementations may wish to use external modules to replace environment functionality on older browsers that don't have the functionality built-in to the environment.  Currently this is done via monkey-patching, which is not possible here.
- The usual disapproval of "with" in the export salt.
- Recursive dependencies between modules?  The beget approach was proposed, but it allows partially set up modules to leak through by examining the prototype.  If module A imports B which then imports A, then B will unknowingly see a partial A and, if it's malicious, can modify some of its exports (via prototypes) since they aren't frozen yet.
- Good to see catch-all imports gone from the proposal.
- Stage separation issues (macro or type system example).  See PLT Scheme for Mark's favorite solution to such issues.
- Related to that:  prefetching modules -- fetching a module over the net asynchronously, without waiting for the import function to complete before continuing with other things.
- How many hermetic eval variants do we need?  They all need to verity that the value is in fact a function, not, say, an expression that closes over a function.  We also may need options to provide either the existing primordial environment (to load modules into an existing one), a completely fresh primordial set (with only built-in global objects), or a fresh set of frozen primordials (same as before but can be safely shared between different modules).
- Need IPR release from Kris to consider his work in any ECMA committee.

ES3.1 currently states that "this" at the top level in strict mode is undefined, not the global object.  This prevents people from portably referring to the global object, other than through a DOM binding.  Agreed to revert it so that "this" refers to the global object at the top level.

Decimal in Harmony:  Wrappers or no wrappers?  Remain in agreement that wrappers are needed for consistency with ES3.1, as long as Number continues to have wrappers.

Mark wants general operator overloading instead of adding Decimal as a one-off.  Brendan: decimal semantics are needed anyway, as per one of the most-reported Mozilla bugs.  Some kind of exact symbolic arithmetic mode is likely impractical.  Also, Mark's proposal does not allow overriding ===, but Decimal needs nonstandard semantics for ===.

Operator overloading use case:  Package A defines complex.  Package B defines rational.  Package C wants to use both A and B, but neither one knows how to do == with respect to the other.
Now suppose A wants to upgrade his complex library to define the heterogeneous comples == rational operator, but does not want to pull in package B unless the ultimate client C uses it.  Without pulling in package B, package A cannot do an instanceof test to detect rational numbers.

To solve the above, we'd want time-reversed weak references.  Traditional weak references point to an object for a while but might turn empty if the object is garbage-collected.  Time-reversed weak references are born empty but might become an object (such as the Rational type) if it is ever interned (brought into the system).

Unusual Decimal proposal:  have numeric constants evaluate to Decimal instead of Number (where "Number" means the existing binary floating point).  Arithmetic contagion of Numer and Decimal is towards Number [sic].  Conversion of strings to numbers produces Decimal.  Transcendental functions, π, etc. produce Numbers.  Might be problematic for those who use 1e400 to represent infinity.


More information about the Es-discuss mailing list