Let’s actually fix web notifications

• Past
• Confirmed
• Breakout Sessions

Web Notifications are often used as a channel for unwanted spam. Even when the notifications are initially wanted, it can be difficult for people to work out how to unsubscribe to their notification subscriptions. The notifications permission grants never expire. It is also a common observed pattern from some websites that they socially engineer people into accepting the notification permission, for example by withholding site content or functionality until the permission is granted.
In this session we would like to propose and discuss potential alternatives for structurally solving the aforementioned issues. These include:

1: Make notifications not-promptable

Instead of showing an interruptive pop-up when websites request notification permission, browsers could silently add a settings row available to the user in secondary browser UI, like so:

<img width="1303" alt="Group 2" src="https://github.com/user-attachments/assets/4320aafa-5fa5-4eda-ada2-65d80c967ed8">

Then, if the user wishes to subscribe to notifications from a website, they can proactively navigate to the browser UI to turn this toggle on. The benefit of this solution is (even if websites socially engineer users to grant them notifications permission), through the act of navigating to browser UI to turn on notifications, people inherently learn where to go to turn it off.

The drawbacks here are centered on discoverability, i.e., whether users will be able to find how to grant notifications when they actually want them. However, given the current prevalence of unwanted notification prompts, this might be a tradeoff worth making.

2: Make default notifications behaviour require an open and active tab

Most other permission types existing today require the website to be in an open and active browser tab for the capability to work. Notifications notably differs: it allows websites to message people even if they close all tabs from that website. In some ways, this is the point of the Web Push API.

Making the default notification behaviour tied to whether tabs from that origin are open gives people an intuitive way to sample notifications from a site while it’s still open, and to silence these notifications if they are unwanted. For sites that the user trusts highly, they can “upgrade” the permission to include the ability to notify them even when tabs from that site are closed. For installed web-apps, the "upgraded" behaviour could be the default.

3: Expire stale notification permissions

Current decisions on notification permission prompts are permanent. The browser does not do any automatic clean-up of stale notification subscriptions, even if they are from a site that the user has not interacted with for many years.

Clarifying the purpose of the Web Push and Web Notification APIs on a philosophical level – amongst browser vendors as well as web developers – would allow user agents to enable helpful notifications while curbing unwanted notifications. For example, if we can agree that the purpose of notifications is to inform users about content being changed on a site, and in response, users are expected to actually visit the sender origin within a reasonable time window (such as within a few months), user agents could expire permission grants outside that reasonable time window. It is an open question if there are legitimate in-the-wild use cases for notifications that users only read, never interact with, nor do they ever visit the sending website again.

Agenda

Chairs:
Serena Chen, Balazs Engedy

Description:
Web Notifications are often used as a channel for unwanted spam. Even when the notifications are initially wanted, it can be difficult for people to work out how to unsubscribe to their notification subscriptions. The notifications permission grants never expire. It is also a common observed pattern from some websites that they socially engineer people into accepting the notification permission, for example by withholding site content or functionality until the permission is granted.
In this session we would like to propose and discuss potential alternatives for structurally solving the aforementioned issues. These include:

1: Make notifications not-promptable

Instead of showing an interruptive pop-up when websites request notification permission, browsers could silently add a settings row available to the user in secondary browser UI, like so:

<img width="1303" alt="Group 2" src="https://github.com/user-attachments/assets/4320aafa-5fa5-4eda-ada2-65d80c967ed8">

Then, if the user wishes to subscribe to notifications from a website, they can proactively navigate to the browser UI to turn this toggle on. The benefit of this solution is (even if websites socially engineer users to grant them notifications permission), through the act of navigating to browser UI to turn on notifications, people inherently learn where to go to turn it off.

The drawbacks here are centered on discoverability, i.e., whether users will be able to find how to grant notifications when they actually want them. However, given the current prevalence of unwanted notification prompts, this might be a tradeoff worth making.

2: Make default notifications behaviour require an open and active tab

Most other permission types existing today require the website to be in an open and active browser tab for the capability to work. Notifications notably differs: it allows websites to message people even if they close all tabs from that website. In some ways, this is the point of the Web Push API.

Making the default notification behaviour tied to whether tabs from that origin are open gives people an intuitive way to sample notifications from a site while it’s still open, and to silence these notifications if they are unwanted. For sites that the user trusts highly, they can “upgrade” the permission to include the ability to notify them even when tabs from that site are closed. For installed web-apps, the "upgraded" behaviour could be the default.

3: Expire stale notification permissions

Current decisions on notification permission prompts are permanent. The browser does not do any automatic clean-up of stale notification subscriptions, even if they are from a site that the user has not interacted with for many years.

Clarifying the purpose of the Web Push and Web Notification APIs on a philosophical level – amongst browser vendors as well as web developers – would allow user agents to enable helpful notifications while curbing unwanted notifications. For example, if we can agree that the purpose of notifications is to inform users about content being changed on a site, and in response, users are expected to actually visit the sender origin within a reasonable time window (such as within a few months), user agents could expire permission grants outside that reasonable time window. It is an open question if there are legitimate in-the-wild use cases for notifications that users only read, never interact with, nor do they ever visit the sending website again.

Goal(s):
Share and discuss solutions to curb spammy and abusive notifications on the web, and to help users exert better control over their notifications. Identify points of consensus and points of contention. Identify open questions to be answered to sort out points of contention. Identify practical next steps to improve Web Notifications.

Agenda:

1. Intro: Web Push Notifications problem space
2. Potential solutions + discussion
   i. Make notifications not-promptable
   ii. Notifications to require open tab
   iii. Expiry for notification grants
   iv. Any other potential solutions from the group
3. Identify points of consensus and points of contention
   i. What are the open questions to answer to sort out the points of contention?
4. Next steps

Materials:

• minutes
• Session proposal on GitHub

Track(s):

• Permissions

Minutes

 Read minutes

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

• Download as ics