PEPC discussion thread

[b1tr0t]

Kick off thread for PEPC discussion.

[tomayac]

The current design implies this is a self-closing element. How would this handle the use case where typically several permissions are required for the app to work well, like, for example, in the case of Meet, which requires notifications, camera, and microphone. The current attribute type is singular.

 

 

One solution would be to make this plural, types, or maybe modeled after allow:

<permission allow="notifications camera microphone">
<!-- Alternative -->
<permission types="notifications camera microphone">

Another solution would be to allow <permission> child elements and introduce <permissions>:

<permissions>
  <permission type="notifications">
  <permission type="camera">
  <permission type="microphone">
</permissions>

Yet another solution would be semantic permission bundles, initially proposed in w3c/permissions#191:

<permission type="videoconferencing">

[andypaicu]

The current thinking is to go with the first option and allow multiple permissions in the "type" (or "types") attribute and leave it up to the user agent to decide how to handle it (on the Chrome side the only combination we think needs to be supported it microphone + camera for example).

Generally speaking however I'm not sure that multiple different permissions that support different parts of a site's "experience" should all be grouped in 1 PEPC, and I think the better pattern would be for the site to include 1 separate PEPC for each permission (again with perhaps the exception of camera + microphone which many user agents allow to be grouped). This would allow sites to explain why each permission might be needed and allow users to make individual permission choices (e.g. in the example above allow camera+microphone but not notifications).

[g029x]

This proposal is really interesting.

At some hypothetical point in the future where PEPC is the dominant way that sites ask for permission, I could see myself and other users becoming used to trusting the in-page button and not reading the actual prompt as carefully since it should align with what was clicked on.

If the legacy prompt looked at all similar to the PEPC prompt, I could potentially see myself getting tricked by a regular button that mimics the familiar style of a PEPC for a permission I'm okay granting but that actually triggers a legacy prompt for a permission I don't want to grant. I can't imagine why the prompts would ever look similar though.

Also, this is probably a dumb question, but how would changes to the PEPC type attribute work? Would it be disallowed entirely or perhaps just be treated as part of the 500ms visibility requirement?

Apologies if this is just noise for you all. It's just a really interesting proposal that got me thinking! Best of luck with the prototype!

[andypaicu]

Thank you for your interest!

Good point for user agents to be mindful of in the future. User habituation can become a real issue if the legacy permission prompt is sufficiently similar to the PEPC-triggered prompt.

For the type attribute, my current thinking now is that it should not be changeable, mostly since I don't think changing the type should be an encouraged pattern. Obviously, sites can easily get the same effect if they create a new PEPC with the new type and replace the existing one so the distinction is probably mostly philosophical.

[simon-friedberger]

As mentioned it is necessary to make it clear that this is browser UI not page UI:

At its simplest, the element takes the shape of a button whose appearance and behavior are materially controlled by the user agent, to the extent that is necessary to ensure interaction with this element is a strong indication of user intent to use a certain capability.

Afaik the only way to do this is to display the element at least partially outside the website viewport, in other words on top of browser chrome, which is what the current permission dialogs are doing. Does that seem accurate? It seems to make challenge (2.) somewhat unfixable.