Jeffrey: Serena might be able to help here, but she is in NY, which makes timing hard. We should go through and work out where the problems are.

Martin: My understanding of the problems is that sites might use this to trick people into giving permission. Wasn't part of the intent. The way we do File Pickers, that's a page-embedded permission control, since it's a button embedded, which opens a picker, and you pick a file. If you don't give the site control over the picker, and it's just a placement of the picker that changes. I'm ok with that. Site gives up some content area to the browser, and you get to ask questions there. Most of these things, as long as you're confident that the browser's pixels are correct, for whatever definition, then there's no opportunity to dupe people. A lot of the concern is misplaced. Don't think anyone's had that conversation.

Jeffrey: Who are those people? Can we just facilitate a conversation?

Martin: Jan-Ivar, and maybe some others.

Jeffrey: My analysis matches yours.

Martin: Some question of whether the page needs to give up some content area. Don't think there's a firm requirement, by analogy with the file picker, which can be triggered from an invisible control.

*** Jeffrey will try to setup a call.

Xiaocheng: If we allow it to pop up at any position, do we want the site to style it?

Martin: No, since the question is browser-chrome. You can style the thing that triggers it. Don't want styling to be used to mislead. Styling could change the fonts to rewrite the question.

(Martin) Waiting on a meeting between various stakeholders.

Martin: Jeffrey is brokering a meeting with the actors here.. that's what's next here. The fact that the TAG is doing mediation here... is a failure of process... There's no working group for this group, and... so it's ended up in WICG, which doesn't have a mechanism for resolving conflicts.. In that situation it falls on the TAG to mediate a conflict when a conflict happens. That's not great.

Dan: reprises discussion in Breakout B

Marcos: need to catch up on this... given consistent feedback that ... you need an equiv JS api so... this has very little value. That's Webkit's current position...

... this is a signifigant shift in the architecture of permissioning. It means there shall not be an API ... all new APIs switch to this model, or we keep having an API... It's signifigant to the permissions architecture.

Dan: Sounds like Marcos and Jeffrey need to chat about this - suggest teeing it up for breakout A next week.

Martin: I looked at this from a Mozilla perspective... we thought the single purpose try-to-solve-everything-with-one-element is not going to work. The variety of use cases was diverse enough that we'd like to see permission-specific elements for each thing. A camera element, a microphone element, etc, but not repeat the mistake we made with ???.

Very enthusiastic about the idea, but it's a big project. Happy with what the google team have done around clickjacking etc, but overall this is a good project. Been running for a while now, I first saw this at TPAC in Seville.

Marcos: Similar to Mozilla on the WebKit side. We've looked at this long and hard ... because the motivation was following what Apple did with the geolocation button in some platform version [?]. With that design, the constraints are so limiting that it kinda becomes useless, which is what we concluded. The mitigations were good, but it was very complicated and kludgy that it added a lot of complexity. The thing that really took this down was that we have N number of APIs that need permission, we would need to move things. Either all new APIs use this model, but we can never get rid of existing APIs. You always need the original API. If you have the API, the developers will use the API anyway. So you are still back. If it is annoying to include this in the page, without being able to style it, you will use the API. Maybe this works for new APIs, or we move all APIs to use this, which could be a thing. Finally, this seemed to be a rehash of what we had with navigator.permissions; we got rid of that because it didn't align with the way the APIs are used. This could be another means of asking for permission, which we didn't feel was a great thing.

Martin: Yeah, we talked through a bunch of this with the team at google, and we agreed with your point Marcos with permission.request. We don't want to build an API with the grant-permissions disconnected from the use. We're enthusiastic about this API because we can closely connect it to the use in a number of cases. There is no time of grant or time of use grant for notifications because you always have to ask ahead of time. But for cameras and microphones, you could imagine an in-page element that you click on, which activates the permission request. We can let the website authors style that however they choose: icon, text, colors, etc. The only thing that matters is the thing that pops up to ask permission. Giving site authors control of the placement of that, without all the controls, seems good to us at Mozilla. If you click the button again, it face mutes. You can turn it on and off in a way the browser understands and is in control of. Don't need JS, the default browser behaviour will just work. We thought through the concerns you had, and thought if we do this well, there is enough upside to this. But it has to be done well.

Otherwise, we share your concerns. The line of death... that's a red herring.

Marcos: the other thing that we concluded was that this was a self-created problem that chrome created for themselves, because Safari... Chrome are doing the door hanger. If you are doing a model request, then people wouldn't miss the permission... The incentives were "people were not understanding that the door hanger up here relates to the button down here", but when you do it in safari, it does it in the middle of the window

Martin: we disagree for good reasons. I think the UX philosophy that we're using is not to allow sites to force people to decide. We decided that in 2008 (before my time).

Marcos: right, and that is following Apple platform conventions. On macOS and ios, that is consistent on the webkit side. Firefox made a different decision,

That's not to say that we don't have to do the same affordances... but there is no way like in firefox where you can dismiss it without having made an explicit choice.

Martin: I do think that problem of people noticing the permissions is solved neatly by this one. But that doesn't foreclose on the choice of a modal prompt. Or maybe, the site would be happy with the chosen placement. That's up to you to work out. There are a lot of competing concerns here.

Marcos: there is some overlap in agreement, but there are difficult problems to overcome here. If we all had concensus that this is the way to go for new APIs, that would give us a path forward. I'm still not convinced that this is the right solution.

Martin: from our [Mozilla's] perspective, we are going to invest time into working out the camera and microphone pieces more fully. I wouldn't expect you to do more... It will be a ways off before we conclude what we think is the right design for just those two pieces.

Marcos: and there is accompanying APIs for those.

Martin: and we can't take them away.

Marcos: even if chrome and gecko end up supporting the pepC thing, you still ...

Hadley: is it too early for the TAG to review? Do we have consensus on anything to say?

Martin: we can comment on the idea that you can do a single element to cover everything. We have established design principles here.

The other thing: we can point out Marcos's point of the relative value of adding yet another way to do something on the platform.

Hadley: the second one weighs in to developer complexity

Martin: yes, but then you don't need to build the UX, you just put the element on the page. Could be less complexity, in the end.

Problems that need to be solved... if you have a camera button and a microphone button, and I unmute one, does it make sense to ask about the other?