Notifications - Sharing current problems & issues

• Past
• Confirmed
• Breakout Sessions

We have a number of rough areas, and while we might not be ready to figure out a solution yet, we would love to chat about the current issues we are seeting. @b1tr0t and @beverloo have most of the context here (although @beverloo won't be at TPAC this year)

• Abuse / spam / requiring install for notifications

  • Chromium is seeing a large quantity of abuse across the ecosystem. We don’t believe gating notifications to installed use is the answer for reasons.

  • We are considering rate limiting and other countermeasures

  • Are there opportunities for standards revisions that might help?

• "important" notifications (VOIP). @beverloo notes:

  • MSFT already working on this:

  • Intent to Prototype on blink-dev, explainer, initial implementation

  • Example hero use-case - empower Skype on the Web.

  • On Android this would require a permission (FOREGROUND_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.

• Notification sounds (ringing?)

  • Related to important notifications, some apps might want a ringing sound

  • 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” “Ringing” “Alarm”, and perhaps others

  • @beverloo notes: This was part of a Microsoft proposal that we provided feedback on

    • Explainer

    • Long story short, a (admittedly brief) joint investigation showed that very few sounds would actually be consistent 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.

    • For Chromium to support arbitrary sounds, the media team advised that the best way to achieve that would be to load a (background) tab with a <media> element in which we play the developer-provided URL. That’s a significant system health cost.

    • On Android such sounds are tied to the notification channel as opposed to individual notifications, and actually cannot be set for individual notifications anymore.

• Notification channels.

  • Allow sites to register and send to specific channels, similar to capabilities offered on Android and iOS platforms

    • 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

  • beverloo@ note:

    • ChromeOS is also very interested in this, would like to see something like this supported. We might be able to mimic support in Windows through grouping.

      • 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.

• Reducing notification energy use (currently need to spin up JS)

  • The current web notifications spec was designed 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.

  • The solution is an amendment to the notification specification that optimizes for the most common notification usage pattern of simply displaying a notification on the user’s device. This change will improve performance and energy usage of notification delivery.

  • @beverloo note: We’ve always been supportive of receiving push messages and showing notifications w/o involving the service worker, this would bring major system health benefits.

    • There has been some resistance from partners to support this as they need the SW / analytics logic to run for monetization.

    • Android 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 impact the holistic browser notification experience.

    • Big +1 to doing this if we can get broader ecosystem adoption.

Agenda

Chairs:
Daniel Murphy

Description:
We have a number of rough areas, and while we might not be ready to figure out a solution yet, we would love to chat about the current issues we are seeting. @b1tr0t and @beverloo have most of the context here (although @beverloo won't be at TPAC this year)

• Abuse / spam / requiring install for notifications

  • Chromium is seeing a large quantity of abuse across the ecosystem. We don’t believe gating notifications to installed use is the answer for reasons.

  • We are considering rate limiting and other countermeasures

  • Are there opportunities for standards revisions that might help?

• "important" notifications (VOIP). @beverloo notes:

  • MSFT already working on this:

  • Intent to Prototype on blink-dev, explainer, initial implementation

  • Example hero use-case - empower Skype on the Web.

  • On Android this would require a permission (FOREGROUND_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.

• Notification sounds (ringing?)

  • Related to important notifications, some apps might want a ringing sound

  • 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” “Ringing” “Alarm”, and perhaps others

  • @beverloo notes: This was part of a Microsoft proposal that we provided feedback on

    • Explainer

    • Long story short, a (admittedly brief) joint investigation showed that very few sounds would actually be consistent 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.

    • For Chromium to support arbitrary sounds, the media team advised that the best way to achieve that would be to load a (background) tab with a <media> element in which we play the developer-provided URL. That’s a significant system health cost.

    • On Android such sounds are tied to the notification channel as opposed to individual notifications, and actually cannot be set for individual notifications anymore.

• Notification channels.

  • Allow sites to register and send to specific channels, similar to capabilities offered on Android and iOS platforms

    • 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

  • beverloo@ note:

    • ChromeOS is also very interested in this, would like to see something like this supported. We might be able to mimic support in Windows through grouping.

      • 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.

• Reducing notification energy use (currently need to spin up JS)

  • The current web notifications spec was designed 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.

  • The solution is an amendment to the notification specification that optimizes for the most common notification usage pattern of simply displaying a notification on the user’s device. This change will improve performance and energy usage of notification delivery.

  • @beverloo note: We’ve always been supportive of receiving push messages and showing notifications w/o involving the service worker, this would bring major system health benefits.

    • There has been some resistance from partners to support this as they need the SW / analytics logic to run for monetization.

    • Android 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 impact the holistic browser notification experience.

    • Big +1 to doing this if we can get broader ecosystem adoption.

Goal(s):
Share issues with current notification spec & ecosystem, possibly connect to problem solve in the future.

Materials:

• slides
• minutes
• live google doc minutes
• Session proposal on GitHub

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