Clarify when a site is allowed to display the permission prompt

[collimarco]

In the last years different browsers have introduced arbitrary limitations on when the permission prompt can be triggered. Some browsers like Chrome are also introducing penalties for websites that don't follow the rules.

However the rules are not always clear and I think that the standard should clarify when a website is allowed to display the permission prompt for notifications. Indeed, whenever we want to try a new way to present the prompt, we always fear the a browser may block that or you can even get penalizations.

For example, I see that there is a trend of displaying the browser permission prompt directly (not a double opt-in) after some page scrolling. Is that an allowed use case or should be avoided?

This is just one of the doubts that all these limitations and penalties introduce... In order to get peace of mind and compatibility between browsers, I think that the standard should clarify when you can display the prompt.

[marcoscaceres]

these issues apply generally to permissions, so I'm going to transfer this to the Permissions API.

[collimarco]

@marcoscaceres These limitations introduced by browsers are usually specific for the notification permission prompt, so maybe it's better to keep this issue in https://github.com/w3c/push-api/

[marcoscaceres]

Appreciate that, but I'm going to move the push permission prompting to use the Permission API, so they will be one and the same.

[jyasskin]

It would be nice to write down some assurances for developers about what coding patterns are "allowed" for showing permissions, but I don't know what we could actually write on the topic. We want to allow browsers to keep acting against patterns that abuse user attention, so any agreement about when we'll allow prompts needs to be resilient against novel forms of abuse.

Even the double-opt-in that's used on https://blog.pushpad.xyz/2020/04/the-double-opt-in-for-web-push-notifications/ is abusive, since it asks the user about notifications (within page UI) without any indication the user actually wants to pay attention to the site in the long run. It's not a form of abuse we know how to block yet, but this spec shouldn't prevent us from trying to do so.

[collimarco]

@jyasskin Now also the double opt-in is abusive!? That is what Google has always recommended: use an HTML/CSS prompt to explain to the user what kind of content will receive by subscribing to the notifications. And that is exactly what we do on that page (and the exact same strategy - i.e. custom prompt - is adopted by all major push services).

In any case I am always open to hear about new solutions that can improve the UX... (e.g. having a standard bell button in the browser UI would be great), but also consider that websites use notifications to re-engage the visitors, so the permission process should also produce good results (i.e. subscribers).

[collimarco]

@jyasskin I also underly, that, despite all the theory, Google itself display the native permission prompt directly when you visit Youtube...

Probably this discussion group should focus on giving practical advice, rather than demonizing the existing solutions.

[jyasskin]

Respectful patterns for push notifications on blogs tend to involve a [subscribe] button that the user clicks before being asked to allow push notifications. A respectful pattern for geolocation tends to be a 'use my current location' button whose click causes the prompt. Disrespectful flows start from a site author realizing that they make more money when users grant permissions, so they ask before the user has expressed interest. Drawing a prompt like the browser's inside page UI doesn't make that prompt respectful, even if it makes it harder for browsers to block.

The practical advice is to build flows that make users happy and avoid manipulating or annoying them into granting permission. I don't know how to write that into a specification in any sort of normative way. We could think about something analogous to https://webkit.org/tracking-prevention-policy/, where we describe some non-normative principles for thinking about what kinds of flows are respectful, but even that doesn't guarantee we'll never wind up accidentally blocking a prompt that a human would consider respectful.

[collimarco]

Drawing a prompt like the browser's inside page UI doesn't make that prompt respectful

@jyasskin There's a difference between the two prompts: the custom prompt explains to the user what kind of content will receive and why he is being prompted to receive the notifications. It's not the same as the browser permission prompt. That was explained in some Google UX guides.

Respectful patterns for push notifications on blogs tend to involve a [subscribe] button

Our SDK already offers that option too (you can see a button in the sidebar for example) - websites are free to use one or the other option (or both).