Intent to Remove: Support for Web Push Notifications using FCM Sender IDs

[Peter Beverloo]

Contact emails

pe...@chromium.org, raya...@chromium.org 

Explainer & specification

None, this is a removal of a proprietary addition to the following specifications:

https://www.rfc-editor.org/rfc/rfc8030

https://www.rfc-editor.org/rfc/rfc8292 

https://www.w3.org/TR/push-api/

Summary

Chrome shipped support for Web Push Notifications using FCM Sender IDs M42 (March 2015), after which we added support for a standardized authentication path in M52 (July 2016).

We have been deprecating support for FCM Sender IDs since, adding console warnings and blocking the list of senders in 2019, and blocking all new subscription requests using sender IDs in 2020. Today we see <1000 unique senders still relying on Chrome to receive such messages in a 7-day window -- this is a tiny portion of full Web Push usage.

Following this prolonged deprecation path, we're now proceeding to remove support for Chrome to receive messages for subscriptions that were once created using FCM Sender IDs. Users who receive such messages will stop receiving them until they re-visit the sender's website, at which time it has the chance to renew the subscription. We unfortunately cannot automatically update such subscriptions. The roll-out will be done server-side.

Blink component

Blink>PushAPI

Search tags

push, notifications, webpush

Motivation

This removes a long-deprecated, now barely-used proprietary addition in our Web Push Notifications implementation.

Initial public proposal

None

Search tags

push, notifications, webpush

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Not supported

WebKit: Not supported

Web developers: Mixed signals. <1000 senders still use this for old subscriptions, all others have either migrated, or never relied on this in the first place.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Console warnings were added in 2019, subscription requests have been blocked since 2020.

Is this feature fully tested by web-platform-tests?

No

Flag name

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No. Web Push Notifications are not supported in Android WebView

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=979235

Estimated milestones

Shipping on desktop

113

Shipping on Android

113

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5187711071158272

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/g/blink-dev/c/_3Q0vj7kQiM

[Yoav Weiss]

Do I understand correctly and breakage would just look like users no longer getting notifications?

Would senders have some way of knowing that the notifications never reached their destination?

 

Gecko: Not supported

WebKit: Not supported

Web developers: Mixed signals. <1000 senders still use this for old subscriptions, all others have either migrated, or never relied on this in the first place.

Any idea what the usecounters for such notifications look like?

Have we tried reaching out to those senders?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALt3x6kbrWgWmh25ovUpsChUNSQH7F8hg1iw3OmD70orQCqUCw%40mail.gmail.com.

[Peter Beverloo]

Yes.

 

Would senders have some way of knowing that the notifications never reached their destination?

Yes - the messages will be rejected by the server.

 

 

Gecko: Not supported

WebKit: Not supported

Web developers: Mixed signals. <1000 senders still use this for old subscriptions, all others have either migrated, or never relied on this in the first place.

Any idea what the usecounters for such notifications look like?

No, we don't know on the client how a subscription was once created.

 

Have we tried reaching out to those senders?

Yes, we worked together with the largest parties to help them migrate, and any new adoption has already been impossible for two years. The list of remaining senders is too long to reach out to individually, but both restrictions and console warnings have been in place for the same amount of time.

Thanks,

Peter

[Yoav Weiss]

Sounds like breakage is tolerable, and senders would be made aware that their code is no longer valid. Once they are aware, what should they do? Try to get the user to re-subscribe to notifications? Something else?

[Peter Beverloo]

On Wed, Apr 12, 2023 at 12:02 PM Yoav Weiss <yoav...@chromium.org> wrote:

Sounds like breakage is tolerable, and senders would be made aware that their code is no longer valid. Once they are aware, what should they do? Try to get the user to re-subscribe to notifications? Something else?

Exactly that, the permission remains valid so they can (silently) resubscribe the next time the user visits their website, just without use of FCM sender IDs. Many sites on the list have already adopted the standardized mechanisms.

Thanks,

Peter

[Yoav Weiss]

LGTM1

On Wed, Apr 12, 2023 at 2:04 PM Peter Beverloo <pe...@chromium.org> wrote:

On Wed, Apr 12, 2023 at 12:02 PM Yoav Weiss <yoav...@chromium.org> wrote:

Sounds like breakage is tolerable, and senders would be made aware that their code is no longer valid. Once they are aware, what should they do? Try to get the user to re-subscribe to notifications? Something else?

Exactly that, the permission remains valid so they can (silently) resubscribe the next time the user visits their website, just without use of FCM sender IDs. Many sites on the list have already adopted the standardized mechanisms.

Makes perfect sense, thanks! :)

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEjXVJ4rikYWvmK_1b3Nmj3btrCAKqGhGFDkvsdReCrQ%40mail.gmail.com.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/faf80691-571a-42c9-767b-e4d432296f1d%40gmail.com.