Intent to Experiment: GetInstalledRelatedApps API

[Matt Giuca]

Contact emails

mgi...@chromium.org, owe...@chromium.org

Spec

https://github.com/WICG/get-installed-related-apps/blob/master/EXPLAINER.md

Summary

Allow sites to determine whether the user has installed their corresponding app, where the “candidates” to be checked are drawn from the related_applications key in the manifest.

Installed applications must attest that the origin is allowed to read their installed state. On Android this is done via Digital Asset Links (“Android app statement lists” part only; we ignore website statement lists).

This API is motivated largely by the need for websites using push notifications to determine whether their corresponding native app is installed to prevent sending duplicate notifications.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/0xXsJYdkaWg/2NwHKmZBEAAJ

Note: This was a combined “intent to implement and experiment”, but it’s so old that we are proposing a fresh experiment with a new timeline and goals.

Goals for experimentation

Determine whether the API design is ergonomic

• There have been suggestions for alternate designs, such as making it a single method isAppInstalled, that takes some metadata and returns a promise. We aim to seek developer feedback during the trial about the decision we have made here.

Determine whether the API solves the notification de-duplication issue

• Hear from developers who use this in practice whether it solves their issue.

• For example, it’s possible that the user may have the app installed, but be logged in with a different account (which cannot be detected with this API). It’s not clear to what extent these edge cases not being solved by this API are blockers for developers.

Experimental timeline

Enabled:

• 2017-04-13: M59 branch to dev channel.

• 2017-05-04: M59 in beta channel.

• 2017-06-06: M59 in stable channel.

• 2017-08-01: M60 in stable channel.

• 2017-08-08: Feedback from M59.

• 2017-09-12: M61 in stable channel.

• 2017-09-19: Feedback from M60.

Disabled:

• 2017-10-24: M62 in stable channel. Experiment ends.

• 2017-10-31: Feedback from M61.

Any risks when the experiment finishes?

No

Ongoing technical constraints

Relies on specific features of Android, so is only available on that platform at the moment. Special technical complexity: can’t be “onion souped” fully yet because the Blink side of the code relies on fetching the Web App Manifest, which is defined in Chrome. Therefore, we need a module in content/renderer. Work is ongoing to port this to Mojo so that we can remove the code from content/renderer.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Android only as that is where the feature requests for de-duplicating notifications have come and as related_applications isn’t used for desktop today.

OWP launch tracking bug

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

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5695378309513216

[Dimitri Glazkov]

LGTM

[Matt Giuca]

Minor update on the timing: it would end a week before M62 is in stable channel. So:

2017-10-17: Experiment ends (prior to M62 in stable channel).

[PhistucK]

(Copied and altered just a bit from a different thread)

​Would it also be ​fine by you in the desktop context, or is it only fine by you in the mobile context?

I mean, yes, on desktop, the application can install a local server on an agreed port that returns a response when called by the web application. But the user can generally shut it down.

In this (mobile) case, the user cannot escape this query. This information is simply revealed to the web application.

I would not want the websites I use to know whether I have their applications without asking me. They, for example, may push me into using them instead of using the website, but I prefer the website. They do not disturb users without their applications, so I am in an inferior position as a result of this API.

☆PhistucK

--
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+unsubscribe@chromium.org.

[owe...@google.com]

On desktop there's no clear way to implement it so I don't think we'll be able to support there regardless, at least without creating a rather non-trivial system for the attestation. And yeah, if you install a native desktop application you're basically hosed, it'll do whatever it wants :)

RE: sites pushing you into using their app instead of using the website - I also hate sites that try to force me into their apps. I think that sites that do that will likely pressure their web users regardless of this API - either way you're on their site instead of their app and they're gonna try to force you into their app or the store.

If it weren't for the duplicate notification issue then I would agree that there's no need to expose this information, but given the annoyance and confusion from receiving duplicate notifications I think this is a good change.

Thanks

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.