New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 25 users

Issue metadata

Status: Fixed
Long OOO (go/where-is-mgiuca)
Closed: May 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocked on:
issue 587623

Sign in to add a comment

Issue 402223: Dedupe notifications between native app and web page

Reported by, Aug 9 2014 Project Member

Issue description

What would be a reasonable way to dedupe notifications between native apps and web pages? Relevant if you have the nyt app installed and also give permission to use the Notifications API.

Idea 1: nyt identifies user and dedupes before sending a push message. E.g. sends only to the native app if it is installed.

Idea 2: Some kind of collapse key in the notification so when it is shown from both native and web, there's still only one notification.

Any more?

Comment 1 by, Aug 10 2014

Labels: Cr-Security-UX

Comment 2 by, Aug 10 2014

Couldn't the notifications API de-dup if it notices two identical notifications in a short period of time? Without a collapse key, just based on similarity.

Comment 3 by, Aug 10 2014

It would have to be the Android notifications system that does the deduping. The web notification would contain one additional piece of content (the origin) so the duplication matching would need to handle that. We can ask whether there currently is any such feature.

Comment 4 by, Aug 11 2014

The Android NotificationManager only allows an application to view and manage notifications displayed by the current app. If you install both BCC News and BBC News Beta, you would get duplicated notifications as well. (Unless BBC would handle this on the server side, in which they could also include their website.)

Automatically removing duplicate notifications in the Notification manager has the difficulty that ours may appear completely different due to the forced inclusion of a Chrome app icon, origin, settings button, and so on. It would have to be a rather broad heuristic.

Android apps themselves aren't origin verified. Including a unique string for deduplication (analogous to the Web Notification API's "tag" property) *might* work if it's the newest notification that gets dropped, to prevent people from replacing other, cross-app/website notifications. It would still be very tricky, though.

Comment 5 by, Aug 11 2014

The notification dedupe tag would have to be interpreted by the Android system. So if it does not exist yet and we can add that feature, it would only work for post-L release. Definitely worth discussing this with the Android ppl.

Comment 6 by, Aug 11 2014

Oh, good point about Android.

For CrOS/Chrome, we could dedupe between Chrome apps and web pages simply based on the content because everything goes through Chrome's notification center.

Comment 7 by, Aug 11 2014

I'm a little bit wary of content-based deduping.  Can we use another more reliable method such as id sharing?  Something like the following setup:

* App registers for a domain in its manifest's permissions section
* Then the ID namespace could be shared for web notifications (and possibly extension api notifications) allowing for cooperative deduping by web sites and apps using the same id for the same notification.


Comment 8 by, Aug 14 2014

Status: Assigned
Michael, can you help drive this to conclusion?

Comment 9 by, Aug 14 2014

Also, thinking about this some more, which app will "win" in the case of a duplicated notification?  We will want a single app (be it mobile or web or packaged) to have control over updates / cancels and to receive events so that it has consistent behavior.

Comment 10 by, Aug 18 2014


Comment 11 by, Feb 9 2015

I don't suppose there is a clever way of sharing a device ID between native app and Chrome as this would mean a developer could de-dupe server side with relative ease.

Comment 12 by, Feb 9 2015

Comment 13 by, Feb 9 2015

Can we refocus the problem so that we send enough information that the app developers can detect this server side and make the right call of what entity should get the notification?

What is currently missing server side to be able to make that call?

Comment 14 by, Feb 9 2015

In order to deduplicate notifications, the application server that sends push messages needs to know:
* user
* if web, the origin (e.g. vs
* device
* web or native

If the user signs into a webapp, the first part seems solved appropriately.

In the face of concerns around fingerprinting, I doubt we will expose an explicit device identifier in Chrome. Some other vendors are even less likely to do this. So we don't seem to have a simple and solid cross-browser solution for this yet.

I also don't know of a solid way to coordinate between web and native. The web should probably not be able to read whether a native app is installed. I've seen tricks to work with this though, but how reliable are they?

Comment 15 by, Feb 9 2015

To clarify, there are currently two (hacky) ways to dedupe notifications:

1. Web app generates a random GUID, stores it in a cookie, and shares it with the native app by having the user click a link to a URL that the native app intercepts using an intent filter*. The native app extracts the GUID from the URL query string. If instead the native app isn't installed then the page loads in the browser and the web app now knows that the native app wasn't yet installed.

2. Native app generates a random GUID and shares it with the web app by launching Chrome with a URL whose query string contains the GUID. The web app saves it in a cookie or similar.

In either case, both the native app and web app now share the GUID, and once they both send it to their server it can dedupe push notifications.

These both have the downside that you have to redirect the user to/from the native app. I suspect that in the web->native direction you can make a transparent intent handler that saves the data then immediately exits, so the web app remains in the foreground and it's (almost?) seamless, but I haven't tested this.

Let's make this bug about standardizing a cleaner solution (without redirecting the user to/from the native app) and/or documenting the existing approaches with sample code.

*: (it's also possible to use an intent:// URI, but this has the downside that if the app isn't installed the user will be taken to the Play Store instead of back to the webapp)

Comment 16 by, Mar 20 2015

In Chrome 42 you can use an intent:// URI and specify a fallback URL which the user should go to instead of the play store. You could set this to be the current page to avoid the redirect to the play store. 

Details about deep linking into apps including fallback URLs:

Comment 17 by, Apr 14 2015

Labels: -Fizz-Push Cr-Blink-PushAPI

Comment 18 by, Oct 14 2015

For now the safest minimal solution is for sites to provide an easy opt out mechanism (which we strongly recommend you do anyway!) so users can turn off notifications from one platform

Another possible heuristic based solution is to take some measure for which interface (web or native) the user most often uses (or most recently used) and only send to that. Combined with grouping these devices by rough screen size should give a pretty good approximation.

The issue is that if the user has two similar sized devices and uses native on one and web on the other then notifications will only be delivered to one, which is an edge case.

We've also been discussing building an API so sites can tell whether their corresponding native app is installed to avoid this case, but need to start discussing that with other browser vendors to see if they'd be supportive.

Comment 19 by, Dec 4 2015

Owner: ----
Status: Available

Comment 20 by, Mar 8 2016

Some more thoughts about techniques to apply in addition to or instead of heuristics:

1) When the user taps the button in your UI that triggers Chrome's permission request, first fire an intent into your native app from the site taking them to a screen which says "push notifications are already enabled", and note on your site to stop promoting it to them on this device. That can be achieved using the intent-firing technique documented by Paul Kinlan here: His blog has more posts on related topics if it's confusing.

The risk now is a user enabling push and then later installing your native app. One potential improvement here is:

2) If your native app uses Chrome Custom Tabs then when a user taps a link to read an article you could open them first to a page on your site which disables push notifications from the web app and then redirect them to the article. Chrome Custom Tabs share the cookies/push subscriptions etc with normal Chrome so you can disable push from here.

Hopefully this API will be available soon too, which will provide more options:!topic/blink-dev/0xXsJYdkaWg

Comment 21 by, Nov 22 2016

Components: -Security>UX Internals>Permissions>Model

Comment 22 by, Nov 22 2016

Components: -Security>UX Internals>Permissions>Model

Comment 23 by, Mar 20 2017

+cc mgiuca@ and benwells@. mgiuca@ is the eng lead on the getInstalledRelatedApps API, which is probably the best solution we have to this problem (it lets a website query if the native app is installed, and thus it can then decide whether or not to prompt and send notifications).

Comment 24 by, Mar 20 2017

Note that the getInstalledRelatedApps() API mentioned in #23 is not available in Service Workers, which is where the vast majority of notifications get shown from. That limits websites to check for duplication at subscription time. Which is a good step, but may not be sufficient per the aggressive "please install our native app" campaigns some websites are doing.

Comment 25 by, Mar 20 2017

Blockedon: 587623
Status: Assigned (was: Available)
Yep, this is being addressed now (Issue 587623) with getInstalledRelatedApps.

That's a good point, #24, about service workers. Probably won't work out of the box so will have to be implemented in a follow-up.

Comment 26 by, May 3 2017

Labels: M-59
Status: Fixed (was: Assigned)
#24 There's a bug for workers (Issue 716307).

Otherwise this is now landed and available behind an origin trial in M59.

Sign in to add a comment