Full TC39 and SES meeting notes

Waldemar Horwat
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
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> ->
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
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

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
- 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