Project: chromium Issues People Development process History Sign in
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
Status: Fixed
Owner:
OOO until Nov 12
Closed: May 3
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Team-Security-UX

Blocked on:
issue 587623



Sign in to add a comment
Dedupe notifications between native app and web page
Project Member Reported by mvanouwe...@chromium.org, Aug 9 2014 Back to list
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 nyt.com 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 f...@chromium.org, Aug 10 2014
Labels: Cr-Security-UX
Comment 2 by f...@chromium.org, 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.
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 peter@chromium.org, 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.
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 f...@chromium.org, 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.
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.

WDYT?
Comment 8 by saroop@chromium.org, Aug 14 2014
Owner: mvanouwe...@chromium.org
Status: Assigned
Michael, can you help drive this to conclusion?
Comment 9 by dewittj@google.com, 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.
Cc: mlamouri@chromium.org
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.


Matt, that sounds like device fingerprinting: http://www.chromium.org/Home/chromium-security/client-identification-mechanisms
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?
In order to deduplicate notifications, the application server that sends push messages needs to know:
* user
* if web, the origin (e.g. ebay.co.uk vs ebay.com)
* 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?
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)
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: https://paul.kinlan.me/deep-app-linking-on-android-and-chrome/
Labels: -Fizz-Push Cr-Blink-PushAPI
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.
Owner: ----
Status: Available
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: https://paul.kinlan.me/android-intent-fallback-detection/. 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: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0xXsJYdkaWg
Components: -Security>UX Internals>Permissions>Model
Components: -Security>UX Internals>Permissions>Model
Cc: mgiuca@chromium.org benwells@chromium.org
+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 peter@chromium.org, 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.
Blockedon: 587623
Owner: mgiuca@chromium.org
Status: Assigned
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.
Labels: M-59
Status: Fixed
#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