Require user gesture for notification permission request

AshleyScirra · 2017-09-23

I’ve noticed some websites ask for permission to send notifications immediately on the first visit. This is annoying[1], enough that guides appear showing how to turn them off [2]. It’s also surprising that these days a website often cannot even start autoplaying media upon visiting a page - to avoid annoying users - but it can still ask for you to permanently allow the website to send you notifications at any time, which is a good channel for spam.

I can’t think of any good reason someone would click “Allow” for notifications right away, without knowing anything about the website, the kind of content it will send, and the frequency. The user has likely not even clicked or touched inside the page yet. Nobody can make a good decision at this point. It seems websites are relying on users making bad decisions: hopefully some people will click “Allow” by accident, and then the website can spam them.

Why not require a user gesture? It would block this dark pattern entirely and still allow legitimate sites to work. It seems likely to improve the user experience since even if a website shows a prompt with a button to enable notifications right away, they’d probably at least try to explain why it’s useful to do so. I suspect many sites would instead relegate the option to a less intrusive UI.

[1] https://twitter.com/MattWilcox/status/910776534524448768

[2] https://www.howtogeek.com/288946/how-to-stop-websites-from-asking-to-show-notifications/

AshleyScirra · 2017-09-24

Filed a spec bug here: https://github.com/whatwg/notifications/issues/108

simevidas · 2017-09-24

I’ve proposed this a year ago on the forum for Chrome interventions. Here’s the response from Chrome team:

The permissions team agrees that onload permission requests are incredibly irritating and shouldn’t be done. We also strongly feel that such requests should be made in context.

We’ve been looking into a number of things to try and discourage onload requests. Unfortunately, detecting if a permission request is made on page load (or very soon after page load) is pretty tricky to do accurately. Like Ojan said, any change we make could also break interop (Chrome won’t let you call geolocation/notifications/etc. when others browsers will).

We’ve reached out to various sites which use onload prompts to try and encourage them to not do that. A lot of these sites have basically ignored us, e.g. Facebook, which hits you with a door-slam black background page with a permission request after you login (see attached). They’ve basically said, “this works best for us wrt CTR” when we tried to tell them not to do this. This is an outlier case, but it’s representative of the attitude we’ve often encountered.

There are also sites which genuinely won’t work properly without a permission grant as early as possible (weather sites, map sites, etc.). In these cases, we don’t necessarily want want to prevent a prompt, because it will only confuse typical users who might not understand why the site isn’t working properly.

We have early metrics suggesting that permission requests are 3-4x more likely to be granted by users if they are accompanied by a user gesture - i.e. that they’re (probably) triggered by the user explicitly clicking on something on the page and directly showing interest in a feature which requires permission. We’re probably going to try an experiment where requests for permission without a gesture are simply ignored (and maybe even work to get that codified in the spec).

So yes, in summary, we know onload prompts are annoying. We’re working on solutions to try and address the situation, but it’s a challenging problem for a bunch of reasons.

AshleyScirra · 2017-09-24

I don’t think other permission prompts need to be changed. I can see that something like a geolocation request upon loading a map makes sense. It’s specifically for the notifications permission only, since I don’t think there’s a use case for displaying that immediately. I think a site like Facebook is an exception, because everyone already knows what Facebook is and what its notifications are likely to involve. But we shouldn’t make special rules for specific sites. In general, visiting a site should not be able to prompt you immediately, and Facebook should play by those same rules as well.

It should also be easy to impose the user-gesture requirement, since many other APIs are already behind that; I don’t understand why they talk about detecting a request on page load being “pretty tricky”. Also obviously asking websites nicely is not going to work and is never going to scale to the whole web, I don’t know why they even tried.

So I don’t understand that reply. I still cannot see any reasons why the notification permission request shouldn’t require a user gesture.

justsomeguy · 2017-10-08

IMO, this is best done with a UI icon indicating that notifications are available. In such a case, the feature remains discoverable, but there are never prompts unless the user requests one.

mkay581 · 2017-10-09

I’ve always thought that unblocking notification permission requests (that I’ve previously blocked) or re-enabling them (after having denied them) pretty difficult for an average browser user to do. The option is buried deep into the browser settings–at least on Chrome. People also are likely to forget that the feature was even available (after having previously denied notification permission requests). That said, I’m in favor of an icon. I would also go as far as making the icon clickable, which would give a user quick access to manipulate any notification settings.

AshleyScirra · 2017-10-09

That’s a good idea actually. Outside a user gesture it could quietly create a toolbar icon, like blocked popups in Chrome. The user can still click on it and allow if that’s what they want.

collimarco · 2019-03-27