Page Embedded Permission Control

[b1tr0t]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Page Embedded Permission Control
• Specification or proposal URL (if available): (in progress)
• Explainer URL (if available): https://github.com/WICG/PEPC
• Proposal author(s) (@-mention GitHub accounts): @andypaicu @tomayac @b1tr0t
• Caniuse.com URL (optional): tbd
• Bugzilla URL (optional): tbd
• Mozillians who can provide input (optional):

Other information

Discussion at TPAC Breakout: w3c/tpac2023-breakouts#35
Discussion at TPAC Web App Sec WG: https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-09-15-TPAC-minutes.md
Discussion at w3c Permissions Workshop: https://www.w3.org/Privacy/permissions-ws-2022/report#novel-building-blocks-for-capability-control

[b1tr0t]

Gentle nudge on this, we'd love feedback.

cc/ @bvandersloot-mozilla from the TPAC discussion.

Thanks all!

[simon-friedberger]

The UX problems with permission prompts are understandable but we should not further confuse users by mixing controls of browser enforced restrictions with website settings. It is important for users to understand when their browser is protecting them, as opposed to giving them the impression that they are only given a choice by the website.

Inline permission elements would also provide further options for dark patterns like adding confusing styling to the element or providing misleading context. A site could label an option “Show me more relevant search results” and the button is labeled “Allow location access”. Using styling, the actual “Allow location access” text could be made hard to read, hidden by an overlay or displayed in a language the user does not know. The explainer addresses this with CSS restrictions but since CSS sanitization is not a solved problem, this seems like an incomplete solution. Having the controls inline will also make it harder to prevent clickjacking attacks.

Permission popup UI should be kept at least partially outside the content area to clearly indicate to users that they are interacting with the browser.

A reasonable compromise might be to let the site add an explanation. "This site is requesting location permissions: location permissions are used to show you offers in your area.” or “This site is requesting microphone and webcam access: microphone and webcam are necessary for you to speak in the call”. This is still prone to bad framing: “We need your location to make the site as fast as possible for you.”.

[zcorpan]

We're aware of the limitations of the line of death concept. Possibly occlusion detection could be helpful to avoid some attack scenarios for inline prompts.

Still, we're not convinced that it's a good idea to put more browser controls in the content area and allow positioning/styling. It adds to the confusion about what is provided by the website and what is provided by the browser, which doesn't seem great for security.

[b1tr0t]

Thanks for the feedback!

We believe the confirmation UI (see low fidelity mock below) should provide a strictly equivalent-or-safer environment from a user safety point of view, as the blurred scrim makes it more difficult for sites to manipulate users to act against their own interest, and could (at the user agent’s discretion) extend from above the line of death. The confirmation UI is the critical moment in user safety. The restrictions in primary UI are concerned with mitigating potential for user annoyance and clickjacking.

It’s worth noting that this does not add additional browser control to the content area beyond how browser controls can currently be triggered via JavaScript. In fact, it captures a greater level of confidence in the intentionality of a user click than say a button element with attached script.

We also believe that, as a semantic element, a permission element will have advantages from an accessibility perspective for magnification and screen reader users as this would allow the intent of the button to be accurately announced by the reader and would be in closer proximity to the user’s viewport when using an OS magnifier. We haven’t included this yet in the explainer, and plan to add more details on this soon.

We think this should be a net win for user safety, accessibility and reduced cognitive load, and hope we can address your concerns. We’d like to discuss this further, if you’re up for that?

[simon-friedberger]

Just to give my understanding of the proposal (please correct me):

1. One part is having a new special element which requires more explicit user activation and is therefore allowed to re-trigger permission prompts. This solves: "Insufficiency of existing mitigations", "Context", "Regret" and the part of "Location" that is about embedding the control in a logical place in the site.
2. One part is a permission prompt that can be displayed in the content area. Given (1.) it can be displayed close to the button. This solves the part of "Location" which is about not showing the permission dialog at the other end of the screen.

I certainly think there is value in (1.). (The engineering effort/feasibility of realizing the security section is still concerning.)

The explainer should maybe be clearer about the relation to https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis in general. It's also interesting to consider the list at https://developer.mozilla.org/en-US/docs/Web/Security/User_activation. For which of these should there be a specific element?

It's probably also worth discussing if this would really satisfy developers. What would it look like here:

[zcorpan]

The original position was based on some misunderstandings on our part.

Per discussion offline, we will reevaluate after some clarifications in the explainer.

[jan-ivar]

I gave feedback via email on the PEPC breakout presentation after TPAC. I was asked to reproduce it here:

The workflows in the demo and screenshots in the slides left me with questions, like:

1. How is a video conferencing website expected to use PEPC?
2. How would this work with Firefox's default per-device permission model?
3. How would this work with Firefox's in-prompt device picker?

I'd suggest presenting PEPC in a more realistic video conferencing context to answer this. Specifically, a context preoccupied with video conferencing, not secondary user concerns like website permission priming or permission revocation.

Video conferencing sites present users with camera and microphone toggles. These might prompt for permission initially (if necessary), but are generally understood to turn self-capture on and off quickly, controlling whether others can see and hear them. Users expect them to work instantly with a single click for privacy. No permission is revoked.

Where would PEPC buttons fit in here? Would we use one, two or three of them? They appear designed to remain prominently placed, and if clicked again bring up a "continue allowing"/"stop allowing" dialog I find confusing. Confusing, because permission revocation isn't a central task. — Is there user research to indicate users want a prominently-placed permission-revocation-prompt-opening button?

★ Visual discontinuity

The presentation makes a convincing case for centered browser prompts for camera and microphone. Thanks for this. But Safari already has them:

This seems solvable without native elements. I'll forward this feedback to our UX team.

★ Developer-push model
★ Interruption

Not requiring transient activation in getUserMedia was a mistake. But is it a problem on well-behaved websites? New APIs cannot address poorly behaved websites. So it seems this must be fixed in getUserMedia. Mitigations possible there might include: require transient activation to resolve its promise (Firefox already requires focus, which the spec allows), or UA mute tracks ahead of transient activation (which the spec also allows).

Well-behaved sites like https://permission.site/pepc and https://jan-ivar.github.io/dummy/enumerate.html present buttons that raise browser prompts when clicked. What value do native elements bring here?

★ Difficult to revert past decisions

This seems like a Chrome UX problem to us. Firefox clears grants and blocks on reload by default, making it hard for Firefox users to perma-block/perma-grant by accident. Our users aren't perma blocked by a single "no" click they made in the past (they'd have to "✅ Remember this decision for all cameras and microphones"). It's still a problem, but a much smaller one

★ Lack of context

The presentation shows a priming page without context, which seems concerning:

By centering permission as a first-order goal, PEPC appears to encourage websites to ask for permission out of context, an anti-pattern we know subjects Firefox users to priming ahead of every meeting by default, something we're actively fighting against.

I would urge Mozilla to oppose this direction if this is the intent. Lack of integration with Firefox's permission model is also an issue of course.

The native elements aspect of PEPC seems interesting to me in areas they might avoid prompts entirely...

Have you considered applying a PEPC approach to the double-mute problem? If a user has "Paused" capture through Safari in this example, the application state (whether others can see or hear you) is updated. But Safari prompts the user only if they unmute from the website, not from the browser UX. Might a native element approach avoid this prompt?

[simon-friedberger]

Webkit position for context: WebKit/standards-positions#270

[b1tr0t]

Thanks for the feedback!

re: 1. I agree, there are a number of possible configurations of using the PEPC. I'm going to walk through the meet.google.com OT experiment example below and I’ll call out reasonable alternatives in the walk through (though this isn’t exhaustive, multiple reasonable alternative journeys exist.).

You can test the journey on meet.google.com with a stable or dev version of Chrome. A caveat about split testing: both Chrome & Meet have split tests running, including differing behaviours of the PEPC (confirmation dialog positioning, options etc) and testing against the control condition, so you may see different behaviours or may not see the PEPC at all.

If the user has not previously accepted Mic/Camera permission, they join the meeting and have warning indicators below the meeting view that Mic/Camera are not currently active. (In this case the ! indicators.)

Alternative: Other video conferencing providers intend to make the Mic/Camera indicators themselves the PEPC. However, the PEPC experiment does not currently support an “Icon only” display. This is a limitation of the experiment implementation right now, we intend to support the use case of icon-only PEPC which would make it easier for developers to use the PEPC directly as a camera/mic control in the meeting.

Clicking on the warning state mic or camera button shows a help popover, in Meet’s experimental implementation this popover contains the PEPC. (The PEPCs in the page are the "Use Camera" and "Use microphone and camera" buttons.)

Clicking on the PEPC reveals the confirmation UI.

Re: 2 PEPC doesn’t make assumptions about the underlying browser permission model and is compatible with a per-device permission model. The confirmation UI above would work well with Firefox’s per-device permission model: where the “🎥 Use your cameras” text , a form input can be populated with available devices. The centered full screen UI of PEPC could give user agents more screen real-estate and more prominent visibility for fine grained options such as device pickers.

Re: 3 Many video conferencing sites use some kind of priming to reduce user error. In some cases this can be annoying, but it’s implemented by so many sites because users are benefitting from it. PEPC will make this less necessary as it lowers the risk of user error for sites and offers a path for users to safely and easily revisit decisions in the same session (and this is a goal). PEPC can be used directly without priming, however, to reduce variance between control & experiment conditions the priming has been retained in the current live Meet experiment. We’re looking forward to test data in the future without the priming screen but we need to add some unimplemented features first.

You’re right that removing permission in a live video conference screen isn’t a common use case. In the case where the PEPC is being used directly in a meeting, PEPC pseudoclass :granted can be used to hide the PEPC and display an alternate element.

Changing permission state from Accept to Block is useful trust building for other use cases, for example, to embed in a “Permission Settings” page for a web app. This can give users a better feeling of control over an app.

As you mentioned, Safari already takes a centered approach to permission confirmation prompts, and Chrome uses centered prompts as well on mobile. One reason Chrome hasn’t implemented prompts like this one on desktop is that they’re very disruptive to the user journey if they are unwanted, much more disruptive than the prompt UI attached to the omnibox which is easily ignored. The PEPC aims to mitigate how disruptive these are by ensuring strong user intent to display the permission request via the clickjacking mitigations.

PEPC alone can’t resolve bad actors behaving abusively since they will retain access to existing APIs i.e. getUserMedia. However, (1) PEPC offers genuine utility for well behaved sites today, and, (2) offering a harder to game declarative alternative can be a prelude to making changes to existing API behavior to incentivize a shift. Making changes to API behavior is a large undertaking, so our preference is to collaborate on these as a parallel but separate effort. Before we can make a push in this direction, we need a better alternative.

With respect to the PEPC example slide with the PEPC located in the center of the mobile screen – this isn’t proposed intended usage, it’s a mock intended to illustrate just the PEPC. I can see where the confusion comes from though – so here's a mock of a realistic scenario (although worth mentioning again it doesn't have to be used in this kind of priming journey -- it could also simply be embedded directly into the live conference).

We’re very interested in use cases where the confirmation UI could be entirely skipped! We think these are ones in which the security and privacy risk to the user is minimal. For example, allowing notifications can be annoying but does not expose the user to significant new security or privacy risks. Curious as to your thoughts here?

I do think the PEPC can assist with the “double mute” problem in that it could be reasonably safe for the confirmation UI to modify not just the permission state, but to also unpause the browser video/audio feed if the user has affirmed (or reaffirmed) that they will Allow the permission. What do you think?

[jan-ivar]

1. How is a video conferencing website expected to use PEPC?

re: 1. I agree, there are a number of possible configurations of using the PEPC.

None of the use cases presented are for a permission toggle.

If the camera/mic PEPC buttons aren't directly usable in video conferencing, what are they for? Shouldn't they be redesigned? And why would any website keep them around once it has obtained permission?

... we intend to support the use case of icon-only PEPC which would make it easier for developers to use the PEPC directly as a camera/mic control in the meeting.

But toggling permission and toggling capture aren't the same thing.

... You’re right that removing permission in a live video conference screen isn’t a common use case. In the case where the PEPC is being used directly in a meeting, PEPC pseudoclass :granted can be used to hide the PEPC and display an alternate element.

Wouldn't this undermine user expectations of what these buttons do? Also, from a web developer perspective, this sounds hard to use, and the explainer makes no mention of it.

2. How would this work with Firefox's default per-device permission model?

Re: 2 PEPC doesn’t make assumptions about the underlying browser permission model and is compatible with a per-device permission model.

How would a user open two cameras with PEPC? How would Firefox ensure its device choices satisfy constraints passed into getUserMedia(constraints)?

Re: 3 Many video conferencing sites use some kind of priming to reduce user error. In some cases this can be annoying, but it’s implemented by so many sites because users are benefitting from it.

Why are no websites priming users for screen-sharing? getDisplayMedia still doesn't require transient activation in Chrome, so that can't be it. Could it be because Chrome doesn't block screen-sharing on a negative user response?

Clicking on the warning state mic or camera button shows a help popover, in Meet’s experimental implementation this popover contains the PEPC.

What's the user benefit to being asked twice (once by Meet's "help popover" and again by the browser prompt)? This is today's priming pattern, where the goal is to secure the website a positive response and make it hard for the user to block.

So far, none of the use cases presented show how PEPC might reduce priming.

[simon-friedberger]

The proposal essentially consists of two parts

1. In-content buttons for requesting permissions with strong user signal
2. In-content area permission dialogs

Goals

The main goal seems to be to prevent “permission regret”, however, this is to some degree a homemade problem because browsers overreact to permission spam with aggressive blocking. It’s not clear how important point (2.) above is for the proposal.

PEPC claims to "improve the permission request flow", but for whom? Websites or users?

1. The metrics chased seem to favor websites, at the cost of users. A low conversion rate is a sign of permissions doing their job. A high conversion rate is a sign they're not. PEPC seems to chase the latter.

2. Regret. It allows users to revert a previous "deny" decision, but not an "allow" decision (websites have no incentive to show this option).

3. Permission priming flows thwart the agent's interaction with its user. We're all familiar with websites asking for notification permission ahead of the browser: If you deny, the website is free to bug you later. If you allow, you're asked again, wasting a click (on every visit in allow-once browsers). Blocking bad websites becomes a task for experts (close your eyes and hit "Allow" to step out on the invisible bridge where the block option will appear). Is the goal to reduce or increase priming?

4. Unaddressed root causes of priming and regret. Why are no websites priming users for screen-sharing? getDisplayMedia still doesn't require transient activation in Chrome, so that can't be it. Could it be because Chrome doesn't block screen-sharing on a negative user response? This suggests website priming is a reaction to Chrome UX. Might a Chrome UX fix address this without needing to standardize anything in other browsers? For example, UAs are free to include transient activation or any other positive signal of intent to reverse a previous block.

Complexity

There is significant complexity to this feature. Styling must be sanitized in a way that prevents tricking users into giving permissions and clickjacking must be prevented. New dark patterns like hiding the buttons after a permission is granted need to be handled (see UI/UX below). This complexity increases when PEPC buttons are allowed to be icon-only or skip the second permission dialog, both of which have already been discussed.

UI/UX

Page UI may suffer due to insufficient styling options and differences between the elements in different browsers. Additionally, if users are currently unable to find the UI to re-enable permissions, this situation will get even worse if the UI is page specific. This empowers pages instead of users. A user who wants to remove a permission will be even less likely to know where the UI is. This gets worse when considering possible API improvements like a mute button.

API

The API encourages websites to ask for permission ahead of access, a repeat of w3c/permissions#83. This makes it incompatible with Firefox's permission model for camera and microphone, which is per-device by default.

Conclusion

This proposal seems to benefit websites more than the users and implementing it reliably will be challenging. Improving current UI and permission request blocking is a better alternative.

[johannhof]

Hi @simon-friedberger, speaking as an interested observer who is not on the team that implements this work, what about your feedback justifies a "negative" label vs. say "neutral"? There doesn't seem to be concrete harm from the proposal if it was implemented, your main criticism seems to be that it's complex and difficult to implement reliably.

I'm not in a position to challenge your verdict, I just wanted to point out this perceived inconsistency. :)

[simon-friedberger]

Hi @johannhof - the position is negative because it creates complexity without addressing the root causes and without addressing certain issues like access to multiple cameras.

I could certainly see us be neutral (maybe even positive) to "something like PEPC", but not without some major rework.

[jan-ivar]

I'd also point out the (conflicting) "Goals" section contains several points that seem harmful.

PEPC undermines permission-on-use.

This seems particularly harmful to interop right now since Chrome unilaterally ties device exposure to permission, against spec web-platform-tests/interop#849. This creates a reason to obtain permission ahead of capture in chromium only.