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

162 views
Skip to first unread message

Peter Beverloo

unread,
Apr 6, 2023, 11:00:42 AM4/6/23
to blink-dev

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

unread,
Apr 12, 2023, 6:01:18 AM4/12/23
to Peter Beverloo, blink-dev
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

unread,
Apr 12, 2023, 6:57:17 AM4/12/23
to Yoav Weiss, blink-dev
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

unread,
Apr 12, 2023, 7:03:05 AM4/12/23
to Peter Beverloo, blink-dev
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

unread,
Apr 12, 2023, 8:04:33 AM4/12/23
to Yoav Weiss, blink-dev
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

unread,
Apr 12, 2023, 8:20:55 AM4/12/23
to Peter Beverloo, blink-dev
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

unread,
Apr 12, 2023, 11:15:02 AM4/12/23
to Yoav Weiss, Peter Beverloo, blink-dev

Mike Taylor

unread,
Apr 13, 2023, 9:29:19 AM4/13/23
to Daniel Bratell, Yoav Weiss, Peter Beverloo, blink-dev
Reply all
Reply to author
Forward
0 new messages