Upcoming WHATNOT meeting on 2024-11-28

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10765) and I will post the meeting notes there in a bit. The next one is scheduled for November 28, 1am PST. Note that this is 1 week later in an APAC+Europe friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[nicolo-ribaudo]

As talked about on matrix, we'd like to discuss #9893.

How does joining a WHATNOT meeting work?

[annevk]

@nicolo-ribaudo I invited you and @Ms2ger just now.

[annevk]

Attendees: Domenic, Noam, Nicolò, Anne, Olli, Ms2ger

Scribe: Domenic

Review past action items

• Anne & Dom will take a look at Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow.
  • Dom took a look at the PR Add support for CSS reading-flow #10613 Anne still has work to do!
• Olli will review the Atomic move PR this week.
  • Needs to be carried over.

Carryovers from last time

• None

New topics

• Add Last-Event-ID to CORS-safelisted request headers
• JavaScript ShadowRealm proposal integration

Action Items

• Olli and Domenic to check the Last-Event-ID PR with relevant teams
• Noam to get web developers to comment on ShadowRealm issues.
• ShadowRealm PR to explore the idea of associating ESO with principal realms/globals + ShadowRealms/their globals.

Minutes

Some insertBefore() discussion around whether a second method is justified. Domenic will post something in the issue.

Last-Event-Id:

Anne: want to let people know this is a thing that will probably happen if nobody comments. There is some implementer interest but it's been a while. This fixes an existing leak involving complicated redirect cases bypassing CORS and transmitting UTF-8 bytes.

ShadowRealm:

Anne: wanted a shared understanding of how we're going to proceed with ShadowRealm.

Domenic: concern about lack of implementer interest. Gecko and Chromium are neutral. Mismatch between WHATWG and TC39 working modes.

Anne: WebKit also neutral.

Olli: haven't heard much demand from web developers, apart from Salesforce.

Noam: we heard feedback from the cybersecurity community, but there's a chicken-and-egg situation. "Interesting but not fully baked for the web".

Domenic: our security people wanted to make it clear this is not a security primitive.

Noam: difference between browser security and other cybersecurity, e.g. supply-chain security.

Anne: but ShadowRealm operates in the same process, so there is no security boundary.

Noam: it's a hurdle for third-party libraries to cross realm boundaries. Spectre is nontrivial to achieve.

Anne: I agree this raises the bar, but does not defend against determined attackers. And if the determined attackers create some kind of gadget you’re potentially back at the design table.

Nicolò: security people are not hoping to use the proposal as-is; they'd hide timers etc.

Noam: I will take an action item to get such people to make the case for shadow realm if they want to affect the neutral positions.

Nicolò: process question. Has it ever happened before that TC39 advances to stage 3 despite WHATWG disinterest?

Domenic: never happened before; usually more collaborative.

Anne: Is host integration necessary to move to stage 3?

Nicolò: technically stage 3 only requires tests. However there is some statement possibly from Mozilla that they are only interested in stage 3 if they plan to implement.

Noam: what about Node?

Nicolò: there are use cases, but Node has not been the focus of discussions.

Domenic: should we discuss spec approach like Anne originally intended?

Anne: Maybe, assuming the implementer deadlock is resolved…

Ms2ger: introducing new types of realms without an ESO. Generally need to proxy to ancestor "principal realm". (ShadowRealms can be nested.)

Nicolò: main issue is when there are two realms we need a way of determining the correct one.

Ms2ger: Agreed. Although in a bunch of places it doesn't matter since you can only access function objects cross-realm, not other objects. E.g. in the DOM spec, since all its APIs are in principal realms only, you will only ever see a principal realm.

Even if you look at the realm of a callback, you will be looking at the wrapped version of the callback, so you won't see the ShadowRealm there either.

Anne: so the only APIs that need to care are the APIs we explicitly expose in ShadowRealms, like URL.

Nicolò: two cases.

Creating an object or function: you should always use "non-principal" realm. This prevents mixing object graphs.
Global state in the realm affects what you can do (e.g. policies) or gives info (e.g. what type of environment you are in, to disallow import() in service workers). You should look at the principal realm. This avoids violating preconditions.
We could clone the non-mutable properties and then you would only have to look at the non-principal realm, to simplify spec authoring? Would be editorial.

I think we should follow these rules even if it doesn't matter, for APIs exposed only in principal realms. My principle was "if the shadow realm had its own DOM, which would we use".

Domenic: OK with the above, but alternate proposal: try to craft a situation where spec developers don't need to care.

Anne: concrete suggestion, every spec update to realms everywhere is to principal realm, except creating objects. And we try to eventually fix IDL "new" to do the right thing automatically, but in the meantime you have to reference the non-principal realm.

Nicolò: alternate idea to also minimize spec updates. Always use non-principal realm. We make it so that things like CSP do not exist on non-principal realms so the spec breaks if you try to look up CSP on it. Upside: we don't need to modify every spec to insert "principal" everywhere.

Anne: curious about cases where a spec needs the non-principal realm, apart from object creation.

Nicolò: examples I've seen are modules (map per realm). CSS highlight registry---although that's only exposed in principal realms, so this is theoretical.

Domenic: general pattern seems to kind of be per-realm registries, and module maps are the only current case of that?

Noam/Domenic/Anne: debate the value of ESO vs. realm vs. global object distinction

Noam: Can ShadowRealm's ESOs just point directly to their ancestor's ESO?

Nicolò: I like this idea. We'd have to make some changes to move stuff between global and ESO.

Ms2ger: this gives us a way to decide whether to put stuff on the ESO or the global, whereas before it was kind of arbitrary.

Noam: e.g. high resolution time currently takes globals, but could move to taking ESOs.

Nicolò: why do we have realm/global/ESO anyway?

Domenic: history ^_^

Noam: implementations have multiple globals/realms per ESO today because of extensions!

Domenic: getting back to the strategy question about how to spec---do the right thing always, or minimize spec-writer work?

Ms2ger: minimizing work is nice! But probably next step is to get back to the implementer interest.

Olli: More concrete examples in the explainer would help. What about parallelism?

Nicolò: answer for running things in parallel is workers. Shadow realms give you sync cross-realm access so in parallel is not really realistic.

Olli: yeah but maybe we can make workers better based on ShadowRealm API shape? Also curious about performance overhead of ShadowRealm vs. iframe vs. workers.

(Discussion of history of realm boundaries.)

(Discussion of how to prevent accidentally mixing object boundaries in spec.)

Nicolò: concrete next steps---explore Noam's suggestion of sharing ESOs.

Anne: how often do people go from ESOs to globals?

Ms2ger: a lot it turns out…

(Discussion of how to fix "new".)

Nicolo: related to AsyncContext threading realms through in parallel / queue a task

Anne: W3C team is working on tools for spec static analysis and might be able to find cases of new-in-a-task.

Domenic: not a requirement the solve "new" problem, just make sure all existing correctly-written specs either get updated or keep working as-is.

Noam: "queue a global task" would logically use an ESO instead of a global…

Anne: I guess we could just have queue a global task go get the principal ESO for you even if logically it should be taking the ESO.

(Discussion of general misuses of various spec terms and spec technical debt.)Agenda
Attendees: Domenic, Noam, Nicolò, Anne, Olli, Ms2ger
Scribe: Domenic
Review past action items
Anne & Dom will take a look at Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow.
Dom took a look at the PR #10613 Anne still has work to do!
Olli will review the Atomic move PR this week.
Needs to be carried over.
Carryovers from last time
None
New topics
Add Last-Event-ID to CORS-safelisted request headers
JavaScript ShadowRealm proposal integration
Action Items
Olli and Domenic to check the Last-Event-ID PR with relevant teams
Noam to get web developers to comment on ShadowRealm issues.
ShadowRealm PR to explore the idea of associating ESO with principal realms/globals + ShadowRealms/their globals.
Minutes

Some insertBefore() discussion around whether a second method is justified. Domenic will post something in the issue.

Last-Event-Id:

Anne: want to let people know this is a thing that will probably happen if nobody comments. There is some implementer interest but it's been a while. This fixes an existing leak involving complicated redirect cases bypassing CORS and transmitting UTF-8 bytes.

ShadowRealm:

Anne: wanted a shared understanding of how we're going to proceed with ShadowRealm.

Domenic: concern about lack of implementer interest. Gecko and Chromium are neutral. Mismatch between WHATWG and TC39 working modes.

Anne: WebKit also neutral.

Olli: haven't heard much demand from web developers, apart from Salesforce.

Noam: we heard feedback from the cybersecurity community, but there's a chicken-and-egg situation. "Interesting but not fully baked for the web".

Domenic: our security people wanted to make it clear this is not a security primitive.

Noam: difference between browser security and other cybersecurity, e.g. supply-chain security.

Anne: but ShadowRealm operates in the same process, so there is no security boundary.

Noam: it's a hurdle for third-party libraries to cross realm boundaries. Spectre is nontrivial to achieve.

Anne: I agree this raises the bar, but does not defend against determined attackers. And if the determined attackers create some kind of gadget you’re potentially back at the design table.

Nicolò: security people are not hoping to use the proposal as-is; they'd hide timers etc.

Noam: I will take an action item to get such people to make the case for shadow realm if they want to affect the neutral positions.

Nicolò: process question. Has it ever happened before that TC39 advances to stage 3 despite WHATWG disinterest?

Domenic: never happened before; usually more collaborative.

Anne: Is host integration necessary to move to stage 3?

Nicolò: technically stage 3 only requires tests. However there is some statement possibly from Mozilla that they are only interested in stage 3 if they plan to implement.

Noam: what about Node?

Nicolò: there are use cases, but Node has not been the focus of discussions.

Domenic: should we discuss spec approach like Anne originally intended?

Anne: Maybe, assuming the implementer deadlock is resolved…

Ms2ger: introducing new types of realms without an ESO. Generally need to proxy to ancestor "principal realm". (ShadowRealms can be nested.)

Nicolò: main issue is when there are two realms we need a way of determining the correct one.

Ms2ger: Agreed. Although in a bunch of places it doesn't matter since you can only access function objects cross-realm, not other objects. E.g. in the DOM spec, since all its APIs are in principal realms only, you will only ever see a principal realm.

Even if you look at the realm of a callback, you will be looking at the wrapped version of the callback, so you won't see the ShadowRealm there either.

Anne: so the only APIs that need to care are the APIs we explicitly expose in ShadowRealms, like URL.

Nicolò: two cases.

Creating an object or function: you should always use "non-principal" realm. This prevents mixing object graphs.
Global state in the realm affects what you can do (e.g. policies) or gives info (e.g. what type of environment you are in, to disallow import() in service workers). You should look at the principal realm. This avoids violating preconditions.
We could clone the non-mutable properties and then you would only have to look at the non-principal realm, to simplify spec authoring? Would be editorial.

I think we should follow these rules even if it doesn't matter, for APIs exposed only in principal realms. My principle was "if the shadow realm had its own DOM, which would we use".

Domenic: OK with the above, but alternate proposal: try to craft a situation where spec developers don't need to care.

Anne: concrete suggestion, every spec update to realms everywhere is to principal realm, except creating objects. And we try to eventually fix IDL "new" to do the right thing automatically, but in the meantime you have to reference the non-principal realm.

Nicolò: alternate idea to also minimize spec updates. Always use non-principal realm. We make it so that things like CSP do not exist on non-principal realms so the spec breaks if you try to look up CSP on it. Upside: we don't need to modify every spec to insert "principal" everywhere.

Anne: curious about cases where a spec needs the non-principal realm, apart from object creation.

Nicolò: examples I've seen are modules (map per realm). CSS highlight registry---although that's only exposed in principal realms, so this is theoretical.

Domenic: general pattern seems to kind of be per-realm registries, and module maps are the only current case of that?

Noam/Domenic/Anne: debate the value of ESO vs. realm vs. global object distinction

Noam: Can ShadowRealm's ESOs just point directly to their ancestor's ESO?

Nicolò: I like this idea. We'd have to make some changes to move stuff between global and ESO.

Ms2ger: this gives us a way to decide whether to put stuff on the ESO or the global, whereas before it was kind of arbitrary.

Noam: e.g. high resolution time currently takes globals, but could move to taking ESOs.

Nicolò: why do we have realm/global/ESO anyway?

Domenic: history ^_^

Noam: implementations have multiple globals/realms per ESO today because of extensions!

Domenic: getting back to the strategy question about how to spec---do the right thing always, or minimize spec-writer work?

Ms2ger: minimizing work is nice! But probably next step is to get back to the implementer interest.

Olli: More concrete examples in the explainer would help. What about parallelism?

Nicolò: answer for running things in parallel is workers. Shadow realms give you sync cross-realm access so in parallel is not really realistic.

Olli: yeah but maybe we can make workers better based on ShadowRealm API shape? Also curious about performance overhead of ShadowRealm vs. iframe vs. workers.

(Discussion of history of realm boundaries.)

(Discussion of how to prevent accidentally mixing object boundaries in spec.)

Nicolò: concrete next steps---explore Noam's suggestion of sharing ESOs.

Anne: how often do people go from ESOs to globals?

Ms2ger: a lot it turns out…

(Discussion of how to fix "new".)

Nicolo: related to AsyncContext threading realms through in parallel / queue a task

Anne: W3C team is working on tools for spec static analysis and might be able to find cases of new-in-a-task.

Domenic: not a requirement the solve "new" problem, just make sure all existing correctly-written specs either get updated or keep working as-is.

Noam: "queue a global task" would logically use an ESO instead of a global…

Anne: I guess we could just have queue a global task go get the principal ESO for you even if logically it should be taking the ESO.

(Discussion of general misuses of various spec terms and spec technical debt.)