BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 4.5.8//EN CALSCALE:GREGORIAN LAST-MODIFIED:20241002T120833Z BEGIN:VTIMEZONE TZID:America/Los_Angeles X-MICROSOFT-CDO-TZID:13 BEGIN:STANDARD DTSTART:20231105T090000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:STANDARD DTSTART:20241103T090000 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:20240310T100000 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:0b16a479-7aa3-48ec-a556-ec8b9aaac8c0 DTSTAMP:20241002T120833Z SUMMARY:Let’s actually fix web notifications DTSTART;TZID=America/Los_Angeles:20240925T144500 DTEND;TZID=America/Los_Angeles:20240925T154500 DESCRIPTION:https://www.w3.org/events/meetings/0b16a479-7aa3-48ec-a556-ec8b 9aaac8c0/\n\nWeb Notifications are often used as a channel for unwanted sp am. Even when the notifications are initially wanted\, it can be difficult for people to work out how to unsubscribe to their notification subscript ions. The notifications permission grants never expire. It is also a commo n observed pattern from some websites that they socially engineer people i nto accepting the notification permission\, for example by withholding sit e content or functionality until the permission is granted.\nIn this sessi on we would like to propose and discuss potential alternatives for structu rally solving the aforementioned issues. These include:\n\n#### 1: Make no tifications not-promptable\nInstead 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:\n\n< img width="1303" alt="Group 2" src="https://github.com/user-attachments/as sets/4320aafa-5fa5-4eda-ada2-65d80c967ed8">\n\nThen\, if the user wishes t o subscribe to notifications from a website\, they can proactively navigat e to the browser UI to turn this toggle on. The benefit of this solution i s (even if websites socially engineer users to grant them notifications pe rmission)\, through the act of navigating to browser UI to turn on notific ations\, people inherently learn where to go to turn it off.\n\nThe drawba cks here are centered on discoverability\, i.e.\, whether users will be ab le to find how to grant notifications when they actually want them. Howeve r\, given the current prevalence of unwanted notification prompts\, this m ight be a tradeoff worth making.\n\n#### 2: Make default notifications beh aviour require an open and active tab\n\nMost other permission types exist ing 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 w ays\, this is the point of the Web Push API.\n\nMaking the default notific ation behaviour tied to whether tabs from that origin are open gives peopl e 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 inc lude the ability to notify them even when tabs from that site are closed. For installed web-apps\, the "upgraded" behaviour could be the default.\n\ n#### 3: Expire stale notification permissions\n\nCurrent decisions on not ification permission prompts are permanent. The browser does not do any au tomatic clean-up of stale notification subscriptions\, even if they are fr om a site that the user has not interacted with for many years. \n\nClarif ying the purpose of the Web Push and Web Notification APIs on a philosophi cal level – amongst browser vendors as well as web developers – would allow user agents to enable helpful notifications while curbing unwanted n otifications. For example\, if we can agree that the purpose of notificati ons is to inform users about content being changed on a site\, and in resp onse\, users are expected to actually visit the sender origin within a rea sonable time window (such as within a few months)\, user agents could expi re permission grants outside that reasonable time window. It is an open qu estion if there are legitimate in-the-wild use cases for notifications tha t users only read\, never interact with\, nor do they ever visit the sendi ng website again.\n\nAgenda\n\n**Chairs:**\nSerena Chen\, Balazs Engedy\n\ n**Description:**\nWeb Notifications are often used as a channel for unwan ted spam. Even when the notifications are initially wanted\, it can be dif ficult for people to work out how to unsubscribe to their notification sub scriptions. The notifications permission grants never expire. It is also a common observed pattern from some websites that they socially engineer pe ople into accepting the notification permission\, for example by withholdi ng site content or functionality until the permission is granted.\nIn this session we would like to propose and discuss potential alternatives for s tructurally solving the aforementioned issues. These include:\n\n#### 1: M ake notifications not-promptable\nInstead of showing an interruptive pop-u p when websites request notification permission\, browsers could silently add a settings row available to the user in secondary browser UI\, like so :\n\nGroup 2\n\nThen\, if the user wi shes to subscribe to notifications from a website\, they can proactively n avigate to the browser UI to turn this toggle on. The benefit of this solu tion is (even if websites socially engineer users to grant them notificati ons permission)\, through the act of navigating to browser UI to turn on n otifications\, people inherently learn where to go to turn it off.\n\nThe 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.\n\n#### 2: Make default notificatio ns behaviour require an open and active tab\n\nMost other permission types existing today require the website to be in an open and active browser ta b for the capability to work. Notifications notably differs: it allows web sites to message people even if they close all tabs from that website. In some ways\, this is the point of the Web Push API.\n\nMaking the default n otification 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 cl osed. For installed web-apps\, the "upgraded" behaviour could be the defau lt.\n\n#### 3: Expire stale notification permissions\n\nCurrent 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. \n\n Clarifying the purpose of the Web Push and Web Notification APIs on a phil osophical level – amongst browser vendors as well as web developers – would allow user agents to enable helpful notifications while curbing unwa nted notifications. For example\, if we can agree that the purpose of noti fications is to inform users about content being changed on a site\, and i n response\, users are expected to actually visit the sender origin within a reasonable time window (such as within a few months)\, user agents coul d expire permission grants outside that reasonable time window. It is an o pen question if there are legitimate in-the-wild use cases for notificatio ns that users only read\, never interact with\, nor do they ever visit the sending website again.\n\n**Goal(s):**\nShare and discuss solutions to cu rb spammy and abusive notifications on the web\, and to help users exert b etter control over their notifications. Identify points of consensus and p oints of contention. Identify open questions to be answered to sort out po ints of contention. Identify practical next steps to improve Web Notificat ions.\n\n\n**Agenda:**\n1. Intro: Web Push Notifications problem space\n2. Potential solutions + discussion\n i. Make notifications not-promptable\ n ii. Notifications to require open tab\n iii. Expiry for notification g rants\n iv. Any other potential solutions from the group\n3. Identify poi nts of consensus and points of contention\n i. What are the open question s to answer to sort out the points of contention?\n4. Next steps\n\n**Mate rials:**\n- [minutes](https://pad.w3.org/p/Notifications)\n- [Session prop osal on GitHub](https://github.com/w3c/tpac2024-breakouts/issues/81)\n\n** Track(s):**\n- Permissions STATUS:CONFIRMED CREATED:20240916T220103Z LAST-MODIFIED:20241002T120833Z SEQUENCE:3 ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor eply@w3.org LOCATION:4 Concourse Level - Oceanside CATEGORIES:TPAC 2024,Breakout Sessions END:VEVENT END:VCALENDAR