Dan: What about 300?

Hadley: awaiting external feedback.

DanThis is where Dave said that Web IDL is better than plain English

Alex: [laughting]

David: This is about an API that exposes the activation state.

Kenneth: Are the use-cases clear here

David: There were some use-cases that were a little interesting, but ... like I think that some of it was around iframes that wanted to post message each others, and condition an message from another iframe depending on user activation or not

Alex: Same thing with resizing iframes.

Hadley: I like that use-case

Dan: Should this not be highlighted in the security considerations. Again I think we need a little more infomation here.

Alex: We asked for sample code and didnt' get it - lets follow up with Dave again on that

Dan: What problems are we trying to solve

Alex: We would like to check the states ourselves in a layered approach, which this seems aligned with. Questions is whether this is motivated well, which I think it is

Dan: That is not really reflected in the explainer well. There are too many assumptions, but the point of the explainer is to do the opposite

Dan: Bumped as well. Will he be at TPAC

Alex: I will chec

David: [left recent comment] we can see how they respond to that. one worry is just that - if uses for this are people writing chrome specific stuff about permissions model, not so great. People shouldn't hard code how chrome's permission model into their web site. There is a way to get the permission with one click in chrome and one click in firefox but the reaity is it takes 2 clicks in firefox because of how the site asks for permission. So there will be a browser prompt each time. Chrome has user interaction - so sites have forced interaction even when they don't need it. Real solution should be to have the permission API answer questions about - whether a permission request will be denied.

Travis: right now it's just 3 values, denied,allowed,prompt

David: there's the permissions API spec - a piece that people have agreed on - and work will happen in the new year

Travis: the proof point is - developers working around that lack of state - and providing the state should be something we [web platorm] do.

Dan: Jo from Samsung did a blog post: https://medium.com/samsung-internet-dev/a-crisis-of-permissions-80cf3b2c802e

Dan: still waiting for a workshop report- I will bug Sam from W3C about this.

Dan: David I think the issue you bring up here is important especially considering current events regarding browser engines.

Travis: maybe start a new issue?

[decided just to keep tracking it on issue 300

David: We "discussed" this before Christmas... Probably needs a deep-dive (more than 30 mintues).

dtapuska: (missed start)

...workarounds used today due to lack of this API:

• ?
• audio tag
• clipboard

...in chrome proposed this user inetractibe

...don't want to tie it to permissions

...don't want to expose timestamp of last interaction; security issues

... some of this ties to other TAG requests, e.g., User Activation v2. This API applies to both old model and new model.

dbaron: more OK with this given those uses you presented -- but still worried about people misusing it for browser-specific permissions issues

peter: this would be useful to me for (reasons missed)

tess: Good to get additional context. Was thinking about autoplay case; was just discussing exposing whether autoplay would be allowed. Was worried about same thing as David; reasonably comfortable now.

dka: That other things sounds worrying: "Sorry, this page doesn't work unless you allow autoplay".

tess: High level concern is page assuming particular permission model and using this API to make decisions about what to do -- but that's not what this API is for. Shouldn't be inferring what will happen with permissions based on these 2 bits of information; should just use the permissions API.

dka: Is that flowchart something that could be in the explainer?

dtapuska: I can edit that in if that's your feedback.

dka: We're keen to close the issue. Thanks for listening to our feedback.

hadley: closing seems reasonable; would be nice to check in again further on.

The flow chart: https://dtapuska.github.io/useractivation/example.html

Tess: if the expaliner were updated ... he was able to clarify everythng but i want to see it reflectedin the explainer. will ask for an updated based on the call we had last week.

Peter: sounds good.

Tess: we coudl close and and ask them to re-open.

[agreed to move to jitsi due to some issues with appear.in this week