HTTPS Everywhere?

[littledan]

@annevk is proposing a requirement that HTTPS be required for basically all new web platform features, which is being discussed in a PR. How should this affect JavaScript? In JS terms, a whole Realm would be either in HTTP or HTTPS mode. I see a few options for policies we could choose:

• Add a new mode, like strict mode or modules. Freeze the language as is in the HTTP mode, and keep evolving it in the HTTPS mode. (I'd rather not go with this option.)
• Keep adding language features which are syntax to all places where JS runs, but only expose new properties on the global object or other objects in HTTPS mode. In WebIDL, the [[SecureContext]](https://heycam.github.io/webidl/#SecureContext) extended attribute stands for this way of hiding new features.
• Decide that this recommendation does not apply to us, for example because it would increase complexity.

There's also a layering question, of what we'd say in our specification (since the ECMAScript specification will not be the one citing HTTPS directly). Are there any other embedding environments besides the Web that may want to implement a similar restriction, which could help be a guide for how to describe these restrictions?

See also WebAssembly/meetings#153 -- I don't see why the policy for WebAssembly should differ from the policy for JavaScript, but maybe others have reasons.

[ljharb]

I'm not sure why this needs to be in the spec; an engine can always choose to only be fully compliant in HTTPS, if "HTTPS" is a thing that exists in the context of that engine.

Separately, what is a secure vs an insecure context in a Moddable engine, or in node? This kind of seems like it's a web-browser-only concept; and if so, it'd either not belong in the spec, or would have to go in Annex B.

edit: were I involved in WASM, I'd have the same response there; it also doesn't seem like a concept that makes sense to be specified in WASM.

[ljharb]

I'm not sure why this needs to be in the spec; an engine can always choose to only be fully compliant in HTTPS, if "HTTPS" is a thing that exists in the context of that engine.

Separately, what is a secure vs an insecure context in a Moddable engine, or in node? This kind of seems like it's a web-browser-only concept; and if so, it'd either not belong in the spec, or would have to go in Annex B.

edit: were I involved in WASM, I'd have the same response there; it also doesn't seem like a concept that makes sense to be specified in WASM.

[allenwb]

ECMAScript is a standard for a platform independent programming language. We should not be adding what is essentially a new language mode that is based upon arbitrary policies that of a single platform (even the biggest platform).

[allenwb]

ECMAScript is a standard for a platform independent programming language. We should not be adding what is essentially a new language mode that is based upon arbitrary policies that of a single platform (even the biggest platform).

[littledan]

@allenwb @ljharb Would it make sense for us to go to the W3C TAG and explain these arguments to them?

[littledan]

@allenwb @ljharb Would it make sense for us to go to the W3C TAG and explain these arguments to them?

[jfbastien]

Is this an official TAG position, or a Mozilla position only?

[jfbastien]

Is this an official TAG position, or a Mozilla position only?

[leobalter]

Add a new mode, like strict mode or modules. Freeze the language as is in the HTTP mode, and keep evolving it in the HTTPS mode. (I'd rather not go with this option.)

I wish we could set a higher bar to ever bring this to a discussion. One requirement should be awaiting for concise feedback of a large use base of module code.

Please let's not introduce any new mode.

For any other thing, I agree with @ljharb and @allenwb on this. I think the W3C TAG can work and decide what's best for what they can produce, I don't see any real indication this should involve ES directly.

[leobalter]

Add a new mode, like strict mode or modules. Freeze the language as is in the HTTP mode, and keep evolving it in the HTTPS mode. (I'd rather not go with this option.)

I wish we could set a higher bar to ever bring this to a discussion. One requirement should be awaiting for concise feedback of a large use base of module code.

Please let's not introduce any new mode.

For any other thing, I agree with @ljharb and @allenwb on this. I think the W3C TAG can work and decide what's best for what they can produce, I don't see any real indication this should involve ES directly.

[rwaldron]

Would it make sense for us to go to the W3C TAG and explain these arguments to them?

No, it wouldn't—I'm confident that the authors independently recognize that secure contexts (spec) are not in scope for ECMA-262.

[rwaldron]

Would it make sense for us to go to the W3C TAG and explain these arguments to them?

No, it wouldn't—I'm confident that the authors independently recognize that secure contexts (spec) are not in scope for ECMA-262.

[littledan]

@rwaldron For context, I expressed skepticism about the policy applying to JavaScript their thread, and @annevk's response was to explain why this is a fine place to add a new, temporary mode. The WebAssembly folks are also considering whether and how the policy should apply to them.

[littledan]

@rwaldron For context, I expressed skepticism about the policy applying to JavaScript their thread, and @annevk's response was to explain why this is a fine place to add a new, temporary mode. The WebAssembly folks are also considering whether and how the policy should apply to them.

[rwaldron]

@littledan my interpretation of that discussion is that they weren't referring to ECMA-262 when they write "JavaScript APIs", instead recognizing it as a shorthand for "JavaScript APIs for Web, specified by W3C or WHATWG or similar".

As for @annevk's response, my interpretation is not at odds: it's not about creating a new "mode" that's relevant to ECMA-262 (or counter to "1JS"), it's about restricting new Web APIs such that they are only available in secure contexts. It makes sense to say: "No HTTPS means No Sensor API" (and similar), but that's not relevant to ECMA-262.

[rwaldron]

@littledan my interpretation of that discussion is that they weren't referring to ECMA-262 when they write "JavaScript APIs", instead recognizing it as a shorthand for "JavaScript APIs for Web, specified by W3C or WHATWG or similar".

As for @annevk's response, my interpretation is not at odds: it's not about creating a new "mode" that's relevant to ECMA-262 (or counter to "1JS"), it's about restricting new Web APIs such that they are only available in secure contexts. It makes sense to say: "No HTTPS means No Sensor API" (and similar), but that's not relevant to ECMA-262.

[msaboff]

As @rwaldron said this may be an issue for JavaScript APIs that are spec'ed by W3c or WHATWG, but this is not a language issue.

From a JavaScript point of view, this is really a non-starter. What should module A, that was loaded over HTTPS, do when it calls into module B loaded via HTTP or something else? Or what should the JavaScript engine do in this case?

[msaboff]

As @rwaldron said this may be an issue for JavaScript APIs that are spec'ed by W3c or WHATWG, but this is not a language issue.

From a JavaScript point of view, this is really a non-starter. What should module A, that was loaded over HTTPS, do when it calls into module B loaded via HTTP or something else? Or what should the JavaScript engine do in this case?

[littledan]

@msaboff I'm confused; I thought scripts were deemed blockable and therefore there would be no mixed content from scripts on a page where some are HTTP and others are HTTPS. I haven't tested locally; I could be misunderstanding this, though.

Anyway, seems like there's a lot of skepticism to applying this sort of policy to the JavaScript language. This seems like useful feedback for the TAG. If anyone else, including people who are in organizations that are both W3C and TC39 members, has an opinion, it'd be great to hear it, cc @ajklein @bterlson @tschneidereit .

[littledan]

@msaboff I'm confused; I thought scripts were deemed blockable and therefore there would be no mixed content from scripts on a page where some are HTTP and others are HTTPS. I haven't tested locally; I could be misunderstanding this, though.

Anyway, seems like there's a lot of skepticism to applying this sort of policy to the JavaScript language. This seems like useful feedback for the TAG. If anyone else, including people who are in organizations that are both W3C and TC39 members, has an opinion, it'd be great to hear it, cc @ajklein @bterlson @tschneidereit .

[littledan]

Further discussion I had with @cynthia on the W3C TAG seems to be pointing in the direction of some TAG members intending to have ECMAScript apply some version of this policy, though the TAG has yet to meet and discuss this topic in particular.

@msaboff I found a note in the WebIDL specification that confirms that a JavaScript global object won't be used on the web in a way that's mixed between secure and insecure contexts, in the [Exposed] section:

Note: Since it is not possible for the relevant settings object for an ECMAScript global object to change whether it is a secure context or not over time, an implementation’s decision to create properties for an interface or interface member can be made once, at the time the initial objects are created.

This seems to indicate that it would be possible to decide, on a realm-by-realm basis, to switch into a different mode and not have to worry about contradictory interpretations for what the global object should be.

[littledan]

Further discussion I had with @cynthia on the W3C TAG seems to be pointing in the direction of some TAG members intending to have ECMAScript apply some version of this policy, though the TAG has yet to meet and discuss this topic in particular.

@msaboff I found a note in the WebIDL specification that confirms that a JavaScript global object won't be used on the web in a way that's mixed between secure and insecure contexts, in the [Exposed] section:

Note: Since it is not possible for the relevant settings object for an ECMAScript global object to change whether it is a secure context or not over time, an implementation’s decision to create properties for an interface or interface member can be made once, at the time the initial objects are created.

This seems to indicate that it would be possible to decide, on a realm-by-realm basis, to switch into a different mode and not have to worry about contradictory interpretations for what the global object should be.

[cynthia]

We touched on this briefly during today's teleconference (and apologies that it took so long) - and as we were pretty sure this would end up as a fairly long discussion, we decided to allocate a time slot during our next face to face. This is scheduled on the first week of April, and we hope to give you an update when we have discussed this at length.

[cynthia]

We touched on this briefly during today's teleconference (and apologies that it took so long) - and as we were pretty sure this would end up as a fairly long discussion, we decided to allocate a time slot during our next face to face. This is scheduled on the first week of April, and we hope to give you an update when we have discussed this at length.

[littledan]

In the end, the TAG adopted a softer version of this policy: we should consider restricting features to secure contexts. The only requirements for secure contexts are cases such as the following:

If a feature would pose a risk to user privacy or security without the authentication, integrity, or confidentiality that is present only in secure contexts, then the feature must be limited to secure contexts.

I don't think TC39 has any features that would pose that sort of issue in its agenda. If we look into adding anything which vaguely touches on these issues, we should strongly consider secure context restrictions. Until then, it doesn't seem to me like there's any action to be taken by TC39.

[littledan]

In the end, the TAG adopted a softer version of this policy: we should consider restricting features to secure contexts. The only requirements for secure contexts are cases such as the following:

If a feature would pose a risk to user privacy or security without the authentication, integrity, or confidentiality that is present only in secure contexts, then the feature must be limited to secure contexts.

I don't think TC39 has any features that would pose that sort of issue in its agenda. If we look into adding anything which vaguely touches on these issues, we should strongly consider secure context restrictions. Until then, it doesn't seem to me like there's any action to be taken by TC39.

[slightlyoff]

For the avoidance of doubt, the TAG was never able to set policy in the first place.

We encourage feature designers to adopt any (and all) changes that encourage an end-to-end encrypted web (consistent with our Finding on the topic). The current advice warns feature designers that they are very likely to be going against the grain and will have significant difficulty in convincing important vendors to ship an implementation without a Secure Context restriction.

It may be helpful for TC39 to note as much to JS language feature designers too.

[slightlyoff]

For the avoidance of doubt, the TAG was never able to set policy in the first place.

We encourage feature designers to adopt any (and all) changes that encourage an end-to-end encrypted web (consistent with our Finding on the topic). The current advice warns feature designers that they are very likely to be going against the grain and will have significant difficulty in convincing important vendors to ship an implementation without a Secure Context restriction.

It may be helpful for TC39 to note as much to JS language feature designers too.