Consider mitigations for push notification abuse by websites

NEW
Unassigned
(Needinfo from 2 people)

Status

()

P2
normal
a year ago
9 months ago

People

(Reporter: bzbarsky, Unassigned, NeedInfo)

Tracking

53 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

We implemented push notifications permissions with a popup that requires the user to make a choice; you can't just click somewhere random to make the whole thing go away.

Unfortunately, various sites are abusing push notifications and prompting as soon as you load the page.  Since the user _has_ to respond to the prompt, this is a pretty terrible user experience.

See https://github.com/WICG/interventions/issues/49 for some discussion about the problem and some data on what Chrome is considering doing.

For our part, we should at the very least make it possible to dismiss without choosing, and probably implement other mitigations too.

Not sure whom to cc about the UX impact here...
Flags: needinfo?(overholt)

Comment 1

a year ago
Panos, who can help with the UX here? Why did we make it impossible to dismiss the prompt without choosing?
Flags: needinfo?(past)
Bryan has thought about plans here and I think Kit has, too.
Flags: needinfo?(overholt)
Flags: needinfo?(kit)
Flags: needinfo?(clarkbw)
Priority: -- → P2
I believe Bryan has all the context, but adding Peter for the privacy and security angle.

I have experienced this behavior, but I wouldn't characterize it as terrible. The Don't Allow button is a huge click target. What I find depressing however is that some of the partners that helped us design this interaction haven't followed through with implementing it and serving as a positive example. The privacy team has been evangelizing the right way to implement push notifications (my talk was a few weeks ago), but I absolutely agree that we should experiment with other proposed countermeasures like requiring a user gesture.
Flags: needinfo?(past) → needinfo?(pdolanjski)
FWIW I've seen a number of users request the ability to disable notifications globally.  See bug 1313939.  Unfortunately I have not had any luck in getting UX to take action on this user feedback.
See Also: → bug 1313939
Pre-53, you could dismiss the doorhanger without making a decision by clicking outside it. For other permissions, we minimized the doorhanger into the identity block, so that you could restore and grant permission later; for notifications, we returned `"default"` to the site. As Panos says, the new modal doorhanger was repeatedly requested by partners; it is a bit unfortunate that they haven't followed through with adopting best practices.

I agree with Ben that disabling notifications globally would help (more discussion in bug 1275599, bug 1363856, bug 1364942). Thanks for linking to https://github.com/WICG/interventions/issues/49, too.
Flags: needinfo?(kit)
See Also: → bug 1368744
We should get some UX in here to figure this out.  I can see how a global option would be nice but it also breaks the experience in ways people might not notice. 

Perhaps we can focus on ways to prevent the permissions from being annoying in certain scenarios instead of trying to block requests.
Flags: needinfo?(clarkbw)
(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #6)
> We should get some UX in here to figure this out.

Do you know if this is underway?
Flags: needinfo?(clarkbw)
So, two things that _are_ underway that offer some possibilities to tackle the notification spam problem:

- I've started adding a user gesture flag to nsIPermissionPrompt in bug 1345424. We could use that to enforce a user gesture before prompting (although that's of course a big web compat issue). I didn't really finish it because I was resourced to Photon but I might pick it up again, since this issue is becoming more and more pressing. I don't think there's a large amount of work left.

- I'm implementing a way to have a clean global disable of permissions in bug 1379560. The big advantage is that that's not a DOM pref, it's just a default state for the respective permission, so users can globally hide permission prompts but whitelist specific sites they like (e.g. WhatsApp, Facebook).

These are both platform fixes, we'd indeed need some Product/UX help to properly integrate them without breaking the web for everyone. One thing that has at least UX commitment (but no spec yet) is adding a global disable toggle (presumably with the ability to whitelist) in bug 1368744.

I'm marking those bugs as blocking, to be able to track the work we're doing and not duplicate efforts.
Depends on: 1379560, 1345424, 1368744
See Also: bug 1368744
I think @phlsa is our UX person here or can direct us to the right person.

Question is: What do we do about sites that annoy people with their immediate request for push permission?

Tom's is a good example of this: http://www.tomshardware.com/

There are suggestions to be able to block all requests for all sites.  I'd push against this because I see it as the "Turn off JavaScript" type of option that avoids issues but also breaks other sites in unforeseen ways.

Here's a couple user stories I think we want to consider:

As a user who navigates to a site for the 1st time I don't want to be bombarded with permission requests such that I have to say no when I'm just investigating this site.

As the developer of a game site I want to be able to ask for user permissions quickly such that I can immerse people into the experience immediately.

It might also be worth considering that, at least for now, I don't believe we've seen sites where the Push permission is required immediately.  So on first visit or in the first several seconds game sites might want other permissions but Push is more about re-acquisition of users and not keeping them on the site.
Flags: needinfo?(clarkbw) → needinfo?(philipp)
One use case I have to add to comment 9:

When setting up a new profile I add the telegram messaging site as a pinned tab.  I would like it to be able to ask for notification permissions immediately.

Updated

a year ago
Duplicate of this bug: 1394407
Depends on: 1345077
You need to log in before you can comment on or make changes to this bug.