BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Sabre//Sabre VObject 4.5.8//EN CALSCALE:GREGORIAN LAST-MODIFIED:20231012T082320Z BEGIN:VTIMEZONE TZID:Europe/Madrid BEGIN:STANDARD DTSTART:20221030T010000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET END:STANDARD BEGIN:STANDARD DTSTART:20231029T010000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:20230326T010000 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:762bb84d-ef4a-42db-8c0c-4563e1b2ff37 DTSTAMP:20231012T082320Z SUMMARY:Notifications - Sharing current problems & issues DTSTART;TZID=Europe/Madrid:20230913T093000 DTEND;TZID=Europe/Madrid:20230913T103000 DESCRIPTION:https://www.w3.org/events/meetings/762bb84d-ef4a-42db-8c0c-4563 e1b2ff37/\n\nWe have a number of rough areas\, and while we might not be r eady to figure out a solution yet\, we would love to chat about the curren t issues we are seeting. @b1tr0t and @beverloo have most of the context he re (although @beverloo won't be at TPAC this year)\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n* Abuse / spam / requiring install for notifications \n\n * Chrom ium is seeing a large quantity of abuse across the ecosystem. We don’t b elieve gating notifications to installed use is the answer for reasons. \n \n * We are considering rate limiting and other countermeasures \n\n * A re there opportunities for standards revisions that might help? \n\n\n\n\n \n\n\n* "important" notifications (VOIP). @beverloo notes:\n\n * MSFT alr eady working on this:\n\n * [Intent to Prototype on blink-dev](https://gr oups.google.com/a/chromium.org/g/blink-dev/c/PtHemJah2Qc/m/EkXmztgzCgAJ?ut m_medium=email&utm_source=footer)\, [explainer](https://github.com/Microso ftEdge/MSEdgeExplainers/blob/main/Notifications/notifications_actions_cust omization.md)\, [initial implementation](https://chromium-review.googlesou rce.com/c/chromium/src/+/4088048)\n\n * Example hero use-case - empower S kype on the Web.\n\n * On Android this would require a permission (FOREGR OUND_SERVICE_PHONE_CALL) that we probably don’t want to issue to Chrome itself. Limiting this functionality to installed experiences seems good in either case\, as otherwise there would be complicated incentives.\n\n\n\n * Notification sounds (ringing?)\n\n * Related to important notifications \, some apps might want a ringing sound\n\n * Somewhat limited by OS supp ort of custom notification sounds\, however\, may be possible to create a “Safe” set of standard notification sounds for developer to choose fro m e.g. “Chime” “Ringing” “Alarm”\, and perhaps others\n\n * @ beverloo notes: This was part of a Microsoft proposal that we provided fee dback on\n\n * [Explainer](https://github.com/MicrosoftEdge/MSEdgeExpla iners/blob/main/Notifications/notifications_actions_customization.md#play- ringtone-from-inside-the-tab)\n\n * Long story short\, a (admittedly br ief) joint investigation showed that very few sounds would actually be con sistent across operating systems\, which is hard to explain to developers. It’s important that these are OS-consistent: ideally an e-mail in Apple Mail and one in Gmail alert Apple users in exactly the same way.\n\n * For Chromium to support arbitrary sounds\, the media team advised that th e best way to achieve that would be to load a (background) tab with a element in which we play the developer-provided URL. That’s a signif icant system health cost.\n\n * On Android such sounds are tied to the notification channel as opposed to individual notifications\, and actually cannot be set for individual notifications anymore.\n\n\n\n\n\n\n\n* Noti fication channels.\n\n * Allow sites to register and send to specific cha nnels\, similar to capabilities offered on Android and iOS platforms\n\n * Can be a useful way for users to reduce unwanted notification volume\, for example on a messaging app like IG the user could choose to allow DMs but not receive notifications about new posts in the feed\n\n * beverloo @ note:\n\n * ChromeOS is also very interested in this\, would like to see something like this supported. We might be able to mimic support in Wi ndows through grouping.\n\n * Nuances to consider on Android: channel s are declared once and are then permanent\, i.e. updating the importance\ , sound\, vibration etc. of a channel **should not happen** after it’s b een created\, even when the channel’s name changes.\n\n\n\n* Reducing no tification energy use (currently need to spin up JS)\n\n * The current we b notifications spec was designed with maximum flexibility as the objectiv e. With the current spec\, notifications require a Service Worker and when a notification is received\, the ServiceWorker wakes and can then take so me action. \n\n * The solution is an amendment to the notification specif ication that optimizes for the most common notification usage pattern of s imply displaying a notification on the user’s device. This change will i mprove performance and energy usage of notification delivery.\n\n * @beve rloo note: We’ve always been supportive of receiving push messages and s howing notifications w/o involving the service worker\, this would bring m ajor system health benefits.\n\n * There has been some resistance from partners to support this as they need the SW / analytics logic to run for monetization.\n\n * Android would be able to support high priority noti fications in a declarative path. This is important because the framework d eprioritises notifications for an entire app (i.e. the browser) based on s how and interaction rates\, which means that currently a single misbehavin g site can negatively impact the holistic browser notification experience. \n\n * Big +1 to doing this if we can get broader ecosystem adoption.\n \nAgenda\n\n**Chairs:**\nDaniel Murphy\n\n**Description:**\nWe have a numb er of rough areas\, and while we might not be ready to figure out a soluti on yet\, we would love to chat about the current issues we are seeting. @b 1tr0t and @beverloo have most of the context here (although @beverloo won' t be at TPAC this year)\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n* Abuse / spam / re quiring install for notifications \n\n * Chromium is seeing a large quant ity of abuse across the ecosystem. We don’t believe gating notifications to installed use is the answer for reasons. \n\n * We are considering ra te limiting and other countermeasures \n\n * Are there opportunities for standards revisions that might help? \n\n\n\n\n\n\n\n* "important" notific ations (VOIP). @beverloo notes:\n\n * MSFT already working on this:\n\n * [Intent to Prototype on blink-dev](https://groups.google.com/a/chromium. org/g/blink-dev/c/PtHemJah2Qc/m/EkXmztgzCgAJ?utm_medium=email&utm_source=f ooter)\, [explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blo b/main/Notifications/notifications_actions_customization.md)\, [initial im plementation](https://chromium-review.googlesource.com/c/chromium/src/+/40 88048)\n\n * Example hero use-case - empower Skype on the Web.\n\n * On Android this would require a permission (FOREGROUND_SERVICE_PHONE_CALL) th at we probably don’t want to issue to Chrome itself. Limiting this funct ionality to installed experiences seems good in either case\, as otherwise there would be complicated incentives.\n\n\n\n* Notification sounds (ring ing?)\n\n * Related to important notifications\, some apps might want a r inging sound\n\n * Somewhat limited by OS support of custom notification sounds\, however\, may be possible to create a “Safe” set of standard notification sounds for developer to choose from e.g. “Chime” “Ringi ng” “Alarm”\, and perhaps others\n\n * @beverloo notes: This was pa rt of a Microsoft proposal that we provided feedback on\n\n * [Explaine r](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Notificatio ns/notifications_actions_customization.md#play-ringtone-from-inside-the-ta b)\n\n * Long story short\, a (admittedly brief) joint investigation sh owed that very few sounds would actually be consistent across operating sy stems\, which is hard to explain to developers. It’s important that thes e are OS-consistent: ideally an e-mail in Apple Mail and one in Gmail aler t Apple users in exactly the same way.\n\n * For Chromium to support ar bitrary sounds\, the media team advised that the best way to achieve that would be to load a (background) tab with a element in which we pla y the developer-provided URL. That’s a significant system health cost.\n \n * On Android such sounds are tied to the notification channel as opp osed to individual notifications\, and actually cannot be set for individu al notifications anymore.\n\n\n\n\n\n\n\n* Notification channels.\n\n * A llow sites to register and send to specific channels\, similar to capabili ties offered on Android and iOS platforms\n\n * Can be a useful way for users to reduce unwanted notification volume\, for example on a messaging app like IG the user could choose to allow DMs but not receive notificati ons about new posts in the feed\n\n * beverloo@ note:\n\n * ChromeOS i s also very interested in this\, would like to see something like this sup ported. We might be able to mimic support in Windows through grouping.\n\n * Nuances to consider on Android: channels are declared once and are then permanent\, i.e. updating the importance\, sound\, vibration etc. of a channel **should not happen** after it’s been created\, even when the channel’s name changes.\n\n\n\n* Reducing notification energy use (curr ently need to spin up JS)\n\n * The current web notifications spec was de signed with maximum flexibility as the objective. With the current spec\, notifications require a Service Worker and when a notification is received \, the ServiceWorker wakes and can then take some action. \n\n * The solu tion is an amendment to the notification specification that optimizes for the most common notification usage pattern of simply displaying a notifica tion on the user’s device. This change will improve performance and ener gy usage of notification delivery.\n\n * @beverloo note: We’ve always b een supportive of receiving push messages and showing notifications w/o in volving the service worker\, this would bring major system health benefits .\n\n * There has been some resistance from partners to support this as they need the SW / analytics logic to run for monetization.\n\n * Andr oid would be able to support high priority notifications in a declarative path. This is important because the framework deprioritises notifications for an entire app (i.e. the browser) based on show and interaction rates\, which means that currently a single misbehaving site can negatively impac t the holistic browser notification experience.\n\n * Big +1 to doing t his if we can get broader ecosystem adoption.\n\n**Goal(s):**\nShare issue s with current notification spec & ecosystem\, possibly connect to problem solve in the future.\n\n\n**Materials:**\n- [slides](https://lists.w3.org /Archives/Public/www-archive/2023Oct/att-0001/Notifications_discussion_-_T PAC_2023.pdf)\n- [minutes](http://www.w3.org/2023/09/tpac-breakouts/18-min utes.pdf)\n- [live google doc minutes](https://docs.google.com/document/d/ 1QJ-zs7B9EHIolG_8RwwxwsUyr1FHRKe7bYscP9zOLus/edit)\n- [Session proposal on GitHub](https://github.com/w3c/tpac2023-breakouts/issues/18) STATUS:CONFIRMED CREATED:20230905T053655Z LAST-MODIFIED:20231012T082320Z SEQUENCE:2 ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor eply@w3.org LOCATION:Lebrija - 1st floor CATEGORIES:TPAC 2023,Breakout Sessions END:VEVENT END:VCALENDAR