I appreciate the concern, and there have been several discussions around the topic (though not formally through issues). Of particular note is that much of this proposal isn't doing anything "new" in as much as it is bringing together multiple functions under one umbrella attribute, as I'll try to break down:
- Invoketarget could be considered a superset of `popovertarget`, as it houses the same functionality of that attribute plus more. I think invoketarget should be treated similarly for the same cases (targeting a popover). JavaScript is not needed in these scenarios. My understanding of the discussions around popover is that it did not bring significant new risk to the platform to warrant opt-in flags or to add new security primitives (such as a CSP header) as it stands today. - invoketarget also has the capability to open dialogs. These are effectively the same as popovers in that it will promote an element to the top layer, but dialogs have the addition that they can focus trap. Personally I don't consider the act of focus trapping to add additional risk (a user is always able to escape the focus trap by pressing the escape key or equivalent gesture), so I would bucket this in the same context as popovertarget. - invoketarget has the ability to fullscreen an element. This is perhaps the riskiest area, and allowing unrestricted access to fullscreen elements would definitely be of concern. Care should be taken here to ensure that fullscreening has the same restrictions as `requestFullScreen`; if a `requestFullScreen` call would fail then so should an invoke. - invoketarget also has the ability to control video playback. My understanding is that this is possible using video player controls today, where JavaScript is not needed, and so I don't consider this as an escalation of ability either. - invoketarget can open a <details> element. <summary> elements can also do this today and JavaScript is not needed in these scenarios, so I don't consider this an escalation of ability either. - Aside from these, any other abilities would require scripting, and the relevant CSP headers would suffice. My understanding is that most sanitizers such as DOMPurify and sanitize-html are allow-list by default, and consequently would remove the `invoketarget` attribute from any user generated content. Given the above I believe the risk to be low enough that I don't believe an opt-in to this behaviour is warranted; the operations one can perform without scripting are quite limited and in some cases possible today through other means (popovertarget, <summary>). It may warrant an opt-out via CSP. Perhaps if you would kindly raise an issue on whatwg/html to around this we could discuss it further? On Fri, 3 Nov 2023, at 12:03 PM, Gijs Kruitbosch wrote: > AIUI this effectively allows a website to declaratively do something that > would currently require JavaScript. > > Would these attributes be subject to CSP, sandboxing or specific HTML > sanitizer behaviour at all (and if so, in what way)? Because if not, I > imagine that these would potentially allow escalation of a website security > vulnerability from a markup injection to something approaching XSS - that is, > doing things on the vulnerable website that would require XSS without > implementation of this proposal. Or is that an accepted risk and/or are the > invoke targets/actions sufficiently underpowered that this was not deemed a > concern? > > ~ Gijs > > PS: Apologies if this got brought up in the spec or previous discussion, but > I was unable to find relevant keywords in any of the spec / pull / explainer > links. The explainer does acknowledge that inline JS is frowned upon and > often disabled via CSP, and that this is a more declarative mechanism to do > the same thing, but I couldn't find anything more than that. > > > > > > On 03/11/2023 00:30, Keith Cirkel wrote: >> *Summary*: >> >> Adding invoketarget and invokeaction attributes to <button> and <input >> type="button"> / <input type="reset"> elements would allow authors to assign >> behaviour to buttons in a more accessible and declarative way, while >> reducing bugs and simplifying the amount of JavaScript pages are required to >> ship for interactivity. Buttons with invoketarget will - when clicked, >> touched, or enacted via keypress - dispatch an InvokeEvent on the element >> referenced by invoketarget, with some default behaviours. >> >> *Bug*: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1856430 >> >> *Specification*: >> https://github.com/whatwg/html/pull/9841 >> >> *Standards Body*: >> WHATWG >> >> *Platform coverage*: >> all. >> >> *Preference*: >> dom.element.invokers.enabled >> >> *DevTools bug*: >> n/a. >> >> *Link to standards-positions discussion*: >> https://github.com/mozilla/standards-positions/issues/902 >> >> *Other browsers*: >> Blink: Prototyping >> (https://groups.google.com/a/chromium.org/g/blink-dev/c/tDanwUCp2cg/m/IPc9hvHcFAAJ). >> WebKit: No Signal. >> *web-platform-tests*: >> >> >> https://wpt.fyi/results/html/semantics/invokers?label=experimental&label=master&aligned >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected]" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/3c383a64-c7d8-4ece-86e1-590fda1e27d9%40app.fastmail.com >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/3c383a64-c7d8-4ece-86e1-590fda1e27d9%40app.fastmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/404f03e5-0339-475d-b96a-fc4ba6368690%40app.fastmail.com.
