Here are my meeting notes from all three days of the meeting.
Waldemar
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.
Desirables:
- 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.
Proposal:
+ 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:
break/*
*/foo;
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 10.4.1.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.
Adjourned.
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
