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?