tpac-breakout-bot
commented
4 days ago Thank you for proposing a session!
You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.
Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.
Session 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:
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.
Session goal
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.
Additional session chairs (Optional)
@engedy
Who can attend
Anyone may attend (Default)
IRC channel (Optional)
fix-notifications
Other sessions where we should avoid scheduling conflicts (Optional)
18, #8
Instructions for meeting planners (Optional)
A screen to display UX mock ups would be nice :)
Agenda for the meeting.
Links to calendar