Page Embedded Permission Control (Permission Element)

[b1tr0t]

Session description

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.

A permission model designed to be initiated by the user would solve these issues. If the user initiates the permission request it ensures that:

• The user understands the purpose of the permission, or at least has enough context to feel comfortable engaging in an activity that uses this permission.

• The user’s current flow or task is related to granting this permission and as such it’s unlikely that the permission request could be interruptive.

• The user agent can ensure the subsequent UI is placed near the current focus of attention of the user. This is because the user has just interacted with some piece of UI to request the permission which means their focus is likely in the area. Because of the above, it is unlikely that such a placement is interruptive or annoying.

This breakout would discuss a proposal for Permission Embedded Permission Control [explainer] [deck] and intends to continue the dialog from the w3c Workshop on Permissions held December 2022.

Session notes

Session goal

Feedback on a proposal to create a Page Embedded Permission Control (Permission Element)

Additional session chairs (Optional)

No response

IRC channel (Optional)

#pepc

Who can attend

Anyone may attend (Default)

Session duration

60 minutes (Default)

Other sessions where we should avoid scheduling conflicts (Optional)

No response

Estimated number of in-person attendees

Fewer than 20 people

Instructions for meeting planners (Optional)

No response

Agenda, minutes, slides, etc. (Optional)

• Slides
• Minutes
• Live Google Doc Minutes
• Calendar