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.