User Activation API

[dtapuska]

Bonjour TAG,

I'm requesting a TAG review of:

• Name: User Activation Query API
• Specification URL: No pull requests yet
• Explainer, Requirements Doc, or Example code: https://github.com/dtapuska/useractivation (Explainer)
• Tests: WPT Tentative Tests
• Primary contacts: @dtapuska

Further details (optional):

• Relevant time constraints or deadlines: Seeking shipping in Chrome 70 or 71. Chrome code is ready.
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

The PostMessageOptions have been factored as a pull request.

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]

[hadleybeeman]

Hi! Thanks for this. It would help us a lot if you could explain what problem you want to solve and what the use cases are? You've clearly put thought into the detail, but it's hard for us to work with that when we're not sure where on the big picture you're focusing.

Our explainer explainer might help with this.

[dtapuska]

@hadleybeeman Did you read my explainer

The motivation is primarily this use case: "For example if an iframe asks a parent window to resize itself, the parent way wish to check that a current user activation is active"

Perhaps if you don't understand that example I can add some more detailed information. But the iframe is generally an ad and it wants to do some type of growth beyond its bounds. And we only want that to occur if the user is interacting with that specific iframe.

[slightlyoff]

Hey @dtapuska,

We did read your explainer; the feature detection snippet is great. I think there are a few open questions:

• The motivation doesn't identify why it's good or necessary to add this API. The iframe activation case is interesting, but there's no example code showing how this will make a difficult or error-prone solution today more usable or less error-prone in the future.
• In general, IDL is for specs, example code is for humans (and Explainers).
• It isn't clear who sets includeUserActivation and how/when. As there isn't any example code, it's hard to suss out what's intended.

Thanks for following up on this.

[dtapuska]

@slightlyoff IDL is often more descriptive and correct than english 😃

I've adjusted the motivation section to call out the performance, security and user destructive behaviors. And added an Example section that I hope clearly shows how you can do this current behavior and how the API is good for resolving this.

[dbaron]

The proposal seems pretty reasonable to me at first glance. Some things I think are worth looking into:

• I wonder whether everything in the pile of postMessage overloads is safe. Is it clear that WebIDL handles them all well, e.g., in terms of converting types that people might be using today to the right thing, and on future possible conversions?
• I think it's worth being clear about the liveness of the UserActivation objects. I'm assuming the intent is for navigator.userActivation to be a single live object that will change after it's been accessed. But I think it looks like the userActivation on MessageEvent would be a static object that represents the activation state at the time the message was sent, and doesn't update later if activation occurs. (There's a mention of cloning.) Is that correct?
• will making PostMessageOptions's targetOrigin default to / be surprising to developers? My inclination is that it seems like a reasonable default, but I think it's worth asking.
• I wonder about the singular name transfer for a sequence (compared to, say, transfers or transferList)

[dtapuska]

Re: postMessage overrides, WebIDL handles them quite well and it is quite simple to feature detect. Chrome has proceeded already in enabling this in Chrome 70.

liveness of UserActivation your interpretation is correct. (live on navigator, static on MessageEvent) We talked about the attribute name on MessageEvent indicating snapshot or something like that but people didn't prefer the extra verboseness.

PostMessageOptions targetOrigin it shouldn't be a surprise it is the most restrictive so it is a good ergonomic change for the web. ie. you need explicitly change to a less restrictive option which then can leak data cross origins.

transfer We can certainly debate this point but we've merged this change already into the HTML spec and Chrome has this for Chrome 70.

dbaron thank you for your comments. Do you have any thought as to the implications that exposing UserActivation cross origin has. I believe there are already approaches to get this data in the same origin as per my examples. But the new behaviour is it is exposed to another origin. We restricted this so it was opt in so I think we mitigate any concerns here. But generally one origin shouldn't know that the user is interacting with another origin.

[dbaron]

At first glance, the cross-origin thing doesn't appear any different an origin's existing ability to postMessage to another origin, but with the addition of the ability to have a piece of that message vouched for by the browser. That doesn't seem scary to me. Or is there a different way I should be looking at it?

[dtapuska]

That is correct. There isn't a different way to look at it.

[dbaron]

So one other comment from TAG discussion right now: a bunch of folks didn't understand what the explainer was saying because the explainer's description of the use cases sort of depends on already understanding some of the concepts involved.

I think a clearer way to describe the example user need would be something like the following:

Suppose a page that contains a cross-origin iframe wants to allow that iframe to request (say, via a postMessage contract) becoming larger, because it's appropriate for that iframe to become larger when the user interacts with it. However, it doesn't entirely trust that iframe from trying to grab extra attention, so it wants to do the same check that the browser does as part of its popup blocking code, which is a test for user activation. So this API allows the containing page to validate the postMessage from its iframe by only honoring the request to become larger if there is currently a user activation, that is, if the message appears to have been the result of a real user interaction with that iframe.

[kenchris]

UserActivation object and the includeUserActivation option confused me a lot at first. It sounds like you are including an action, but what you do it request to add a state object.

Maybe rename the object, UserActivationState and similarly the option?

[torgo]

Under what circumstances is a tab or other types of user interaction also a user activation? Where is this defined?

[torgo]

@dtapuska do you have any into to provide regarding @dbaron's question above?

[torgo]

We are coming back to this open issue in our f2f meeting. I'd like to understand if there is anything we can do further here to help or if the TAG should close this issue?

[dbaron]

To make that question a little more concrete: it feels like a bunch of the use cases for this might be better addressed by enhancements to the permission API to more clearly explain the permission state, e.g., building an API that's expressive enough to say "right now the permission is denied, but following user interaction your page would be able to prompt to ask for this permission"... and then probably also notify the page when that changes. It seems like that sort of thing is an improvement in that it would mean less baking of knowledge of what browsers do (which may differ between browsers and may change over time) into the JS within applications.

[torgo]

After discussing with @dbaron and @hober the consensus is not to close the issue at this point. There is a concern among some tag members that this may not be the right approach. Maybe it would be a good idea to have a focused discussion on this topic with @dtapuska on a future call...? Our next cal is on the 26th at 21:00 GMT / UK time (16:00 Eastern Time) - are you able to join us? If so, please contact @alice for the call details.

[hober]

Out of curiosity, and because I couldn't figure it out myself by following links: what is the working group (or community group, etc.) that is working on this?

[dtapuska]

It is part of the whatwg (not W3C). See whatwg/html#4009

@dbaron What about generic things that want to know the state about something? This isn't whether the permission is allowed in the embeder's frame but whether it was allowed in the embedded frame.

I am able to make a call at 16:00 Eastern Time that day (only for about an hour though).

[dbaron]

@dtapuska could you give an example use case for one of those "generic things"? I don't think I follow what you're asking about.

[dtapuska]

@dbaron the main example of resizing an iframe is an example. For example if I wanted to implement the policy of "if the user has every touched the frame allow the iframe resize" how would you do that?

[dbaron]

I'm not sure -- though I'm also not convinced of the importance of that use case. Do you have examples of sites that do this sort of thing today?

[plinss]

@dtapuska we currently have you on the schedule to join a TAG call on 2/26, but unfortunately all three of the TAG members working on this issue have sent regrets, can we reschedule for next week?

[dtapuska]

@plinss Yes same time the following week is fine.

[plinss]

Great, thanks!

[dbaron]

We discussed this in our teleconference today.

[hober]

Thank you so much for joining our call last week. The discussion we had really clarified things for us. We'd love it if you would revise your explainer in light of that conversation. The TAG is only one of the many audiences explainer documents are intended for, and your other readers would benefit from the clarification you were able to provide to us on the call.

We're going to close this for now; once your explainer is ready for another look, please either

• open another issue, linking back to this one; or
• comment on this one and ping @plinss directly to get it re-opened.