Obsolete this document

[littledan]

The JavaScript WHATWG spec is pretty small and largely subsumed by TC39 work. There are just a few things left. Ideally, we would bring the remaining items into ECMAScript (e.g., library features like __defineSetter__ and RegExp legacy $1 properties) and just leave it to HTML/WebIDL to reference ECMAScript and require Annex B. Now that there's the stage process and ecmarkup, we could even have spec text which is at an earlier stage to describe certain features where consensus doesn't yet exist.

@annevk @domenic @mathiasbynens What do you think?

[mathiasbynens]

👍, being superseded by the ECMAScript standard has always been the goal.

Compared to its first release (even before https://rawgit.com/whatwg/javascript/e244c5996edeabfbb614a9a5e2d40303068d26b5/index.html), the JS spec has become ridiculously small and the remaining bits are underspecified.

[annevk]

Looking through the document these things are left:

• Requirement on Annex B and Unicode version.
• Requirement on Date.UTC.
• RegExp, including Octal escapes in regular expression literals (including in strict mode), RegExp.$1-$9, and RegExp.lastMatch / RegExp["$&"] (last one not actually defined).
• __defineGetter__, __defineSetter__, __lookupGetter__, and __lookupSetter__.

I think the Unicode version is being bumped by TC39. Requiring Annex B could be something HTML does.

Are there issues filed against https://github.com/tc39/ecma262 for the remainder?

[littledan]

The process isn't to file bugs for feature requests (those are being closed), but to write an explainer document and link it as a stage 0 proposal/get it on the agenda for a TC39 meeting. I don't think there are bugs or documents for any of these. If anyone wants to champion these things at TC39, I'd recommend starting with the getter/setter functionality. I can see some old mailing list posts about some of these issues, and there was some disagreement, but I think it can be worked through. For RegExp properties, maybe if there's some arrangement for them to be safely disable-able then they could be standardized.

@ljharb You've done some work on adding some standard library functions. Any interest in these (or Date parsing)?

@erights Could you summarize/tell me where I can find information on previous discussions/why these were not included in ES2015?

[annevk]

@littledan these are not feature requests though. These are implemented by all engines and the web most likely depends on them. Classifying those as feature requests seems misguided.

[ljharb]

@littledan I've got a pretty big list, and Date functions, RegExp static properties, and dunder methods frighten me. That said I'll be happy to help wherever I can.

[littledan]

What frightens you about them? (If you don't do this, then whoever else takes it up should take that into account.)

[domenic]

Think of it this way: here's your chance to go from stage 0 to stage 4 in a single meeting ;).

[annevk]

Dunder methods is tc39/ecma262#381 now. Paging @claudepache to see if he's interested in the remainder of the list. 😊

[erights]

The RegExp statics are mutable global state and a global communications channel.
https://github.com/google/caja/wiki/RegexpsLeakMatchGlobally
Their existence must not be normative, so that a system (like SES's repairES5) that removes them produces a state that is still considered a conformant ES implementation.

Regarding the RegExp statics, the important issue is
http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable
which we should propose and make normative. I just verified that Chrome 48.0.2564.103 ships with these statics configurable, and actually deletable, demonstrating that it is web compatible to require this.

[littledan]

@erights How would you feel about standardizing these RegExp properties with the semantics that Chrome ships?

[erights]

I am certainly against specifying these as normative. As I say above:

Their existence must not be normative, so that a system (like SES's repairES5) that removes them
produces a state that is still considered a conformant ES implementation.

However, in light of Claude's point at tc39/proposal-regexp-legacy-features#3 and my reply at tc39/proposal-regexp-legacy-features#3 (comment) , if inter-realm leakage were also banned, I would see benefit to these being normative-optional rather than continuing as unspecified. i.e., where there is no normative requirement that they be present, but there is a normative requirement that, if they are present, then

• they must actually be deletable. If deleted, they do not magically reappear.
• they must not leak info cross realm.

With these, yes, I think I would support normative-optional.

[littledan]

What if they're in the existing primordials, and deleting them takes effect? Does Chrome 48 make them sufficiently deletable, or are additional changes needed?

Beyond that, what does it mean that for something to make sure not to not leak cross-realm? Seems like with deletion, SES will have all the tools it needs.

Does Annex B suffice for normative-optional?

[erights]

What if they're in the existing primordials, and deleting them takes effect?

I don't understand the question. Rephrase?

Does Chrome 48 make them sufficiently deletable, or are additional changes needed?

From my testing, they seem to be sufficiently deletable on Chrome 48. The reason I specified "deletable" explicitly is that a property may legally be both configurable and not deletable. We need to ensure that these are actually deletable (as they are on Chrome)

Beyond that, what does it mean that for something to make sure not to not leak cross-realm?
Seems like with deletion, SES will have all the tools it needs.

I thought so until I saw claude's example. The issue is, what happens when a RegExp.prototype.exec method from one realm is applied to a RegExp instance from another realm. In this cross realm case, info must not leak to either, even if the properties are not deleted.

Does Annex B suffice for normative-optional?

I should double check the language, but yes, I believe so. That's what I had in mind.

[littledan]

I don't understand the question. Rephrase?

I was getting at my understanding of Chrome 48 semantics, so you answered my question.

The issue is, what happens when a RegExp.prototype.exec method from one realm is applied to a RegExp instance from another realm. In this cross realm case, info must not leak to either, even if the properties are not deleted.

I'm not sure if I understand the threat model here. Why wouldn't SES be applied on each realm individually, if these are same-origin realms that are supposed to be isolated? If SES, or another system which freezes things and deletes those problematic RegExp properties, isn't applied to one of them, then I think there are other communication channels besides running RegExp.prototype.exec (for example, simply setting a property on something). Is the idea that it's more ergonomic to just recursively freeze things, and we have to protect against a naive system which would simply do that and fail to first remove those properties?

[erights]

(Attention @dtribble , @FUDCo )

An example:

Standard SES assumes that it is in contact with non-SES realms, and so defensive SES code must be able to defend its integrity and security properties from objects from non-SES clients. Within SES, an object which is correctly judged to have no references, transitively, to mutable state is judged to be deeply frozen. Because of encapsulating functions, SES code is often not able to judge an object to be deeply frozen even if it is. But, if it engages in valid tests, it must never judge as deeply frozen an object with an overt (or semi-overt[1]) channel to others.

SES code may validly share such objects across subgraphs that must not be able to communicate, either to each other or to outside collaborators. The deep-frozen check must ensure that such sharing has indeed denied them a communications channel. If within SES realm R a deeply frozen exec method from non-ses realm A is applied to a deeply frozen regexp instance from non-ses realm B, this application must not leak non-local information.

You may ask, if B's RegExp constructor is unsanitized, how can B's regexp instance seem to be deeply frozen? The least change answer is if B has set RegExp.prototype.constructor to hide the real constructor, and then transitively freezes all primordial state reachable from RegExp.prototype. This is what user-land SES actually does today when it needs to! Special detection of the RegExp special case does not work, because code in the standard SES realm has no way of distinguishing userland SES code from an attacker.

I could spin many more such examples, but I trust I don't need to. Leakage of overt or semi-overt information by paths outside the object graph are inherently dangerous. That is why I have spent a huge amount of time killing function.caller and function.arguments on sloppy functions. The additional prohibition that sloppyFunction.caller may never reveal a strict function is exactly the same kind of issue we're discussing here. A SES realm has no sloppy functions. But defensive code in a SES realm must be able to defend itself from a non-SES adversary it is in contact with, including a sloppy function it calls.

[1] I refer to the weakreference leakage, that the weakref proposal is plugging in the same way between realms, as a semi-overt channel because it is reliable on one side but not on the other. If the observer detects that a target has become garbage, it is guaranteed that the signaller signalled. There's nothing probabalistic about it. But, because gc might be arbitrarily conservative, if the observer does not see the signal, it does not gain reliable info about whether the signaller signalled.

[erights]

With the weakreference comparison in hand, it is worth point out that it leaks less than 1 overt bit per incident. The string leakage we're talking about here is the immediate overt leakage of arbitrary strings, by obvious means.

[claudepache]

Reviewing the remaining items:

• Requiring Annex B implementation. Already in ECMAScript, see the first sentence of Annex B.
• Date.UTC. Chakra disagrees with your semantics, see Remove Date.UTC after tc39/ecma262#642 is merged #31 (comment); so that it is likely not required for web compatibility.
• Octal escapes in regexp. This is already specified in B.1.4 Regular Expressions Patterns (search for LegacyOctalEscapeSequence in that section). Note that "sloppy" regexp pattern semantics are also applied in strict mode (contrarily to string literals).
• RegExp.$1-$9, .lastMatch should be subsumed by https://github.com/claudepache/es-regexp-legacy-static-properties (stage-0 proposal).
• Function#toString will be subsumed by https://github.com/tc39/Function-prototype-toString-revision (stage-3 proposal).

[claudepache]

Also, absent from this document but possibly needed for web compatibility:

• Function#caller and #arguments. Some people think it should not be included in ECMAScript, see Add Function#caller and Function#arguments to Annex B tc39/ecma262#562.
• String#trimLeft and #trimRight. Will likely be included in ECMAScript as compatibility aliases of String#trimStart and String#trimEnd, see https://github.com/sebmarkbage/ecmascript-string-left-right-trim (stage-1 proposal).
• error stack. Implementations are disagreeing on the semantics. There is a rumor about intention to standardise it.
• Array#join (and #toString, #toLocaleString), additional measure for dealing with cyclic structures, see A.p.join on cyclic arrays does not reflect web reality tc39/ecma262#289 and https://gist.github.com/anba/4a154bd7143bf2bab3ef
• one should also check whether regexp pattern semantics are completely specified in ES.

[ljharb]

@claudepache I'm indeed working with @erights to attempt to standardize error stacks in ES.

[domenic]

I noticed that as of six days ago this spec seems to have indeed evaporated, as @mathiasbynens removed all the stuff that was covered by in-progress proposals. https://javascript.spec.whatwg.org/ seems to have no normative content anymore.

I wonder if we should pack up and go home on this repo? Maybe leave a readme with the contents of #36, and redirect https://javascript.spec.whatwg.org/ to that readme?

[mathiasbynens]

@domenic 👍 However, instead of a README that would have to be maintained, I’d rather link to https://github.com/tc39/ecma262/labels/web%20reality and file (closed) tracking issues for the contents of #36.