API changes to prevent site abuse / annoyances

[pes10k]

Many sites spam users with faux-permission "please turn on your notifications" requests before actually asking for permission, b/c the sites know they'll only get one bite-at-the-apple if they do it the proper way and actually ask for permission.

The API enables this by having one API for asking for permission, and another API for querying the current permission state.

The API should be changed to address this by collapsing both activities into a single decision point, so that querying the state of the permission, and the permission itself, both trigger browser-chrome requests, and so websites can only ask once.

[annevk]

That's a very interesting idea, but executing this in a backwards-compatible fashion might be tricky.

I suppose we could make https://notifications.spec.whatwg.org/#dom-notification-permission always return "default" easily enough and also mark it as deprecated. That would also rid us of requiring synchronous cross-process communication (or caching upon process creation).

cc @johannhof @beverloo

[johannhof]

Hmm, I'm trying to fully understand the implications of this, so below are genuine questions/confusion, not trying to shut down the idea :)

How exactly would this help with fake notifications? Why would a fake notification spammer need to check permission access? I would think there are two common patterns:

• Spam the user until they click "Yes" in the DOM element then show the real prompt.
• "The switcheroo": Spam the user, but "No" is on the wrong side, then show a real prompt after a few times.

Both of which don't really require access to permission state.

On the other hand, I can see a bunch of legitimate uses for permission state checking, especially for notifications. i.e. if Slack wants to show a small pre-prompt UI item to highlight that the user can optionally turn on notifications, how would they know when to show or not to show?

Or, consider web applications that have optional notification settings in their menus. They do that to avoid spamming users with permission prompts, but with this intervention they couldn't render their menu or send notifications without setting off a new prompt right away.

[pes10k]

On the other hand, I can see a bunch of legitimate uses for permission state checking, especially for notifications. i.e. if Slack wants to show a small pre-prompt UI item to highlight that the user can optionally turn on notifications, how would they know when to show or not to show?

If the user has enabled and logged in, this information can easily be stored in localStorage or similar. The browser doesn't need to carry and expose that state to the page directly.

@johannhof Those are not the patterns I see in the wild, and have to try and engineer against. The predominant anti-patern here (and reported to us often) is some 3p script does:

1. whats the notification access state?
2. If "default", then show fake notification, so that the user can be re-asked
3. If allowed, use the API
4. If not allowed, stop

The fake notification system checks permission access so that, if the user hasn't made a decision yet, they can repeatedly fake ask over and over (while if the page was actually asking for the permission, they'd only get once chance), without the user making the semi-difficult-to-reverse "deny" decision. So, by removing the opportunity for the site to repeatedly "fake ask" it becomes harder to cheese the system, and users can shut things down easier

[johannhof]

On the other hand, I can see a bunch of legitimate uses for permission state checking, especially for notifications. i.e. if Slack wants to show a small pre-prompt UI item to highlight that the user can optionally turn on notifications, how would they know when to show or not to show?

If the user has enabled and logged in, this information can easily be stored in localStorage or similar. The browser doesn't need to carry and expose that state to the page directly.

What is to prevent bad actors from doing the same?

And to give a concrete example on how this would create more annoyance on a legitimate site, Slack uses a cookie to store the user choice to never ask for notifications, but this cookie is occasionally purged on Firefox for privacy reasons, leading to Firefox users being asked to enable notifications again and again.

The assumption that web storage is persistent enough to reliable mirror notification settings doesn't hold. But I doubt bad actors care, because they're not in it for the user experience. This mostly affects legitimate sites.

@johannhof Those are not the patterns I see in the wild, and have to try and engineer against. The predominant anti-patern here (and reported to us often) is some 3p script does:

1. whats the notification access state?

2. If "default", then show fake notification, so that the user can be re-asked

3. If allowed, use the API

4. If not allowed, stop

The fake notification system checks permission access so that, if the user hasn't made a decision yet, they can repeatedly fake ask over and over (while if the page was actually asking for the permission, they'd only get once chance), without the user making the semi-difficult-to-reverse "deny" decision. So, by removing the opportunity for the site to repeatedly "fake ask" it becomes harder to cheese the system, and users can shut things down easier

I don't understand the importance of checking for permission access in this scheme. Those sites can make the pretty safe assumption that the vast majority of users would return "default" anyway, so they can just show the fake prompt until they have a good feeling that a user would allow and then register to the push service and thereby trigger the real dialog. What's their risk in showing the fake prompt to someone who had already seen it before?

[pes10k]

The difference in both cases is that, as the API is currently designed, sites can nag users and be truthful / not have an inconsistency. The proposed change (i believe, my goal is) to force annoying / user-harming scripts to either perform better (by asking once, directly for the permission) or to lie to the user, and so 1ps wouldn't include them.

Put differently:

What's their risk in showing the fake prompt to someone who had already seen it before

Its that doing so would result in a situation thats much more likely to be intolerable to the site owner, since the script is lying to the user (because the "enable notifications" prompt is no longer available, b/c it was previously rejected)

Any script, at any given time, can lie about anything at all; I don't think that should be how marginal improvements are measured. The goal of this change is to move "attackers" from being "annoying-and-honest" to being "annoying-and-dishonest".

[markcellus]

I've always found it strange that sites can just spam users with notification perm requests randomly. Is it a possibility to just not allow a site to request notifications permissions unless it's "installed" as a web app? This would bring it in line with how native mobile apps work.