[w3c/manifest] New Boolean members to control interaction with related applications (#658)

For a number of years, there have been requests to support the following two use cases:

1. Suppressing notifications if the related app is installed. If the native app is installed, it could be assumed that it is sending notifications to the user, and thus the web app should not also send notifications.
2. Suppressing the web app install prompt if the related app is installed (in the `beforeinstallprompt` event handler). If the native app is installed, it would put the user into a confusing state if they were also offered to install the web app.

I propose two new Boolean manifest members that declaratively disable certain features of the web application if one or more of the `related_applications` are installed in the user's system.

* `disable_notifications_if_related_app_installed`: If true, then if one or more of the applications listed in `related_applications` are installed in the user's system, notification permission would be auto-blocked for the app. (This would be indistinguishable from the user blocking notifications.)
* `disable_install_prompt_if_related_app_installed`: If true, then if one or more of the applications listed in `related_applications` are installed in the user's system, the `beforeinstallprompt` event would not fire for this application.

A key requirement would be that the web app is not able to actually query whether or not related applications are installed.

Some concerns / issues:

* May need to require that the related application in some way links back to the web domain (e.g., through [Android Digital Asset Links](https://developers.google.com/digital-asset-links/)). Otherwise, you can potentially find out whether the user has any particular native app installed on their device. (However, this may not be necessary since you can't actually query whether an app is installed, you just experience run-on effects from this. But I think a clever malicious site could use knowledge about the behaviour of certain user agents to distinguish whether the app is installed or not.)
* This may not be flexible enough; you wouldn’t know whether or not to show UI relating to notifications in your app (because you can't tell in advance whether it's going to be auto-blocked by the native app being installed, or whether it will prompt the user).
* We may want to recommend that the UA only blocks notifications if the native app has already been granted notification permission in the OS.
* The notification one feels weirdly positioned in the Manifest (since notifications aren't part of the web app manifest, and can be fired by a normal web site). In particular, notification permission is per-origin, while manifests can have a path scope. Would a non-/-scoped manifest block notification permission for the whole origin? Would we ignore it unless the manifest is /-scoped?
* The "at least one" rule might not be flexible enough. Could make it "all", or could allow the user to define some subset of the `related_applications` (replacing the Boolean with a list of app IDs).

An alternative syntax might allow for shorter names and scale in the future if we find more similar use cases:

```json
"if_related_app_installed": ["disable_notifications", "disable_install_prompt"]
```

So there are a lot of details we have to sort out before we do this.

**Background**

Last year, Chrome ran an origin trial for a proposed API called `getInstalledRelatedApps`, which was a JavaScript method allowing the site to query for the subset of the `related_applications` Manifest member that were actually installed on the user's system. This API is detailed in this blog post:

https://developers.google.com/web/updates/2017/04/getinstalledrelatedapps

As the above post suggests, this API had only two known use cases (those at the top of this post).

The origin trial had very low participation and there was not much enthusiasm for continuing with the API ([write-up](https://groups.google.com/a/chromium.org/d/msg/blink-dev/vrB0sJ0tQaI/8teG0oyrAwAJ)). It represents a bit too much of an information leak for a web app to learn about the user's system. A [timing attack](https://bugs.chromium.org/p/chromium/issues/detail?id=707071) was also identified (which would be common to all implementations, not Chrome) that would allow a malicious site to reliably query for the installed state of a non-related application, unless carefully mitigated.

However, we still wish to solve the above two use cases, so we are proposing the above manifest flag, as a simple declarative option that solves precisely those use cases, without actually letting the website know whether the native application is installed, or presenting a timing attack surface.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/658