Require user gesture to request notification permissions

[Ajedi32]

One behavior I'm starting to notice with increasing frequency on the web is sites that immediately prompt users for permission to show desktop notifications the moment they land on the site.

This is very annoying and I nearly always immediately hit "Block", especially when it's just a random news article or forum post I got to through Google or Reddit. Personally I'd prefer if browsers would just ignore requests for this permission that occur automatically without any sort of user interaction.

As evidence that this is a problem, here's a short list of examples of sites that immediately prompt for notification permissions the moment you visit the site:

• https://themerkle.com/
• https://www.bhphotovideo.com/
• https://joaoapps.com/
• https://community.storj.io/
• https://fee.org/

If you use Chrome, there's a pretty decent chance you can find numerous other examples by going to chrome://settings/content/notifications and looking through the list of sites you have set to explicitly block notifications from.

[cramforce]

I don't think this would help.

Many sites are now switching to a 2 step flow. One app layer popup (that cannot be permanently dismissed) and which after click opens the system UI. This is just as annoying and it would not be blocked by requiring a user action.

[Ajedi32]

Yeah, interstitial popups are a whole other issue. None of the examples I listed above use that solution though, so I still think requiring a user gesture would be helpful to at least prevent those cases.

That said, you do raise a good point: if notification prompts are changed to require a user gesture will sites respond by adopting an even more annoying interstitial pop-up prompt to ask users to enable notifications?

I'm hoping that many of the sites that currently prompt for notifications without a user gesture are just being lazy; implementing the simplest possible solution while ignorant about how annoying that behavior is. In such a case, I imagine the site would be hesitant to deploy a solution like interstitial pop-ups that's much more obviously obnoxious to their users.

Meanwhile the sites brazen enough to use interstitial pop-ups are already doing so for other reasons (like "Sign up for our newsletter!") and don't need any technical reason to do so.

That's what I'm hoping anyway. It's kinda hard to make predictions about the future actions of site operators without having any data to base those predictions on.

[beverloo]

We (Chrome) are actually planning some experiments to move in the direction of making this more restricted. It's very annoying indeed, and as more developers adopt push notifications the problem is getting more severe.

The idea is to require the user to have some engagement with the site before it can request permission—what we call site engagement score, unless there is a user gesture. Requests would be settled with default indicating that the user dismissed the prompt without making a decision, avoiding sites from either displaying a full-page overlay until the user makes a decision, or displaying an overlay informing the user how to undo their previous decision.

User gestures are significant, because many sites delegate to push aggregators for distributing their notifications. Such aggregators live on origins that the user won't have visited before, while they are more likely to actually want to opt-in at that point.

In the very long past (Chrome ~32) we actually did require a user gesture for all notification permission requests, but we found that this was inconsistent with other permissions, and also that many sites worked around this restriction by having a full-screen transparent <div> capturing gestures, requesting permission then anyway.

Other ideas are most welcome of course! We're still very much investigating :).

[drewzboto]

One thing to note. A few vendors (including us) that provide a hosted push notification service for customers who have not moved to HTTPS everywhere, and therefore cannot use service worker, are dependent on triggering notification request without a gesture as a workaround.

User flow:

1. User lands on example.com and browses around
2. User triggers engagement flag and sees a banner informing them of the benefits of push notifications
3. User agrees and clicks on banner
4. User is redirected to example.vendor.com and gets the browser push notification request (and additional information on the value of the subscription)
5. User gets redirected back to example.com

In step 4, we are triggering the request without a user request directly, as that was done on the previous step/site.

Adding this intervention will essentially kill this equivalent offering from a few push vendors, most of whom are trying to follow the rules here.

Examples of this include https://www.lancome-usa.com and http://www.extrastores.com/en-sa/ (which was featured as a developers.google.com case study)

[benlast]

@beverloo if the site requires some level of engagement before subscription's possible, then I think it's important that code have some way to determine if that level has been reached. It's common practice for our customers' sites to show an initial prompt (or button, or other "non-intrusive" widget) asking the user if they would like to subscribe, similar to an invitation to subscribe for email updates. Answering yes to that prompt will then cause the request for notification permission. Obviously, if the request is going to be unsuccessful because the user hasn't engaged enough, then we don't want to show that initial prompt.

[benlast]

On user gestures; it makes sense that requests for notification permission, or calls to PushManager.subscribe() should happen in response to a gesture, but there are use-cases that need exceptions. For instance, the amp-webpush proposal plans to have a service worker call subscribe() in response to a postMessage, that may be invoked via an iframe... the gesture privilege would need to be passed through a significant chain of events.

[dylanpyle]

@drewzboto With full respect for the work your team is doing, that seems like an anti-pattern. Centralizing push notification access with a single 3rd-party vendor would let vendors use sneaky tactics e.g. if a customer has allowed notifications for one site using a push vendor, they could offer other sites the ability to push without any opt-in at all.

Looks like your app uses separate subdomains for each site, but that's essentially on the honor system and doesn't seem like a strong enough justification to avoid fixing this issue.

[drewzboto]

@dylanpyle I don't think we're advocating not fixing this issue, just making sure this is rolled out at the right time. I just want to be clear on a few things to help vendors like us who are trying to do the right thing gradually:

1. We use this centralized approach only as a fallback. We still try to start all customers with notifications on their own domain with a user gesture to trigger opt-in.

2. Lower loading priority of cross-origin iframes #1 only exists because not all customers are ready for HTTPS everywhere required to go with the recommended approach. This will be the case for the majority of eCommerce sites in 2018 unfortunately, even for some of from the largest sites out there. I know it seems simple to just flip on HTTPs everywhere and move on the fallback approach we have, but we have large enterprises swimming in legacy technology that don't have a great path forward for their eCommerce platforms. For example, one of the largest eCommerce SaaS platforms (Salesforce Commerce) only started supporting HTTPS everywhere recently, and still needs to roll that out to customers

Because of this, we're advocating that any intervention is rolled out slowly based on the uptake of HTTPs everywhere across sites, with enough of a published schedule for vendors like us to educate our customer base further with a mitigation plan. These things move slow, and it would be a shame to suddenly turn off the majority of our notification subscribers instead of working with our customers to educate them further on proper push notification etiquette while they get their systems ready

[DemiMarie]

@drewzboto I think that those enterprises should instead be pressuring their platforms to provide HTTPS. Is there some reason that HTTPS is so hard? I do know that there are difficulties related to links, but that can be solved by post-processing the HTML before it is served to the user.

[collimarco]

I am the founder of Pushpad and I am really interested in this discussion, because we want to recommend the best practices to our customers. Currently we let the developers choose when they want to trigger the prompt: they can prompt on page load or they can show the prompt when the user clicks a button or performs any other action.

However many of our customers actually display the prompt on page load: even if this doesn't offer the best UX, probably it generates enough conversions. Probably if someone visits a website related to events, he already knows what kind of notifications he can expect... the same for an e-commerce, etc. Also, revoking the permission when you receive an unwanted notification is very easy.

Is blocking the notifications on load the right solution?

I don't think that this is the right solution, simply because this is what will happen:

• websites will start showing 2 step prompts; many vendors already offer this kind of solutions; these 2 step prompts are even more annoying because they are displayed every time you visit the website, while the browser prompt can be displayed only once and then is blocked forever
• websites will start including floating widgets (e.g. a notification icon on the bottom of the page) which are really annoying because they partially cover the content

I think that it is up to the developer to create the right UX, you cannot force them, because you won't achieve anything... The UX may become even worse. I think that blocking the notifications permanently if the user deny permission is already enough.

Are there any alternatives?

I agree that displaying the prompt on page load might not be the best solution. However, instead of blocking this behavior, I would prefer if browsers could implement a really valuable alternative...

Example (it's only for brainstorming): browsers could display a small notification icon in the address bar for websites that ask permission for push notifications on page load, instead of displaying the prompt.

Safari behavior

It seems that Safari (desktop) 12.1 started blocking the prompts on page load.

I think that Apple should take part in this conversation instead of breaking things without notice.

If this behavior persists, probably we will start offering 2 step prompts to our customers, as many other providers already do... The problem is that customers will start asking us to offer that feature. It would be sad, because this is even worse in my opinion.

On the other hand, if someone could suggest the right approach for a general widget, I would appreciate that.

[collimarco]

Related:

• WICG forum: https://discourse.wicg.io/t/require-user-gesture-for-notification-permission-request
• Safari bug report: https://bugs.webkit.org/show_bug.cgi?id=196294

[johannhof]

(As noted in #72, we intend to archive this repository and are thus triaging and resolving all open issues)

This is being tracked in whatwg/notifications#108 and both Firefox and Safari have implemented this, IIUC.