Open Bug 1375683 Opened 4 years ago Updated 7 months ago
[meta] Consider mitigations for push notification abuse by websites
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...
Panos, who can help with the UX here? Why did we make it impossible to dismiss the prompt without choosing?
Bryan has thought about plans here and I think Kit has, too.
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: → 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.
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.
(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?
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.
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.
I think that in order to provide a good user experience, we should really take a step back and consider whether incremental fixes are the right way to go, or whether we need to rethink the whole approach of showing notifications from the ground up and build it around the idea of not requiring permission prompts in the first place. I would like to argue that any of the solutions of the first category will fall short of the ideal user experience (which is, to allow sites to send notifications for useful things in a way that doesn't annoy users), and we should take the second path. First, here are some of the problems with ideas along the first approach. What I would like to emphasize here is that what matters above all else is the *default experience* that users get out of the box. We know from a variety of research that users are averse to changing settings in their software. So approaches like bug 1379560 aren't a sufficient fix here because they only address the problem for the tiny minority of users who go out of their way to discover that setting and turn it on, and even worse that precludes all sites from that point on to send notifications unless if the user configures their browser even further. Also, ideas such as bug 1345424 and https://github.com/WICG/interventions/issues/49#issuecomment-310445655 only improve things a tiny bit, since there is really not much reason to believe that sites that the user interacts with (a bit, or to some extent) are exactly the sites that the user is OK to receive notifications from. Using interaction/engagement as a proxy here seems quite weird. But if we were to design things differently from scratch, here is one possible approach that wouldn't require permission prompts at all. Let's imagine that the browser had a Notifications Sidebar. By default, all sites would have a free pass to send you notifications but instead of the notification going to the desktop (or to the phone notification UI) it would go to the browser's Notifications Sidebar. In terms of the visible UI changes when that happens, we'd need something really subtle, like an animated icon that would tell the user something happened, but not more than that. Once the user clicked on that, they could see the recent notification plus all of the ones sent in the past. There, we would also show a button to the user like "Send This Site's Notifications To Desktop", which would have the same impact as saying Allow to our current Notification Permission Prompts. The effect of changing our UI this way would be that we would remove the step where we have to ask the user a question, by redoing things in a way that doesn't require asking a question in the first place (since once you have a place to put notifications in all the time that isn't in the user's face, then you don't need to ask them permission to display those notifications...) The details of the idea I'm proposing could be adjusted of course but the crux of the idea is to remove the question we're asking this permission around.
Push notifications imply the ability to wake up a ServiceWorker when the user isn't browsing the site. So the permission grant is doing (secret) double-duty, hopefully setting the expectation that the website will be able to do things in the background. This, of course, is not necessarily entirely obvious, so some browsers (like Chrome) will display a notification if a SW that received a "push" event fails to display its own notification (and in a timely fashion). Based on brief research, I think the notification will say "This site has been updated in the background." with the origin labeled. Which is to say, I don't think granting the ability to dispatch "push" notifications but hiding the notifications is a workable strategy based on the current execution model. (One could of course create an exciting new sub-genre of anti-virus software to rein in the worst excesses...) Looking into the abandonment of the Budget API, :mt's post at https://discourse.wicg.io/t/proposal-budget-api/1717/7 suggests he might be an excellent person to consult with in this space. 1: I'm going off of the screenshot at https://developers.google.com/web/fundamentals/push-notifications/handling-messages 2: https://github.com/WICG/budget-api/issues/23
I like the way that Ehsan is thinking here. One thing that came up in discussions is the removal of the ability to summon the doorhanger unless the request was a direct result of an engagement gesture. Sites that call the geolocation API at page load time would then cause an icon to appear in the control centre only. Activating the control centre would either cause the doorhanger to display or maybe just highlight the permissions that have been requested. The key here is that this requires explicit action to be elevated into an annoyance. We would treat display of the doorhanger as morally equivalent to a popup, which I think is fair, based on how badly they are being abused. Changes like this will guarantee complaints from some sites. I don't think that it's a big deal, but we should be prepared to answer those complaints.
You need to log in before you can comment on or make changes to this bug.