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 https://github.com/w3c/permissions/issues/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.

[andypaicu]

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.

Very late to reply to this, but just for clarity. This has 2 components, an in-page UI that triggers a permission request, and the actual permission flow (which is outside the scope of the proposal and up to user agents to define). The in-page UI, will be a button that has very restricted CSS styling and other verifications, to try to prevent users from being tricked into clicking it. The browser is ultimately in control of the CSS styling of any element and therefore has the capability to enforce any restrictions it wants.

[chrisadubois]

Just chiming in here to mention our interest, coming from a product from which we need user permissions frequently. There has been a lot of work, and ongoing pressure to improve the permissions controls for users. Ease of use has been a major problem for our customers interacting with the existing permissions APIs for camera and microphones at least. From our perspective on the product we work on, there is 100% a need to produce a standardized UI around permissions when they make simple mistakes with the current mode. Whatever comes out of this, we are likely to use it because the current modes have not been successful despite whatever UX workaround we have come up with. Every website that asks for permissions currently has to educate the user about the browser they are currently using. This is time consuming and prone to mistakes. A consistent UI and a bit of programmatic approach that gives some more control (but not disguise it in anyway) and indicates the current state of permissions and allowing the user to change them easily would definitely be beneficial.

[mehagar]

As a developer of a web app that requires microphone and camera permissions, I am very interested in this API. We frequently get reports of users not able to use their microphone or camera, only to find out that they have somehow disabled the relevant permission accidentally, and can't figure out how to re-enable it.

[egm0121]

From our web-app perspective, being in the voice and video calling space, this proposal does solve a problem where the first-time user or agent might initially not allow for various reasons the required mic+camera access and subsequently have trouble finding a way to grant these permissions, which are vital for our app functionality.

We have been testing with the PEPC trial on Chrome and we have found significant usage of the PEPC button that led more than half of the time to the mic+camera permission being granted and overall has decreased the number of returning users missing required permissions vs the legacy permission flow.

[jan-ivar]

A question about this statement in the explainer.md:

Even with these measures in place, most user interactions on permission prompts are negative. For notifications (the most requested permission type), Google Chrome metrics data shows that the percentage of prompts that are ignored, dismissed or blocked by the user add up to approx 92% on desktop platforms and 85% on mobile devices.

Those numbers sure seem depressing, leaving readers to deduce an 8% and 15% conversion rate respectively.

But does this account for persisted decisions reducing future prompts?

In Chrome, when a user grants or blocks a permission, that decision is persisted by default. This means the user won't be prompted again for that permission on that site unless they manually change their settings. As a result, the data on prompt interactions in Chrome seems like it comes primarily from users who have not yet made a persisted decision or who consistently dismiss the prompt without choosing.

IOW, 8% of prompts ≠ 8% of people, as some people (the undecideds) produce more prompts than others.

Is this accounted for somehow?

If we calculate conversion only from persisted decisions (granted / (granted + blocked)) do we get a different answer?

(I realize I'm deducing methodology from a sentence here, so apologies if I'm off!)

[b1tr0t]

Can you tell me more about what accounting for perma-decisions would demonstrate? I don't think accounting for behavior this way would be possible in aggregate stats. Decisions happen on a per-page basis whereas once a permission is granted/blocked that's at the origin level. We'd end up overcounting pages where the permission is granted but isn't actually requested for users in a permanent accept/blocked state.

Chrome has been split testing one-time permissions for some capability types for a while (https://developer.chrome.com/blog/one-time-permissions). I believe one time permissions are a user benefit, however, they come with a tradeoff in the form of more unwanted prompts. Let's take an example where in session 1 the user is prompted for camera access and says "Allow once", then in Session 2 the user is prompted for camera and Blocks/Dismisses. It's great that the user got the behaviour they wanted in each session (grant the first time, block the second), but wouldn't it be even better if they were never interrupted by the second request?

Users who block or ignore fall into a few buckets: (1) users ignore, dismiss or block prompts reflexively due to spam and one-time permissions further train this behaviour by increasing the number of prompts users encounter (2) users ignore, dismiss or block prompts they don't understand (site gave poor context) (3) users ignore prompts they don't notice, (4) users ignore, dismiss or block prompts when asked for access they don't want to give, or, (5) the user made a mistake and accidentally ignored/blocked due to: misunderstanding, missed click etc.

In all of these cases, it would be better if the user was never prompted as the outcome would be the same: the permission is not granted. PEPC gives developers the power to do this. PEPC's design provides a high confidence that engagement with the capability was both user initiated and intended: ideally, no pro-active prompt is presented to users at all, the prompt is always a response to user interest clicking on the permission element.

[jan-ivar]

Can you tell me more about what accounting for perma-decisions would demonstrate?

It would avoid comparing apples to oranges.

Users who granted or blocked permissions are no longer contributing to prompt interaction data after their decision. Their initial positive or negative interactions are counted only once.

As days progress, the dataset increasingly consists of negative responses because the undecided users are continually prompted. This drives down the conversion rate over time on account of a small population, even if nobody changes their mind, which intuitively seems wrong.

Similarly, Allow Once permissions (once they're common) might sway the numbers in the other direction.

It seems better to have metrics that aren't affected by such changes. E.g. only compare persisted buckets against other persisted buckets, and only compare non-persisted buckets against other non-persisted buckets.

That's why I was interested in what the persistent allow vs block ratio was.

[jan-ivar]

I believe one time permissions are a user benefit, however, they come with a tradeoff in the form of more unwanted prompts. ... wouldn't it be even better if they were never interrupted by the second request?

How are they "unwanted" by the user? If a user has granted a website a one time permission, the website has done something to earn their trust, and is likely well-behaved. Future prompts are therefore wanted by the user who explicitly chose to always be asked.

Let's take an example where in session 1 the user is prompted for camera access and says "Allow once", then in Session 2 the user is prompted for camera and Blocks/Dismisses. It's great that the user got the behaviour they wanted in each session (grant the first time, block the second), but wouldn't it be even better if they were never interrupted by the second request?

Interruption just isn't an issue with well-behaved sites, and PEPC doesn't address poorly behaved ones. So the second prompt would likely be from the user clicking a button, not an interruption.

Here's the user benefit of one time permission to me: I don't have tape over my camera, and apps sometimes have confusing UX. So it gives me comfort and a sense of privacy to know that the camera and microphone cannot go hot until I acknowledge it by clicking a browser button. The prompt serves this function and works as intended.

Metrics that assume prompts are bad therefore aren't measuring my happiness as a user.

It remains unclear to me whether PEPC can help provide this same comfort and sense of privacy in a workflow that isn't adding extra clicks ahead of every meeting.