Should top-level transient activation be sufficient for getDisplayMedia() on cross-origin iframes with allow="display-capture"?

[karlt]

This came up when we added the transient activation requirement to Gecko. The data flow affected was "click handler in main document" -> iframe.contentWindow.postMessage() -> "getDisplayMedia() inside iframe". The gesture in the top-level Document does not affect cross-origin descendant Documents.

I assume the purpose of the transient activation test is to require a user gesture and the precise location of the user gesture is not important?
If so, then checking for transient activation on the top-level Window instead of on the relevant global object is an option to allow this use case.

Would any host Document want to grant a cross-origin iframe "display-capture" permission but restrict its getDisplayMedia() calls to a user gesture specifically on the iframe?

[annevk]

See also whatwg/html#5129.

cc @mustaqahmed @domenic

[jan-ivar]

@annevk thanks, but did you mean to link to this one as well? whatwg/html#4364

Would any host Document want to grant a cross-origin iframe "display-capture" permission but restrict its getDisplayMedia() calls to a user gesture specifically on the iframe?

@karlt I can't think of any case like that.

then checking for transient activation on the top-level Window instead of on the relevant global object is an option to allow this use case.

I think that'd work in our case since getDisplayMedia is the lone feature enabled by "display-capture".

Though now I'm curious, can an iframe doc get transient activation without its top-level doc also getting it?

[karlt]

Though now I'm curious, can an iframe doc get transient activation without its top-level doc also getting it?

No, a user interaction in an iframe causes active Windows of all, even cross-origin, ancestor browsing contexts to have their timestamp updated, so all ancestor Windows (including the top-level) always get transient activation when the iframe gets it.

[youennf]

Would any host Document want to grant a cross-origin iframe "display-capture" permission but restrict its getDisplayMedia() calls to a user gesture specifically on the iframe?

I cannot think of a case like that.
But I can see top level frames not wanting that any random click can be used by third-party iframes, even though they have "display-capture" permission.
My understanding here is that the postMessage from top level frame to third-party iframe is triggering the "transient activation" delegation.
Is that correct?

[annevk]

"Transient activation" isn't tracked through postMessage() at the moment. There's a proposal in whatwg/html#4364 but that went dormant. That also wouldn't solve any existing scenarios as code would have to be updated to make use of it.

cc @dtapuska

[youennf]

For "existing code", quirks can be used as a short term mitigation.
I hope we can come up with some consensus for third-party iframe mitigations.
FWIW, Safari is shipping strict activation rules for getDisplayMedia.

[karlt]

My understanding here is that the postMessage from top level frame to third-party iframe is triggering the "transient activation" delegation.

The proposal here is not to pass the transient activation to a cross-origin frame by postMessage(). i.e. it is not to provide cross-origin transient activation for general usage. I guess you could view the postMessage() as informing the third-party frame that the top-level has transient activation, in much the same way as a user-gesture handler might inform a Promise microtask.

[mustaqahmed]

Let me clarify last few posts here, we are linking two different proposals here:

• @karlt is correct about JS API for querying User Activation which allows a frame to only "see" the user activation state of another frame.

• The issue @annevk linked (User Activation: ability to transfer activation to another frame whatwg/html#4364) was delegating user activation through postMessage() calls. This issue can be considered dead now---TAG expressed valid concerns around abusability. We are exploring an alternate proposal (Capability Delegation) which focuses on API-specific delegation without modifying user activation state in any frame. If media-capture finds this useful, please let us know.

For the media-capture question raised in this issue, I think the answer depends on what allow="display-capture" really means. Does it expect the subframe to rely on its own user activation for a media-capture call or no? An "yes" seems to be the safest answer to me because, for example, I don't ever want a random ad subframe in a site to perform screen-capture without a click in that frame.

Edit: fixed the Capability Delegation design doc link.

[annevk]

@mustaqahmed if you could note that in that issue (including a link to the TAG review) that would be appreciated.

I cannot open the Capability Delegation document. It would be helpful to understand how it differs from the postMessage() approach which also seems to be about delegating the capability...

[youennf]

• We are exploring an alternate proposal (Capability Delegation)

Can you make that document publicly available.

An "yes" seems to be the safest answer to me

That seems like a good default to me in general.

[mustaqahmed]

Sorry I pasted a wrong link there! The fixed link is here (also fixed above).

[mustaqahmed]

@annevk Let's discuss the new proposal through WICG/capability-delegation. I will close the HTML issue and other (quite a few) untied knots around the old proposal soon.

[annevk]

Ah okay, so the problem with delegating user activation is that it's too generic. You want to delegate user activation but scoped to a particular API. I like that.