![Thomas Steiner](https://web.dev/images/authors/thomassteiner.jpg) Thomas Steiner [GitHub](https://github.com/tomayac) [LinkedIn](https://www.linkedin.com/in/thomassteinerlinkedin) [Mastodon](https://toot.cafe/@tomayac) [Bluesky](https://bsky.app/profile/tomayac.com) [Homepage](https://blog.tomayac.com/)
Until now, when a user visited a site that requests a permission, a bubble pops up to prompt the user to make a decision. For example, you can see the geolocation permission prompt as implemented in Chrome up to version 96. (You can try this and other permissions on our demo site [permission.site](https://permission.site/).) ![Chrome geolocation permission prompt](https://developer.chrome.com/static/blog/permissions-chip/image/chrome-geolocation-permis-e6959b1ca9942.png) Chrome's telemetry data proves that a lot of permission prompts are ignored. You can explore the [notification permission data](https://developers.google.com/web/updates/2020/02/notification-permission-data-in-crux) in the Chrome UX report yourself. For now, consider the table below that shows how Windows users reacted to the notification prompt on sites in an accumulated way, while noting that geolocation prompts saw a similar dismiss or ignore behavior. | Action | Percent of notification prompts | |---|---| | Allow | 6.69% | | Block | 9.20% | | Dismiss | 35.76% | | Ignore | 47.19% | Given an ignore and dismiss rate of approximately 85%, and especially given how much the prompt stands out and insists on users making a decision immediately, there is a conflict between the level of urgency assumed by the browser versus the user's preference for waiting to make a decision. This creates the perception that it's "annoying" for a site to ask for a permission because it will be lost in the potential extra things users need to react to like cookie consent banners, newsletter signups, etc. ## New design From Chrome 98 on, we therefore introduced an animated chip UI which appears next to the lock whenever a permission is requested. This consists of an icon and label describing the permission being requested. Our aim was to improve the experience of web browsing while avoiding permission requests that are generally unnecessary for the vast majority of users and frequently ignored or dismissed. The existing prompt bubble will be shown when the request chip is clicked (if not already shown) and the request UI is automatically augmented with the request bubble based on the following heuristics: - The permission was triggered through a user gesture when interacting with the site itself rather than automatically triggered by the site. - The permission is deemed essential and generally non-spammy. This includes camera, microphone, and camera paired with microphone. ![Flow diagram going from padlock to the geolocation prompt, which, if dismissed, results in the 'geolocation blocked' icon, which, after a four second delay, is finally replaced with the padlock again.](https://developer.chrome.com/static/blog/permissions-chip/image/flow-diagram-going-padlo-398258680af8b.png) ### Forcing the new design Since this is a staged rollout, you can force the new design by toggling the following flags: - `chrome://flags/#permission-chip` - `chrome://flags/#permission-chip-gesture` - `chrome://flags/#permission-chip-request-type` ### Flow of the new design #### Without user gesture For non-essential permissions not triggered by a gesture, the prompt no longer intrudes on the site contents, and does not insist on an immediate decision. The user can ignore the request chip until they have enough information to make a decision. #### Without interaction With no interaction, and after a short delay, the request chip will automatically collapse to just a blocked icon (to indicate the permission being temporarily blocked), before being dismissed entirely. The aim is to get out of the way of users who choose not to make a decision letting them do so without any interaction. ![Flow diagram going from padlock to the unobtrusive geolocation chip, which, after a twelve second delay results in the 'geolocation blocked' icon, which, after a four second delay, is finally replaced with the padlock again.](https://developer.chrome.com/static/blog/permissions-chip/image/flow-diagram-going-padlo-f46214095ed07.png) ### Expected short-term impact In the short term, and until users get used to the new UI, it is likely that site owners will observe lower grant rates for sites, especially for those that auto-request permissions without priming or demanding a user gesture (which is considered a [bad practice](https://developer.chrome.com/docs/lighthouse/best-practices/notification-on-start.md.txt) anyway). This acknowledged downside is vastly outweighed by the less interruptive experience. ### Best practices It is up to the site to ensure it provides the necessary context and only requests permissions at the appropriate and expected moment. Permissions that have been temporarily blocked---through a user ignoring the request or dismissing the prompt---can request the permission again within the same session. Only do this if the permission is essential for the site or feature to work, otherwise it runs the risk of annoying users and getting auto blocked. In those cases we show the [quiet messaging](https://blog.chromium.org/2020/01/introducing-quieter-permission-ui-for.html) that was introduced in Chrome 80. For more general guidance, see [Permission UX](https://developers.google.com/web/fundamentals/push-notifications/permission-ux). ## Outlook and conclusions There are plans for further UI and UX improvements. The Chrome team is already working on them and investigating potentially more aggressive auto-blocking of permissions based on prior behavior. You will learn about the news here once these plans mature. Concluding, the new UI reduces the perceived insistence on a decision and improves the browsing experience. Since most permission prompts are blocked or ignored, the met objective was to improve the general experience of browsing, while not breaking user flows when showing a permission prompt, especially in situations where permissions are required to complete a use case. ## Acknowledgements This document was reviewed by [Joe Medley](https://github.com/jpmedley).