Intent to Ship: getInstalledRelatedApps

[Rayan Kanso]

Contact emails

pe...@chromium.org, mgi...@chromium.org, raya...@chromium.org

Explainer

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

Spec

https://wicg.github.io/get-installed-related-apps/spec/

Tag Review: https://github.com/w3ctag/design-reviews/issues/436

 

Summary

Allow sites to determine whether the user has installed a related native application, where the candidates to be checked are drawn from the "related_applications" key in the web manifest. The corresponding installed application needs to link to the manifest as well.

 

The Origin Trial feedback was positive, with developers wanting continued use of this API. The feedback was even used to extend the API to include app versioning as well.

Link to “Intent to Implement” blink-dev discussion

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

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, the feature will start with Android since it has a defined method for declaring an association from a native app to a website.

Demo link

https://get-installed-apps.glitch.me/

Risks

Interoperability and Compatibility

Edge: Positive

Firefox: No resolved position

Safari: No Signals

Web / Framework developers: Positive based on OT feedback

Ergonomics

No adverse effects on Chrome performance are expected. This does not have a set answer for WebAPKs yet.

Activation

The API can be used immediately when shipped, but developers will need to update their manifest/native apps for the API to work.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Partially (link here). It cannot be fully tested e2e without some wpt infra changes (issue).

Entry on the feature dashboard

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

[Daniel Bratell]

I am not sure what the use case is. The explainer says:

"It is important to allow apps to detect this situation to allow them to disable functionality that should be provided by the other app."

Where would this be a good thing for a user? The mobile web already suffers from heavy handed attempts at getting web users to replace web sites with native apps[1] and this mostly looks useful for funneling users from the open web to closed ecosystems.

/Daniel

[1] Not saying I'm talking about reddit.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAe2mZ2DrLn9fiMCwshbQiUoR0jy8c93phG_J%2B3rfYtw9%2BWmDQ%40mail.gmail.com.

[Rayan Kanso]

There are a few use cases, but the primary one is behaviour synchronization between apps. An example of that would be reducing notification noise, by sending push messages only through the native app instead of both the native app and web push.

Although this isn't an API that would directly benefit users, it indirectly benefits them through improved web experiences. We received very positive OT feedback from partners using this API, and the alternative is them using hacks to figure whether their native app is installed.

Heavy handed attempts to switch users from a web experience to a closed native one already exist, and I don't expect this API will change that. Even so, this API is disabled in incognito mode, so a website wouldn't know if a related native app is installed.

~Rayan

[Yoav Weiss]

I have some reservations regarding the fact that every app can declare N websites and every website can declare M apps as "related".

IMO, that creates a risk of forming large sets of apps related to multiple large website, which would open potential for abuse:

1) Knowing that specific apps were installed can contain valuable and potentially sensitive information about the user: income level, relationship status, sexual orientation, etc

2) The collection of bits of answers to "Is app X installed?" can be a powerful fingerprinting vector.

While I agree that large sets are potentially easy to detect, it might be better to prevent than to cure.

Is there a significant use case to having N and M be infinite? If not, can we limit them to a reasonable value that would prevent large sets from forming?

I don't think such a limit would impact the API shape, so doesn't have to block shipping, but would have to follow it rather closely. (to prevent breakage pain once it's introduced)

If you're happy with introducing such a limit at a recent future version, I'll happily sign off on the API.

[Rayan Kanso]

Thanks Yoav,

I think it's important to keep in mind that all of these declared associations will be publicly accessible. Regardless, having non-infinite associations is reasonable. Since I'm not sure what values for N and M would be appropriate, I'd suggest monitoring how the API is used initially, as you suggested, then select values in a data-driven way after we get a feel of how the API will be used in the wild.

Thanks,

~Rayan 

[Yoav Weiss]

On Wed, Dec 4, 2019 at 7:07 PM Rayan Kanso <raya...@google.com> wrote:

Thanks Yoav,

I think it's important to keep in mind that all of these declared associations will be publicly accessible. Regardless, having non-infinite associations is reasonable. Since I'm not sure what values for N and M would be appropriate, I'd suggest monitoring how the API is used initially, as you suggested, then select values in a data-driven way after we get a feel of how the API will be used in the wild.

LGTM1 provided we're committed to do that.

Can you also add those risks to the spec's Privacy section, until we'd add stricter size restrictions?

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh%3DTHvsDTPdz3CAfJmwuvT5ZytDeNANAe7uHX3VfAcSNA%40mail.gmail.com.

[Brad Lassey]

On Thu, Dec 5, 2019 at 3:02 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM2

On Wed, Dec 4, 2019 at 12:26 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Dec 4, 2019 at 7:07 PM Rayan Kanso <raya...@google.com> wrote:

Thanks Yoav,

 

I think it's important to keep in mind that all of these declared associations will be publicly accessible. Regardless, having non-infinite associations is reasonable. Since I'm not sure what values for N and M would be appropriate, I'd suggest monitoring how the API is used initially, as you suggested, then select values in a data-driven way after we get a feel of how the API will be used in the wild.

LGTM1 provided we're committed to do that.

Can you also add those risks to the spec's Privacy section, until we'd add stricter size restrictions?

Can we ship with a reasonable guess at N and M? If the data says they are either too generous or too restrictive we can adjust later. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_0zsE%3DbuWxrMpbmaX4XeVH7PboTe3AJnyGe46es8XDpw%40mail.gmail.com.

[Rayan Kanso]

I'm adding a limit of only using the first 50 declared related apps from the Web Manifest. The thresholds can be revisited in the future once we get some data.

~Rayan

[David Benjamin]

A limit of 50 is not an effective privacy mitigation. A human can be identified globally with only 33 independent bits, and that's combined across the entire platform. Something like 2 or 3 seems a much more reasonable starting point. We can apply the limit after filtering out the entries not applicable for the OS, so sites won't worry about multiple OS's worth of applications.

It is always easier to add new capabilities than to take them away. That means, when we don't know, we should err on the side of user safety. If we set the limit too high, we risk harm to our users. If we set the limit too low, we do risk missing some use cases, but those use cases are already missed in the status quo without the API. We can then evaluate those use cases against our other requirements if it happens.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL6mntg52Ydn3Tobm1LFMEOLdcUDs%3D0u4T2YE1tv%2B_KEvR9BfQ%40mail.gmail.com.

[Rayan Kanso]

Thanks David. I updated the limit to 3.

~Rayan

[Alex Russell]

Per conversation amongst API OWNERS yesterday, I'd like to see this set a lot lower (say, 2-5) as we haven't seen apps yet that have more permutations to detect than:

• A "full fat" native app
• A "lite" app
• Their own PWA (which I predict we will want/need to reflect through this)

Ryan: is the limit you're landing here settable by Finch? Or will we need to ask for merges to change it post-branch?

Regards

 

Thanks,

~Rayan 

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAe2mZ2DrLn9fiMCwshbQiUoR0jy8c93phG_J%2B3rfYtw9%2BWmDQ%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEh%3DTHvsDTPdz3CAfJmwuvT5ZytDeNANAe7uHX3VfAcSNA%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_0zsE%3DbuWxrMpbmaX4XeVH7PboTe3AJnyGe46es8XDpw%40mail.gmail.com.

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

[Rayan Kanso]

Hi Alex,

It's currently hardcoded at 3, which will be merged back. This should cover the cases you mentioned.

Thanks,

~Rayan

[Alex Russell]

Thanks!

[PhistucK]

> but those use cases are already missed in the status quo without the API

Do they? I do not know the Android architecture, but is it possible for many native applications to run local servers in the background, therefore exposing always-on endpoints that can be accessed/detected by websites?

(Or am I missing the point of this privacy preserving discussion?)

(To be clear, I am pretty much against this API because I feel like it reveals too much about the user, even if it only reveals one application and can cause a website not to work because "the user should use the native application instead", but since the functionality is already apparently available now via the means I mentioned, I do not have a strong case against it.)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANr5HFW%3DnVmbXmg1GNBg%3DxufkBtAiFKeQCvJRuHed39z8W86zQ%40mail.gmail.com.

[Rayan Kanso]

This is missing one more API owner LGTM. Can an owner either approve it, or provide some more feedback on the API?

Thanks,

~Rayan

[Chris Harrelson]

The API owners just discussed this Intent again. We still don't have full consensus on this API; the concerns raised on this thread seem legitimate.

We brainstormed a bit for further ways to restrict this API that reduce risk:

How about only allowing this API when called from an installed PWA? That would prevent sites from abuses such as trying to force users to install a native app in order to see website content, when viewed from a "drive-by web" page load. It would also reduce privacy risk in such scenarios.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL6mnthonHPpWuX_9eHtXNdMYov9G7HvH-X6VipfF8SAOdzEwg%40mail.gmail.com.

[Rayan Kanso]

Hi Chris,

I went through the thread again and I'm not sure which concerns you're referring to. I published this FAQ doc with answers to all the privacy related questions I've been getting. Hopefully that should resolve the concerns.

How about only allowing this API when called from an installed PWA? That would prevent sites from abuses such as trying to force users to install a native app in order to see website content, when viewed from a "drive-by web" page load. It would also reduce privacy risk in such scenarios.

Having this API available only for installed PWAs would severely limit its functionality to the point where it is no longer useful. I'm not opposed to adding gates on the API (e.g. permission, engagement) as long as they solve any potential abuse concerns. With the top-level frame restriction in place, I don't think that's necessary. The FAQ doc covers the scenarios that have been brought up.

Thanks,

~Rayan 

[Philip Jägenstedt]

Chris, I presume your LGTM2 stands, but do you have more details on "don't have full consensus on this API"?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL6mntibeXoChi9BYxoToDr%3DiQGdga60_qgcPM1KwEkBOSkufw%40mail.gmail.com.

[Philip Jägenstedt]

I've gone ahead and reviewed the spec, short and sweet. I've filed some issues at https://github.com/WICG/get-installed-related-apps/issues and it would be good to go through all open issues and close the ones that are no longer relevant, so that it's clear what questions remain. It looks like a few would affect web-observable behavior of the bits already implemented, but I don't see anything that could likely affect the overall design.

Given that, I'm comfortable saying LGTM3, but as usualy if anyone has new issues it's not too late until web apps start to depend on this in significant numbers.

[Chris Harrelson]

Yes it still stands. TL;DR there are now 3 LGTMs for this intent and it can proceed according to the launch process.

Re "don't have full consensus on this API": in the meeting, Daniel Bratell still had reservations about the API even with existing mitigations. I don't think there is much to add that he didn't already mention in his public email responses.

[Daniel Bratell]

Yes, you have the required approvals, and while I have some reservations, the process luckily doesn't require you to convince everyone in the world. Just keep an eye for misuse and if detected, see what's needed to avoid it.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZuC1wB2d%3Dsuc6jVhRHJ11EgZVtd9TcvqPtKFkrWAv0nZg%40mail.gmail.com.