Push Notifications with MV3, but without User Approval

[Andy Mitchell]

# Summary

Issue

My app synchronises user data from the server to local storage. It does it for 3 reasons: 

• offline stability if the server is inaccessible 
• privacy, making the chrome extension storage the single source of truth with optional server syncing (so the user can change their mind about data locations) 
• cost, get local cached data rather than expensive server loops 

Example: keeping their preferences the same between home & office (sadly, chrome.storage.sync is not workable, see P4 below). 

Right now, it seems polling is the only option. And an expensive one. Because Push requires user visual approval for Notifications (which the user is unlikely to grant), and MV3 denies any long running listeners. 

Goal

Ideally, when the server has an update, it can silently push that fact to the background page, which can then opt to sync. 

The performance/cost gain is significant. Rather than a chrome alarm polling a server every few minutes, it can respond to a pushed sync request that really only needs to be done on average once a day. 

# Other Discussion

Simeon ( @dotproto ), you stated you'd like to see this functionality made possible too - in https://groups.google.com/a/chromium.org/g/chromium-extensions/c/V6cZ5ORplBY/m/QjuljFzLCgAJ 

# Detailing The Problems

P1. For background syncing, Push Notifications / FCM are unworkable due to UI requests

From the user's POV, they just want to optionally 'log in to turn on preference syncing'. 

If I use Web Push Notifications, or FCM, or chrome.gcm, the user has to approve to receive a Notifications UI. That makes no sense to them in the context of preference syncing. 

They'd either need it lengthily explained to them ("it's a workaround"), or they'd deny it, and then be upset that the preference syncing appears to be broken. 

In either case, they've had a poorer UX. 

(For helpful reference, the decision to always force Push Notifications to require visual user approval appears well defended. See the quote of Google DevRel Doug Stevenson in https://stackoverflow.com/questions/48692169/can-i-use-firebase-cloud-messaging-without-notification-permission-javascript . However, that argument imo doesn't apply to Chrome Extensions, to which the user has given their trust.)

P2. With Manifest V3, there can be no long-running listeners

It was previously possible to achieve non-polled syncing by either: 

• Set Firestore's .onSnapshot, which would callback in the client any time the server data changed. 
• Setting up an EventSource for SSE, so our server could push requests to sync. (Albeit those are also short-lived, but a 30 mins timeout was more workable than MV3's 5 mins.)

I totally appreciate MV3's decision to prevent costly long-running listeners. But currently, that decision is forcing me to resort to polling. Which is not only similarly costly in computer resources, it actually costs a lot more in server resources.

P3. Support docs don't currently answer what 'wakes up' MV3 service worker

Supposing P1 is fixed, and FCM's onMessage works silently (wonderful!)... Will it continue to actually 'wake up' the service worker? 

The question really is: which initial event listeners survive the ephemeral service worker (MV3) being stopped after the max 5 mins? 

I gather that the native chrome.alarm, and chrome.runtime.onMessage can wake up the service worker (and expect the deprecated chrome.gcm would). My assumption is based on their namespace. 

But given that FCM's onMessage is imported - and looks like any other non-native Javascript - will it be terminated with the service worker? 

What about Web Push Notifications? 

P4 Chrome.storage.sync is not viable for Gmail extensions

This would have been such an easy option for many use-cases! 

Alas, it fails for the many-many accounts problem of Chrome login vs. Gmail login. The crux is that the data is synced to their Chrome logged in user, but within that, they can log in to many Gmail accounts. There's no guarantee those data repositories align.

I find this slightly hard to explain, so let me give an example: syncing Preferences for my Gmail extension, between a home computer and work. 

At home, the user:

1. Logs into Chrome with a...@gmail.com

2. Logs into Gmail with a...@mycompany.com 

At work, the user: 

1. Logs into Chrome with a...@mycompany.com

2. Logs into Gmail with a...@mycompany.com 

From their POV, as the Chrome Extension is for Gmail, they expect their synchronised data to always sync for a...@mycompany.com. 

However, with chrome.storage.sync, the repository at home is for a...@gmail.com, and the repository at work is for a...@mycompany.com. 

Despite them both having a keyed entry for a...@mycompany.com, the data is siloed, and no synchronisation can occur. 

Summarising the Problems 

A silent/background Push Notification system that doesn't require visual Notifications approval would solve all the above. 

It would: 

• Improve performance (no polling) 
• Be a better UX (don't make the user choose to opt in to something that doesn't make sense - or worse, have to understand an explanation of why it's a workaround)
• Facilitate privacy (make it possible to have chrome local storage the 'single source of truth' for their data, with the _option_ to sync if the user permits their data to touch a server) 

[Andy Mitchell]

Potentially partially answering P3...

Apologies, I'd missed that when the extension is instantiated, and the background service worker is called the first time, event listeners which are established in that first synchronous run are what later reinvokes the service worker (Top Level Event Listeners). 

Assuming Top Level Event Listeners work for any valid Javascript (not just chrome.* APIs), that's appreciated and clear. 

Sadly, it still wouldn't enable using Firestore's .onSnapshot, as the preliminary step of logging the user in is asynchronous. 

Nor do I believe EventSource listeners would endure, as it needs to be reestablished every 30 minutes. And subsequent set ups would not be Top Level Event Listeners, so could not awaken the service worker. 

[Jon Howard]

Watching this thread with interest as I'd like to investigate ways to push status updates to users without having to resort to periodic polling.

[Uladzimir Yankovich]

Any news or ideas? 

[Oren Zomer]

Upvoting. Is there any way to send a silent FCM notification, to help the browser extension update its data, without a toast of "This site has been updated in the background"? I couldn't find any solution using the firebase cloud-messaging docs . I understand the motivation when it comes to websites that might abuse this api when they update service-workers - but here we're talking about a Chrome Extension, which is similar to an "app" than a "website".

The old chrome.gcm.onMessage handler did not show a toast.