To expand on my comments around fullscreen with a more concrete example,
the current prototype within Chrome allows for invoking an element into
fullscreen in a sandboxed frame with the `allow=fullscreen` feature policy.
This is not too dissimilar to the existing possibility of using an onclick
handler. Consider the following:
```html
<iframe sandbox="allow-scripts" allow="fullscreen">
<html id="invokee">
<button invoketarget="invokee" invokeaction="toggleFullscreen">Invoke</
button>
<button onclick="invokee.requestFullscreen()">Go fullscreen</button>
</html>
</iframe>
```
In the above example both the `<button onclick>` and `<button
invoketarget>` will fullscreen the iframe. Removing `allow=fullscreen` will
mean this buttons cannot fullscreen the iframe. Changing
`sandbox=allow-scripts` to `sandbox` will disable scripting, and so the
`<button oncllick>` will no longer work, but `<button invoketarget>` will
(provided `allow=fullscreen` is still present). Given these buttons require
user activation (invoke defaults are only triggered from trusted user
activation) I believe the risk is sufficiently low with these safeguards in
place.
For any other questions around security, perhaps we could coalesce the
discussion here: https://github.com/openui/open-ui/issues/904 where the
proposal is incubating to get the right feedback from the proposing team?
On Tuesday, 7 November 2023 at 09:49:48 UTC Keith Cirkel wrote:
> 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/7ceadf17-e86d-4fa0-966e-723aca814e42n%40mozilla.org.
