1 of 14

PEPC

Page Embedded Permission Control

ICE COLD ! DELICIOUS !

☀️

chrome permissions

☀️

User friendly!

Now with contextual integrity!

5.

¢

2 of 14

Page Embedded Permission

Control

example.com wants to

📍 Use your location

Block

Allow

example.com wants to

📍 Use your location

Block

Allow

example.com wants to

📍 Use your location

Block

Allow

pjmclachlan@chromium.org

mharbach@google.com

On behalf of the

Google Chrome Permissions Team

Many slides cribbed design from sereeena@google.com

3 of 14

4 of 14

The user lacks the context of why a permission is being requested.

Poorly timed permission requests can interrupt the user .

Permission requests are often outside the user’s focus of attention.

Interaction design considerations are frequently overlooked during product design phases.

Recovering from a ‘block’ decision is hard.

User problems

5 of 14

An example

6 of 14

Another example

7 of 14

Alternatives explored

8 of 14

Oh, prompts are interruptive?

Introducing: the permission request chip

Out of the way
Grant rates dropped from 20% to less than 1%

WAS NOT SHIPPED

9 of 14

Oh, risks are hard to explain?

Automatic permission revocation

One-time grants

SHIPPED!

10 of 14

Oh, there’s too many prompts?

Hide what people don’t want

Based on user behaviour (settings opt-in, repeated denials)
Based on site behaviour (high-prompt/low-grant sites)

Chrome Permission Suggestion Service (CPSS)

On-device, privacy-preserving ML that predicts likelihood of user grant
If highly confident (>95% precision) user will not grant, we show the chip UI

Bilogrevic et al. ”Shhh...be quiet!” Reducing the Unwanted Interruptions of Notification Permission Prompts on Chrome. USENIX Security, 2021.

SHIPPED!

Too many prompts? To mitigate this, we can bring back out old friend, the little chip UI. With a twist this time — this time we hide some prompts, only the ones people don’t want.

To start with, we can look at some simple heuristics.

First, let’s let people decide how they want to see their prompts. Maybe they never want to see those pop-ups. So we introduced a setting where they can set and forget.
Second, we can infer intent from someone’s behaviour. For example, if a user denies a notification prompt from a site three times, we can safely assume they don’t want it. So from then on, we also show the quiet chip.
We can also use telemetry from users who have opted in, to see which sites are the worst offenders. We made lists of the sites with the highest notification volumes and lowest grant rates. Take the worst 10%, and show the quiet chip for them.

Those are the simple heuristics. We can go further.

11 of 14

How web APIs work

Website tries to use a capability
Browser checks for permission
If no permission -> pop prompt

At no point before this does the user need to be involved!

“Developer-push”

12 of 14

∿∿∿ PROPOSAL ∿∿∿

The Permission Element is a new HTML element embedded into web content that allows users to initiate a permission request flow.

This reframes the current permission model from developer-push to user-pull, where we can be confident of users’ intention to use web capabilities.

Public explainer

13 of 14

∿∿∿ PROPOSAL ∿∿∿

14 of 14

∿∿∿ ADVANTAGES ∿∿∿

It is non-interruptive: it is static, small, and contained in the content area on the same z-level.

It is discoverable: it can be placed by the developer within the user's focus of attention.

It provides more contextual information: it has a visual manifestation as opposed to being a procedural API, requiring developers to think about integrating it into the user journey at UX design time.

It allows users to revert a previous "deny" decision if they have changed their mind and are now interested in the feature that the site provides.