Upcoming WHATNOT meeting on 2025-05-29

[annevk]

Today's meeting was canceled (#11307). The next one is scheduled for May 29, 4pm PT. Note that this is 1 week later in an Americas + APAC friendly time.

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

[pmeenan]

If possible, I'd like to talk about #8143. Specifically the proposal to run an origin trial in Chrome for the compression dictionary use case and the usefulness, if any, for being able to mark same-origin responses as opaque.

[pmeenan]

Just checking to see if I should add the agenda+ label or if the editors will if it is accepted for the agenda and if the meeting details are available somewhere if I was to join.

[cwilso]

@pmeenan oops, sorry! I added it to the agenda and forgot to add the agenda+ label. Done.

[cwilso]

Thank you all for attending the meeting last Thursday and a special thank you to Joey for taking meeting notes! Here are the notes from this meeting (the next one is at #11353):

Attendees: Chris Wilson, Joey Arhar, Patrick Meenan, Olli Pettay, Anne van Kestern, Domenic Denicola
Scribe: Joey

Review past action items
Simon will create a spec PR for Form Submission: Fix the "Double Submit problem" at the spec level.
Carry over (no Simon)
Carryovers from last time
[Domenic/Nick] Carry UserActivation across cross-document View Transitions
Domenic to write up a more detailed proposal and bring it back.
New topics
[Patrick] like to talk about #8143 ​​CORS, CORP, TAO & "public static resource" metadata, specifically the proposal to run an origin trial in Chrome for the compression dictionary use case and the usefulness, if any, for being able to mark same-origin responses as opaque.
Patrick to collect more data, generally supportive. To bring back later.
[Simon] Audit and fix innerHTML scripting disabled parsing behavior for template #10879
Push to EU meeting
[Anne/Domenic] constraint validation for FACE when validation anchor is null #10155
carryover
Action Items
[Domenic/Nick] Carry UserActivation across cross-document View Transitions
Domenic to write up a more detailed proposal and bring it back. (things to consider: should we just start with sticky? what happens to iframes / do we carry over nested state too, what happens with traverse bfcache vs. traverse fresh vs. push/replace).
Minutes

carry useractivation across cross document view transitions
domenic: the trend is lets stop building spas and start building mpas. user activation is not preserved with doing mpa navigation, which is a blocker for using mpas. i thought this was frustrating, and i dont have a great solution. its a little scary to port user activation over indefinitely. theres also sticky activation, do we port that across the whole origin? wanted to get peoples thoughts that people agree this is a frustrating capability gap.
olli: we were going through this earlier at mozilla. why does this have anything to do with view transitions? what if the page isn’t using view transitions? the same capability should be there.
domenic: yeah this has nothing to do with view transitions. thats frustrating that they put that in the title. they didnt mention it anywhere else
anne: maybe thats how they noticed it? they were trying to migrate using view transitions, but this is now blocking us?
domenic: yes
chris: we can edit the title
anne: i was just trying to offer an explanation
domenic: simon makes a point, this should not be tied to cross document view transitions. nobody has come up with a no we shouldnt do this
anne: some of these values have timeouts? so maybe you could carry it over and maybe you have it and maybe you dont. for the ones that dont have a timeout, it seems more reasonable to keep them, but for the ones that have a timeout maybe it makes sense to reset them?
olli: yeah i think that should consume the transient one always. you might just inherit a sticky activation.
domenic: i guess the issue is - starting with sticky might be a good starting point. transient being consumed by activation doesn’t quite make sense. you wouldnt consume the user activation by intercepting a click and updating some html.
anne: there can already be raciness if youre waiting for network
domenic: we should consider allowing transient
anne: copying state across documents feels extremely sketch. whenever we copy state across - im thinking about policy with initial about:blank and its horrible. it is somewhat constrained i guess. is it also like would we only do it for top level?
domenic: thats a good question. the user activation stuff propagates up and down the tree, and theres an interop bug here where chrome put the behavior they want in the spec and still hasnt updated.
anne: yeah i think we ran into that at one point
olli: user activation has various bugs. webkit probably follows the spec, but the spec gives you too many transient activations, it has something like mouseup and pointerup so you get twice. firefox and chrome dont do that. you may consume two when you should only be able to do one.
anne: that sounds like a test case to me. even with top level youre going to deal with nested
domenic: with mpa youre not going to deal with subframes. ill try to write something up and see what happens naturally, and then we can critique a proposal.
olli: what about bfcache? do we inherit i there?
domenic: there was an issue, we added wpts but i dont remember what the conclusion was. can we just start with sticky? what about top level vs iframes, and what happens with history navigation? lets make sure we have proposals for all these
anne: sounds good. i dont think we will regret this, but we will have to test it carefully.
domenic: thank you all
cors, corp, tao:
patrick: this came up recently again for dictionary compression. it would be useful if there was a way for servers to respond in a way so that no cors requests could be marked as readable. mostly for public resources that dont change, regardless of credentials, like facebook js or google analytics, without sites having to put crossorigin on their embeds. where it matters for dictionary compression, we can only apply dictionary compression for ?? because you can side channel attack to get it otherwise. you cant dictionary request any no cors responses at all if theyre cross origin. the other use case is for resource timing, which is currently gated based on cors readability as wel. it migrated to that off of timing allow origin. the thinking is for a new header explicitly not try and do anything magic based on existing headers which says this is a publicly readable resource. combine it with combine access control wildcard to make it readable. i dont have a usecase for it, but i dont know if it would be useful for a server to respond to make responses opaque even same origin, so to go the other way and lock down a response. theres concerns about exposing third party information without coordination from the embedding site, but if the thing that is trying to read the information is a script it could always just insert a cross origin fetch directly. assuming the server isnt footgunning and always sends this is a public resource and access control wildcard, it could choose to allow cross origin credentialed or uncredentialed to have the private information anyway. it kind of feels like its a backdoor around cors and i dont know that theres always a reason to client side opt in to cors mode and there was a reason that servers were never allowed to specify themselves
anne: that is one thing we have to do digging on. i also dont remember and i also remember suggesting for images to be able to declare this so they could be used from canvas without having to change the html markup
domenic: cors processing does affect the request. headers get stripped, request blocked, etc
anne: for the request is the origin header whether thats included
domenic: theres a list of no cors safelisted
anne: if you do a fetch. but the list for no cors is even smaller
domenic: if you do a fetch call, the headers you set change based on cors or no cors. link limits too
anne: that in theory shouldnt affect the readability of the response.
patrick: if no cors has looser requirements on fetch currently, could you use it to smuggle cross origin requests with ehaders assuming the server was cooperating and responding ?? is readable
domenic: i suspect the edge case would be the server assumes, so lets say you have a resource you want to be public. youre going to get one set of headers if the request has cors, or if no cors. that might be bad i guess. in both cases you can expose the response because the server says its ok. you might get different headers, is that bad? no its not bad, but maybe thats the thing to be cautious of.
anne: i remember discussing with ian hickson about this. i think i just went with it at the time. i would like do some archeology. i think he realy appreciated the transactional nature, you opt in and get something or dont get something. with this model, you will get something regardless, it becomes a tristate. you get something or you dont get something or you get something and you cna read it. maybe he made it seem to be more than it was at the time. we should go back
patrick: i can ping him. one think i need to think through more is for tainting and redirects. i assume for the final resource, the actual readability might be fine, but the headers leaking redirect information might not be fine. that space might need to be thought through
anne: we dont want to expose all the headers, we were worried about servers having debug headers and we dont want to expose those to script. theres some sort of cors headers about that as well. i dont remember. theres also the other thing you brought up around with resource timing we expose content type and now we expose content encoding. we were careful about how we expose it because we dont want to leak it to third party scripts. you have a website that embeds resources, and we dont want a bunch of images - we dont wnat third party scripts to take all the stuff those images hand out on the side
patrick: if the server always serves the same response nomatter how its requested, the script could just get the same data anyway right?
anne: yes but then they would have to spend resources, it becomes a more active attack. i think for some people on my team that does change it. that is also a thing i would have to double check on.
domenic: one point separate from this is that the proposal has a none version which makes the response opaque. that seems like needless complexity to me
patrick: i dont want to add complexity with no use case. if we add a new header and someone had a reason to make same origin requests opaque, this would be a time to speak up and includeit
domenic: i agree, i just hope nobody has that use case
patrick: if you want same origin responses that youre sending that has information from the script like keys that you woudlnt want to be readable for xss
anne: i dont want to dissuade anyone from putting forward use cases, but we decided that anything that does new requests will have to do cors
patrick: but even if you make a cors request, the server could make an opaque response
anne: thats in direct conflict with our cors decision. either you get failure, or a response you can read. youre introducing a third state, its a response that you cant read. then we have to decide for each endpoint what to do. lets not do that
patrick: i will follow up and poke around and see if we can get more history on it.
domenic: sounds generally supportive. we need to try and figure out if there are any bad consequences. artur and co back with my proposal of reusing access control allow origin were concerned with credentials changing over time
patrick: my hope and proposal was that if we make it anew header and dont do anything implicit, that we dont care about credentials. we dont need to worry about cookies or credentials. it can be an explicit opt in even if its a credentialed request
anne: have you filed a webkit standards position?
patrick: no
anne: youre doing network performance things? have you ever looked into using tls to opt out of all cors preflights for a given origin?
patrick: yes, no
anne: that is an idea i had at one point, i think it still has merit
patrick: these days we could do something with h2 and quick framing, without using tls specifically
anne: yeah thats also a thing we could do. theres some concern that its handled by a different team. if for a whole domain you can say this domain is going to be cors aware, so you could just flip and not handle all the preflights all the time. maybe something to think about
innerhtml scripting disabled
anne: lets push that to the european meeting
olli: it would be good to have henri
anne: and simon
constraint validation for FACE
anne: domenic just left