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 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)