#347: User Activation Delegation through postMessages

Visit on Github.

Opened Feb 22, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details (optional):

You should also know that... While Chrome needs this API to fix regressions caused by UAv2 (#295), the concept of delegation here is independent of the model in UAv2. The delegation here can be used with any user activation model, including Chrome's old model (user gesture tokens).

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

2019-03-19

Minutes

alice: This came in 25 days ago, not quite my area but seem reasonable. Useful when you want to know if the user has interacted, let's you transfer to the frame.

tess: Worried about the browser limiting some activity in iframes/subframes to a user gesture and this is a way for the main frame to hand off that user gesture. This makes sense going upward, but not downward. Media policies are different in different browsers; would this allow arbitrary hand-off of user gesture state? You have an iframe that has a video in it, user taps to make a comment and that causes the iframe to start playing a video.

alice: Wouldn't the video stop when the user interacted with the top frame again?

hober: I think that would depend on the browser's policy.

torgo: There are some security considerations in the design doc; not very privacy focused. Does seem that there's a missing privacy consideration... any time you're dealing with activation you're dealing with something that is personal to the user. That feels dangerous when it comes to privacy... doesn't seem that there's enough in this doc that deals with this issue. This is a little vague..

dbaron: I'm concerned that there are things that set the user activation state; often you'll get more than one of those in rapid succession. If you have the ability to transfer that to another frame, you can take what's conceptually one user action and "spread" it around, e.g. mousedown transfers state and then mouseup keeps the state locally.

hober: or you run into an issue where the transfer recipient loses user activation.

torgo: Let's try and solidify our feedback and come back to this next week.

2019-03-26

Minutes

David: he responded to the substantive questions

Peter: he checked "issues in their repo" for feedback.

Tess: mark as urgent? he said we need to do it quickly.

Dan: Feels like he is dismissive of the privacy concerns. Yes, this is info that can be collected via other mechanisms, but does it make it easier to collect and share?

Peter: is this a high level feature that we even want to expose?

Tess: the case of the iframe that wants to tell its parents to resize it but only under user gesture. - a reasonable case for wanting to write web content that restricted itself to a user gesture. Prior to thinking of that use case I thought it could be gated in other ways. the iframe resizing case was a reasonable counter-argument. It's a bigger question than the scope of this design review.

Dan: i think it's reasonable for us to highlight this.

Tess: say you've got 2 fingers on the screen on 2 different elements...

Sangwhan: is the activation state exploitable like how you could use hsts to fingerprint people?

Tess: not obvious off-hand to me if this would make it more possible.

Sangwhan: is there some kind of cache of activation state? Not sure how persistent that is.

Tess: the persistence of that cache is concerning because...

Sangwhan: hsts state can be cached and can be used [for fingerprinting]. Is that in any way possible with this info.

David: if the user activation state is cached it's cached for a few seconds, not permenantly like HSTS.

Dan: ok - other than that I think we are happy - so let's bump it a week just to come back to it and hopefully close it up then.

Alice: if they decided next week to ship [in chromium] would anyone have a strong objection?

Peter: my concerns escalate as I see more and more APIs coming in that have a similar scope and nobody is looking at the big picture. These are all being taken in different directions.

Dan: what can we do about that?

Tess: 2 parts of that - would these things be unified in some way and how, and what is the right approach? also a process question - if we get 5 reviews that are all urgent that all have longer-term implicaitons, how do we give effectivefeedback in the time requested and simultaneously do right by our chartered obligations. if we're always udner pressure to not strongly object because of time-pressure then what is the point of the process?

Dan: +1

Dan: what are the similar things?

Peter: issue 356 - autoplay detection - feels like it should be harmonized with some other APIs.

Tess: there's a

Peter: that was just an example of one more interesting aspect

Sangwhan: RTCquic transport - also an exmaple of different groups going in different directions for one problem set. Spatial navigation and html focus...

Dan: I think it should be explored...

Peter: how?

Dan: meta-issue in design reviews repo?

Peter: i will do that

2019-05-15

Minutes

Alice: The last comment ... looking into use cases. I think this one is pending feedback, or possibly even "ping to reopen". I'll set "pending external feedback" for now, and I'll ping folks internally to encourage them to get us feedback by next week.

Dan: Set milestone to f2f?

Alice: yes