WHATWG on 2025-06-11

07:16	<gogo>	Hello. I want to document the latest version of the w3c parser for finding client side vulnerabilities. I started with a DOM XSS using the RFC of the parser with element.innerHTML = "XSS";. My goal is to have the syntax possible for each XSS possible. I started with: https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model according to the schema, the loop starts at the HTML tree builder at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/parser/HTMLTreeBuilder.cpp#L816 and then I am wondering if according to the code at https://github.com/WebKit/WebKit/blob/2246a2aa28d527e129ebec66183569db035fdc8a/Source/WebCore/dom/Element.cpp#L4347 , the policy of innerHTML could deny to execute a script even if not sanitized. I need to find the parser location to see the grammar syntax for potential XSS as mentrionned there: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . Is Elements::replaceChildrenWithMarkup the parser please? Could I ask again for the setinnerhtml parser please?
07:17	<gogo>	Could I ask again for the setinnerhtml parser please? I need the policy parser
13:42	<annevk>	If anyone wanted to review https://github.com/whatwg/html/pull/10548 before it lands, now would be a very good time.
13:59	<jmdyck>	gogo: Re "the setinnerhtml parser": You linked to https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . So 2 lines down from that is "Element's innerHTML setter steps" (which refer to "the fragment parsing algorithm steps", which refer to "the HTML fragment parsing algorithm", etc). Does that answer your question? If not, could you be more specific?
14:00	<annevk>	Luca Casonato: https://github.com/whatwg/webidl/pull/1489
14:10	<gogo>	yes. I showed you a link of my previous work. In 1000 pages, I showed you the link I finally found. I need: to know if the policy parser could ignore not sanitized scripts if responsible, I need the policy parser
14:51	<annevk>	Luke Warlow keithamus smaug: based on the discussion we had last week, are https://github.com/whatwg/html/pull/11255 and https://github.com/whatwg/html/pull/11345 still accurate or will they need changes? Per my recollection I think they match what we wanted in the end. Which was not composed, retargeted, and no further changes to event dispatch for referencetarget. (Olli was not in the room, but I'd like to make sure he agrees so maybe Keith can chat with Olli or some such.)
14:52	<Luke Warlow>	Luke Warlow keithamus smaug: based on the discussion we had last week, are https://github.com/whatwg/html/pull/11255 and https://github.com/whatwg/html/pull/11345 still accurate or will they need changes? Per my recollection I think they match what we wanted in the end. Which was not composed, retargeted, and no further changes to event dispatch for referencetarget. (Olli was not in the room, but I'd like to make sure he agrees so maybe Keith can chat with Olli or some such.) I think that's correct those two things should be enough.
14:53	<gogo>	I need to understand why are not executed the <script> tag after innerHTML while not sanitized and while <img onerror="alert(1)">*
15:04	<akaster>	These properties' setters perform no sanitization to remove potentially-dangerous elements and attributes like script or event handler content attributes. setting an element's innerHTML to untrusted input is a horrible idea in any case. it's almost guaranteed to lead to the problems like the ones outlined in your lab. There are better ways to dynamically add elements to the page than blindly treating a string from the network as html markup.
15:06	<gogo>	Yes. I agree with it. What is the other way to secure with no sanitization please?
15:08	<akaster>	for that simple example of a search form? you could do something trivial like `document.createTextNode` and then `appendChild` that to the responsible div. or call the textContent setter on something. But in general usage questions like this are out of scope for this forum
15:15	<smaug>	Not sure why source needs to retarget if the event isn't composed
15:15	<smaug>	Feels useless
15:20	<annevk>	smaug: the rationale is that people might accidentally expose their shadow tree if they fire a synthetic event as composed. (Though this really argues for generically retargeting event fields that hold nodes.)
15:22	<smaug>	I'd expect similar behavior to events which have .relatedTarget
15:24	<smaug>	(though, 'command' really should be composed always, somehow, or perhaps composed with some opt-in mechanism. Otherwise it becomes too useless.)
15:26	<smaug>	One shouldn't need to manually dispatch composed 'command' events, after capturing the trusted, non-composed 'command'.
15:29	<Luke Warlow>	During our discussion we couldn't really think of an example where using the composed command event really made sense. Because you can't operate on the real event target anyway
15:30	<smaug>	It is an API. You get command event with command "play" on widget which incorporates video element
15:30	<Luke Warlow>	In the toggle event case it would also be problematic because you can't actually disambiguate what fired the toggle event
15:30	<smaug>	and you can call preventDefault
15:30	<smaug>	stuff like that
15:30	<annevk>	I don't actually know what happens for a synthetic event with a class that has relatedTarget. Would be good to test.
15:31	<smaug>	(command event isn't integrated with video or such yet, sure)
15:31	<Luke Warlow>	and you can call preventDefault But is it really the job of the consumer to do that? Surely that's an implementation detail?
15:32	<smaug>	It would be part of the API
15:32	<Luke Warlow>	I fire a play command at "<magical-element>" if that element wants to let me prevent that behaviour they should fire their own event?
15:32	<smaug>	API contract that one can get notified when something happens and possibly cancel it
15:32	<Luke Warlow>	Whether it uses video under the hood or not isn't really relevant right?
15:32	<smaug>	Why would one need to first capture the event internally and then dispatch another event
15:33	<smaug>	feels useless
15:33	<Luke Warlow>	Because shadow roots are deliberately quite encapsulated
15:33	<smaug>	the API contract could be that `<magical-video>` exposes commands 'play', 'pause', 'stop'
15:34	<Luke Warlow>	Yeah and in doing that it would listen to command events on itself? Why does it need to be composed?
15:34	<smaug>	Right now in many cases one can call preventDefault() on down/up/click
15:34	<smaug>	composed makes it useful to the outside world
15:35	<smaug>	I might need to be opt-in somehow
15:36	<Luke Warlow>	I guess my question is why is command special? Do we instead need a way for a shadow root to "forward events" which automatically refires them essentially making them composed?
15:38	<smaug>	command might not need to be special. But in order to have somewhat useful command (so that it could replace some click usage), it probably needs to propagate outside shadow dom
15:38	<Luke Warlow>	I'm confused on why command keeps being equated to click?
15:38	<Luke Warlow>	Command fires on the other end
15:39	<smaug>	on the other end?
15:39	<Luke Warlow>	Well command fires on the video not on the button.
15:39	<smaug>	for now
15:39	<smaug>	command should fire on video when you click on video
15:40	<Luke Warlow>	...that's not what command buttons are though.
15:40	<smaug>	the whole "limit to button" should be just a temporary thing 🙂
15:40	<Luke Warlow>	Firing a command event instead of click in all scenarios doesn't make sense to me
15:44	<Luke Warlow>	Given it is only on buttons right now, is there a scenario where having it composed is good in practice and not in a hypothetical? I'm happy to be persuaded either way but Jake's made a fairly compelling case that it's not actually desirable to be composed. And when thinking through the source retargeting possibilities none of us could come up with a compelling case even for that.
15:46	<smaug>	if we keep it very simple and bound to buttons only, then sure, non-composed could work
15:47	<smaug>	But that is not what I had in mind when this was discussed in Sevilla
15:51	<gogo>	ok no problem. Do you know a more specific forum please?
15:58	<Luke Warlow>	Well if we need to add something novel in future we can still add that, but I'm just trying not to block shipping the current stuff on a potential future thing. If there's a counter use case to Jake's then we can discuss it though.
16:01	<smaug>	we need to always think about future when designing APIs. This is the web, we can't easily remove badly designed APIs 😉
16:03	<Luke Warlow>	For sure, and I think what you're describing suggests a new forward event mechanism because this isn't the only event that probably warrants optional forwarding. Though doing that in JS doesn't feel like a major blocker
16:08	<TabAtkins>	Sure, but part of "stop self-inflicting problems" was asking for some working mode changes from WHATWG (RDs, at least), and some legal wording on their part presumably. I was just checking if there were more details I wasn't aware of.
16:37	<smaug>	Luke Warlow: I think we could add opt-in filtering later. (but I don't still understand the retargeting patch. Added a comment there)
16:45	<annevk>	TabAtkins: RDs came before the W3C MoU and I don't think were motivated by the MoU. They were motivated by not having a compelling enough IPR story.
16:46	<cwilso>	RDs weren't motivated by the MoU, they were motivated by IPR commitments (and horizontal review at W3C), but that was the point of the MoU...
16:46	<annevk>	The main thing W3C asked for the MoU was the right to jointly publish some RDs of specific Workstreams, which we granted. Though then subsequently they stopped investing effort into that.
16:48	<cwilso>	I think at this point, we need to figure out what to re-work. The biggest problems, to me, are 1) the IPR path from incubation to standard should be unbroken; the current path of incubation in CGs relies on the work "migrating to a W3C WG", which it "kinda" does via HTML WG when feature goes to HTML spec, IFF those RDs are published.
16:48	<cwilso>	horizontal review of HTML and DOM, which I still think is a value W3C could add if they got their act together.
17:54	<gogo>	can I ask to RD and where?
18:55	<jmdyck>	I think "RD" stands for "Review Draft", which is briefly described here: https://whatwg.org/faq#patent-policy
18:55	<Severin Severin>	I'm so sorry if I'm in the wrong place. I just have a random question about a decision made for the HTML spec. Specifically concerning the CanvasImageSource.
18:58	<gogo>	Hello. Let me clarify previous question. where is the javascript EBNF javascript formal grammar please? I am looking for the doc for element.innerHTML and document.write please.
18:58	<jmdyck>	Severin Severin: I'm guessing you're in the right place. (or a right place, at least).
19:02	<Severin Severin>	jmdyck: Thanks. Do we just... shout it out and hope some other soul in the void can provide an answer?
19:02	<jmdyck>	gogo: The javascript language is defined in the ECMAScript specification, which you can find the current draft here: https://tc39.es/ecma262 It contains a grammar for the language, in BNF plus extensions, though probably not the EBNF you have in mind.
19:02	<jmdyck>	Severin Severin: That seems to be how it works. (Here and chat rooms in general, I think.)
19:04	<Severin Severin>	jmdyck: It's been a while since being in a "chat room" for me. 20 years or so. Thanks for the tips.
19:04	<gogo>	great ! thank you!! I want to write my own formal grammar spec for innerHTML xss injection I am going to read the parser of Element::setInnerHTML(...) in order to tell all the possible syntax for such injection.
19:05	<jmdyck>	Severin Severin: I mean, if you think you've found an error/problem with the spec, you can open an issue in the spec's github repo. But if you just want to ask a question, best to start here, probably.