Should globals from 262's Annex B be part of the intrinsics/stdlib?

[caridy]

No description provided.

[Jamesernator]

A more general question that doesn't seem to be anywhere in the Realms proposal is should Annex B in general be supported by Realms and if so, how?

For example if I had a Realm:

let realm = new Realm()

realm.evalScript(`
    // Can detect the Annex B-ness of the outside environment
    if ('__proto__' in { __proto__: 'x' }) {
        ...
`)

Which feels like a security violation.

Now something I'm aware is that it may be difficult or undesirable for implementations to not support Annex B so perhaps there could be something like:

const realm = new Realm({
    // Where extensions are implementation specific and may be required
    // to create a Realm
    extensions: ['__proto__']
})

Implementations could then mandate that certain extensions are required to be passed, e.g. if an implementation decided it was too difficult to support __proto__ separately it could always require that Realms created use the __proto__ extension.

[ljharb]

I think it is very important that someone can create both a non-annex-b realm, and an annex-b-realm.

[erights]

Let's take inventory of Annex B from software engineering, security, and formal properties perspectives. From all three perspectives, the main issue is that the non-sloppy non-annex-B subset of EcmaScript continue to have good software engineering, security, and formal properties.

If some bizarre property in annex B is already sloppy-only, then there's usually little reason it may not graduate from annex B into the main spec. Doing so will still keep it out of the non-sloppy non-annex-B subset. However, admission controls prohibiting sloppy code should only be assumed to be per realm, so we must also beware of cross-realm leakage of effects from anything we promote into main-spec sloppy-only annex B.

"Authority-free" means that, once the relevant primordials are frozen, the operation provides no ability for non-sloppy code to cause/sense side effects, or even for sloppy code to cause/sense side effects to/from realms other than their own. The operation is free of hidden mutable state, ability to cause I/O, or ability to sense I/O.

"Deterministic" means that its allowed-by-the-spec observable behavior is uniquely determined from its overt inputs. Deterministic operations do not enable a computation to diverge under attempts at deterministic replay. Deterministic operations thus cannot read covert or side channels, though they can still write or modulate them.

"Safe" means Authority-free and Deterministic.

"Dynamically-deterministic" means that its behavior can statically vary from one implementation to another, but cannot vary among runs on the same implementation. The only side channel opened by this is the ability to sense which implementation it is being run on. The only weakening of deterministic replay is that the computation must be replayed on the same implementation.

"Dynamically-safe" means Authority-free and Dynamically-deterministic.

B Additional ECMAScript Features for Web Browsers

• B.1 Additional Syntax
  • B.1.1 Numeric Literals
    Safe. Sloppy-only octal literals can graduate to the main spec. They will still be sloppy-only.
  • B.1.2 String Literals
    Safe. Sloppy-only octal escapes can graduate to the main spec. They will still be sloppy-only.
  • B.1.3 HTML-like Comments
    Dynamically-safe. To prevent injection attacks, it should never be ambiguous or
    implementation defined what syntax is accepted. I don't know what to do here.
  • B.1.4 Regular Expressions Patterns
    Dynamically-safe. To prevent injection attacks, it should never be ambiguous or
    implementation defined what syntax is accepted. I don't know what to do here.
• B.2 Additional Built-in Properties
  • B.2.1 Additional Properties of the Global Object
    • B.2.1.1 escape ( string )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.1.2 unescape ( string )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
  • B.2.2 Additional Properties of the Object.prototype Object
    • B.2.2.1 Object.prototype.__proto__
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.2.2 Object.prototype.__defineGetter__ ( P, getter )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.2.3 Object.prototype.__defineSetter__ ( P, setter )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.2.4 Object.prototype.__lookupGetter__ ( P )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.2.5 Object.prototype.__lookupSetter__ ( P )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
  • B.2.3 Additional Properties of the String.prototype Object
    • B.2.3.1 String.prototype.substr ( start, length )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.2 String.prototype.anchor ( name )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.3 String.prototype.big ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.4 String.prototype.blink ( )
      Safe. de-facto standard and universal. I reluctantly recommend it graduate to the
      main spec. The tag is universally hated, but excluding the tag will do little to mitigate
      its use.
    • B.2.3.5 String.prototype.bold ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.6 String.prototype.fixed ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.7 String.prototype.fontcolor ( color )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.8 String.prototype.fontsize ( size )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.9 String.prototype.italics ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.10 String.prototype.link ( url )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.11 String.prototype.small ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.12 String.prototype.strike ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.13 String.prototype.sub ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.3.14 String.prototype.sup ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
  • B.2.4 Additional Properties of the Date.prototype Object
    • B.2.4.1 Date.prototype.getYear ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.4.2 Date.prototype.setYear ( year )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    • B.2.4.3 Date.prototype.toGMTString ( )
      Safe. de-facto standard and universal. I recommend it graduate to the main spec.
  • B.2.5 Additional Properties of the RegExp.prototype Object
    • B.2.5.1 RegExp.prototype.compile ( pattern, flags )
      Unsafe. Causes observable side effects to frozen objects, violating the object invariants.
      It is dangerous even to leave it as is in Annex B. We should see what we can do to
      further restrict it.
    • The proposed additional RegExp statics
      Unsafe. Must remain in Annex B
  • The Error.prototype.stack from the proposed Error stacks
    Unsafe. That is why it is separated out from the getStack and getStackString operations.
• B.3 Other Additional Features
  • B.3.1 __proto__ Property Names in Object Initializers
    Safe. de-facto standard and universal. I recommend it graduate to the main spec.
  • B.3.2 Labelled Function Declarations
    Safe. de-facto standard and universal. I recommend it graduate to the main spec.
    Sloppy-only, though I see no problem (other than historical) for including it in strict.
  • B.3.3 Block-Level Function Declarations Web Legacy Compatibility Semantics
    Sloppy only. Safe. But really ugly. I do not object to graduating these to the main spec,
    but I cannot bring myself to recommend this either.
  • B.3.4 FunctionDeclarations in IfStatement Statement Clauses
    Sloppy only. Safe. I do not object to graduating it to the main spec,
  • B.3.5 VariableStatements in Catch Blocks
    Why isn't this sloppy only? I recommend that, even if it remains in Annex B, it be mandated
    to be an early error in strict code.
  • B.3.6 Initializers in ForIn Statement Heads
    Sloppy only. Safe. But really ugly. I do not object to graduating it to the main spec,
    but I cannot bring myself to recommend this either.

(Attn @bterlson @allenwb I finally did that inventory we talked about.)

[erights]

After acting on these recommendations somehow, I recommend that anything still remaining in Annex B must be omitted by default from new realms.

[ljharb]

@erights regardless of the default, do you agree it should be easy/ergonomic to create an annex b-compliant ream?

[erights]

@ljharb If the underlying implementation simply omits some annex B features completely, as it is allowed to do, then it would be bizarre to require it to implement these features anyway in order to support this non-default annex-b-compliant realm option.

The most that could make sense is for the non-default annex-b-compliant realm option itself to be an annex B feature. I think this would indeed make sense.

[erights]

A very concrete example: When creating a non-annex-B realm (presumably the default), the Realm class created as part of that new realm must itself not have an option to create an annex-B realm.

[caridy]

@Jamesernator

Implementations could then mandate that certain extensions are required to be passed

I don't think that's how annex-B works. It is either all or nothing from what I recall.

@ljharb

do you agree it should be easy/ergonomic to create an annex b-compliant realm?

Can this be done in user-land? We could look over annex-B and see if there is something that can't be implemented in user-land.

[ljharb]

@caridy I don't think it should be. Annex B is very complex, and i think it'd be too easy to get it wrong.

[erights]

If my suggestions above are taken, then all that's left in annex B is

B Additional ECMAScript Features for Web Browsers

• B.1 Additional Syntax
  • B.1.3 HTML-like Comments
    Dynamically-safe. To prevent injection attacks, it should never be ambiguous or
    implementation defined what syntax is accepted. I don't know what to do here.
  • B.1.4 Regular Expressions Patterns
    Dynamically-safe. To prevent injection attacks, it should never be ambiguous or
    implementation defined what syntax is accepted. I don't know what to do here.
• B.2 Additional Built-in Properties
  • B.2.5 Additional Properties of the RegExp.prototype Object
    • B.2.5.1 RegExp.prototype.compile ( pattern, flags )
      Unsafe. Causes observable side effects to frozen objects, violating the object invariants.
      It is dangerous even to leave it as is in Annex B. We should see what we can do to
      further restrict it.
    • The proposed additional RegExp statics
      Unsafe. Must remain in Annex B
  • The Error.prototype.stack from the proposed Error stacks
    Unsafe. That is why it is separated out from the getStack and getStackString operations.
• B.3 Other Additional Features
  • B.3.5 VariableStatements in Catch Blocks
    Why isn't this sloppy only? I recommend that, even if it remains in Annex B, it be mandated
    to be an early error in strict code.

Some of these are impossible to emulate for good reason! They also must not be present by default, and not accessible from a non-annex-B realm, even indirectly through that realm's Realm object.

[littledan]

Lots of people want to use Realms to emulate JS environments that they care about. Many of those environments have Annex B enabled. My intuition is that it would be OK to let environments control the Annex B-ness of a Realm; In that case, I'd expect many environments to match the surrounding context (e.g., on the Web, Annex B would be enabled both inside and outside of Realms). Then, maybe we could provide more control over whether Annex B is disabled in a future Evaluator/Compartments proposal.

[caridy]

That matches my mental model as well. However, it is not clear to me where does that happen, maybe some intersection here with #230.

Can someone confirm if Annex B is being taking care of by the following line:

Create any implementation-defined global object properties on globalObj.

[erights]

... Annex B ...

After our consensus on Annex B reform, what globals from Annex B remain an issue?

Create any implementation-defined global object properties on globalObj.

Is this about host objects? Or does it mean something else by "implementation-defined"?

[allenwb]

@erights It was originally intended to mean all implementation provided global properties which are non normatively defined by ECMA-262.

[erights]

Where you do not distinguish between an implementation (e.g. v8) and a host (e.g. chrome)? If so, then these are host-provided host objects. No relationship to Annex B. Thanks.

[caridy]

@allenwb thanks for the clarification.

[littledan]

I like @ljharb's idea to make it clear that implementations and hosts are expected to not add extra properties to the global objects of new Realms, so now there's spec text indicating that intention, in the description of the host hook in #230 . Hopefully that clears things up for anything not in the ES specification.

@erights My understanding is that "implementation-defined" as @allenwb has used it includes host-defined here.

Given that the "consensus" on the future of Annex B is a little incomplete (we don't seem to have anything merged into the main spec yet), I want to suggest that we refrain from mandating the removal of any globals in the Realm API, and continue to leave it implementation-defined whether to implement Annex B in Realms. Is that an acceptable conclusion to this issue?

[caridy]

Given that the "consensus" on the future of Annex B is a little incomplete (we don't seem to have anything merged into the main spec yet), I want to suggest that we refrain from mandating the removal of any globals in the Realm API, and continue to leave it implementation-defined whether to implement Annex B in Realms. Is that an acceptable conclusion to this issue?

@littledan yes, at the SES meeting we discussed this, and we agreed with that conclusion. There is still a small detail to be figured in terms of the wording in PR #236, we can keep this open until that is merged.

[erights]

For reference, that SES meeting is at https://www.youtube.com/watch?v=TbIAScAcga8&list=PLzDw4TTug5O1jzKodRDp3qec8zl88oxGd

[Jack-Works]

I see this issue has a stage 3 blocker tag. Is there a conclusion for this? I didn't see this is mentioned in the spec.

• "Inherit" host behavior about annex B (including syntaxes)
• Default has annex B turned off

The two options above both look good to me and to achieve virtualization, it should be configurable by programmers. (what should do if the engine is not implementing annex B for some reason e.g. embedded system)?

[ljharb]

The arguments I've heard for not separating these boil down to "most web devs don't know or care about the difference between browsers and the language, and it will be confusing for them".

This is a compelling argument (whether I think "most" is correct or not) - but only an argument for "what the default should be". It is not an argument for "actively obstructing and blocking the use cases of those that do know and care about the difference".

[leobalter]

"Inherit" host behavior about annex B (including syntaxes)

IMO, this is the implicit behavior from HostInitializeSyntheticRealm, which lists fundamental requirements. Although, that's again something valuable to be part of the HTML integration. I don't believe Realms should bring a ECMAScript capability that allows Annex B to be turned on off.

If the requirements from HostInitializeSyntheticRealm are met, it's still possible to meet the goals of this proposal and its use cases. That matches what @ljharb has said above.

[leobalter]

The proposal spec offers no distinction on the Annex B names. @caridy @littledan, WDYT?