Intent to Implement And Ship: Temporarily stop permission requests after 3 dismissals

[Dominick Ng]

Primary eng (and PM) emails

domi...@chromium.org

emilysc...@chromium.org

Summary

Temporarily stop an origin from requesting a permission following the 3rd dismissal of a permission prompt from that origin. The stop will be lifted after some amount of time has passed (initially 1 week), after which the origin may request the permission again. A further dismissal will apply the temporary stop again.

Dismissals are counted per (origin, permission) pair. Once the temporary stop is applied, permission requests behave as if the user has immediately dismissed the prompt. There will be a console message informing developers of what has happened with a link to the chromestatus entry.

Motivation

Dismissing a permission prompt in Chrome blocks the permission, but the origin may prompt again, usually after a page refresh. Allowing or blocking the permission is a permanent decision.

In Chrome Stable, over 95% of permission prompts that users allow or block have strictly fewer than 3 prior dismissals. Over 75% of permission prompts that users allow or block have strictly fewer than 1 prior dismissal. Conversely, over 25% of permission prompts dismissed by users have 3 or more prior dismissals.

Once a user has dismissed a prompt 3 times, they are increasingly unlikely to ever allow or block the permission. Based on our metrics, this change should have very limited impact on the actual number of times that origins are granted or denied permission. It will also influence developers to prompt for permission at appropriate times and with relevant context.

Interoperability and Compatibility Risk

Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

No APIs are being changed. Some amount of unpredictability is introduced, but permission prompts are already unpredictable as users may ignore them or take substantial lengths of time to respond. This change will usually result in the same effect for developers (blocked permission) with a large reduction in the number of prompts to users.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All platforms excluding WebView.

OWP launch tracking bug

None

Entry on the feature dashboard

https://www.chromestatus.com/features/6443143280984064

Requesting approval to ship?

Yes, if approval is required (this will not be violating any specs). We'd like to ship in M58.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[nate.k...@ikan.be]

Are there plans to allow users to manually overrule this permission request rule, for example if a user reconsiders before the week is over?

[Dimitri Glazkov]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Miguel Garcia]

If a user reconsiders they can always directly grant/deny the
permission from the lock or chrome settings.

non owner LGTM, this is great.

[Philip Jägenstedt]

LGTM3

Although I agree that no normative spec changes anywhere are needed, is there some appropriate venue to let others know that this change is being made? Web developers may ultimately have to change the way they write code in response to this, and those changes could have a non-zero impact on other engines.

https://w3c.github.io/permissions/ seems like the most obvious venue, and a separate state like "throttled" would allow web developers to notice in the wild that this is affecting them, where they won't have access to the console messages.

[Ojan Vafai]

+Rick Byers is designing a deprecation+interventions reporting API for getting data about these things from the wild. The plan is to hook all of these intervention console logs cases up to that API eventually.

[Dominick Ng]

Update: since we got approval fairly late in the M58 cycle, we're going to delay shipping until M59 to ensure that we have good testing through canary, dev, and beta channels.

[Xiaohan Wang (王消寒)]

What's the status of this work? Is there a bug somewhere tracking this?

[Dominick Ng]

This is currently rolling to stable with M59. The launch bug is crbug.com/697686.