Open karlt opened 3 years ago
See also https://github.com/whatwg/html/issues/5129.
cc @mustaqahmed @domenic
@annevk thanks, but did you mean to link to this one as well? https://github.com/whatwg/html/issues/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?
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.
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?
"Transient activation" isn't tracked through postMessage()
at the moment. There's a proposal in https://github.com/whatwg/html/issues/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
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.
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.
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 (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.
@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...
- 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.
Sorry I pasted a wrong link there! The fixed link is here (also fixed above).
@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.
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.
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?