Hi

One question about

The user agent MUST NOT return installed applications when running in a privacy preserving mode, for example Incognito in Chrome or Private Browsing in Firefox.

What if, say, a very popular app has a pre-populated manifest file specifying avery popular website? We can also assume that the app with manifest is shipped by default, let's say in a very popular operating system.

It seems that this Very Popular app would be able to see that the user is browsing in private browsing mode because the website would expect navigator.getInstalledRelatedApps() return nothing when in private browsing mode (but it would know that this particular OS/browser in fact most likely has the app with a pre-populated).

Case in point could be Apple Maps or Google Maps or other X Y.

Hello,

That's a very interesting point which I hadn't considered. Let me start by giving some context around why the incognito restriction was added initially. We were worried that a website might force users to use the native application when users are actually trying to use the website in a privacy preserving mode.

I think this is a useful privacy improvement that will benefit all origins. On the other hand, the situation described by @lknik might give a select few websites another signal for fingerprinting privacy preserving mode, although it will still have false positives (when users uninstall the pre-installed apps).

At this point, I believe the benefits of keeping the privacy preserving mode restrictions outweigh those of the alternative.

Hi @rayankans

We discussed it during 2019-11-19-telecon.

Thanks for the clarification and explaining the rationale for incognito restriction. Would it be possible to clarify it in the explainer/specs (we feel it is important ot make the users/developers aware of this design consideration).

Additionally, are you sure there is no way particular approach you could devise to avoid the ability of private mode detection?

Regardless, it would be useful to have the potential attack scenario documented in as well.

I'm a little concerned about the intended operation / user flow for this when the user has both web apps and native apps "installed." For example, if they have google maps PWA installed (e.g. as a WebAPK) and also the native app, but they prefer to use the PWA, will this API mean that the PWA always gets passed over for the Native version? What happens if they have a PWA installed but no native version? Will they constantly get prompted to install the native app? I'm concerned about functionality that favors the use of native apps over equivalent webapps. Can you please elaborate in the explainer about these cases and how you're going to mitigate against these risks?

Hi folks, thanks for the feedback. I've added an Abuse Considerations section to the explainer.

Additionally, are you sure there is no way particular approach you could devise to avoid the ability of private mode detection?

We could drop the privacy mode restriction to not return any related applications. I don't think that's the right way to go though, it's a privacy improvement for 100% of origins at the expense of having an imperfect privacy mode detector for a very very small percentage of origins. I recommended keeping track of how the API is being used, if at all, by the origins that control pre-installed native applications on certain platforms.

I'm a little concerned about the intended operation / user flow for this when the user has both web apps and native apps "installed."

Unfortunately this is a practice that we already see a lot of in the wild. Certain websites try to redirect you to their native application, and if not installed it would just take you to a place to install it. I don't think this API will affect that practice, but that's why we added the privacy mode restriction. I've expanded on this in the explainer.

As Microsoft could probably use this for PWA installation via the Microsoft Store on Windows, I wonder if you have been in talk with them. It would be great to get their review as well

@aarongustafson for Microsoft PWA things ;)

As an update, Microsoft is supporting this API for Windows (implementation doc).

My apologies for being late to this thread. Yes, Microsoft does support this API for our PWA work and that Implementation Document was written by a member of the Edge dev team. Thanks for calling that out @kenchris and @rayankans .

Hi all. We are looking at this at our W3CTAG face-to-face in Wellington.

The main concern at this point is an architectural one: given that we've had W3C standards for manifests, as well as cross-browser support for installing web applications on a device – we'd like to see this API make more use of the web, rather than only driving users to native apps.

Would it be possible to build in some accommodation for web apps?

Hi @hadleybeeman,

The specification uses the concept of installed apps, and doesn't distinguish between the types whether native or web powered. The syntax and the method of verification is OS/platform specific.

To give a specific example, on Android, you can query for both native apps (by using the app's ID), and web apps (WebAPKs, by using the app's manifest URL).

That being said, although the spec uses the concept of installed apps, the explainer focuses on native apps. I'll update the explainer accordingly.

That's good news, @rayankans! Thanks for the explanation. Great to hear we're already on the same page.

In addition to the explainer, the spec also has a lot of references to native apps. It might be good to clarify those too.

I clarified a bunch of references in this commit

Talking to @marcoscaceres about related apps fields in the Web App Manifest spec yesterday, he mentioned that Mozilla (Martin Thomson, I believe) is working on a slightly changed proposal that will be more privacy preserving. Are you aware of this work?

Yeah, the plan is that Martin is going to send his proposal to Microsoft soon for us to take a look.

@kenchris This is the first I hear of it. I look forward to seeing it.

Since the cat is out of the bag.

Did anyone (@rayankans ?) look at Martin's proposal? Feedback?

Friendly ping @rayankans @beverloo @slightlyoff - it would really be great with your feedback on the "counter" proposal.

@atanassov do you know who from MSFT has been working on the Windows side of this, maybe they have feedback as well. The counter proposal seems quite interesting

@kenchris, I'm a good contact from MSFT for this one. When we tried commenting the paper previously, it was locked for comments. We'll take a look again today.

What is the status of the implemention? chromestatus.com says it is shipping on Android since Chrome M80, but https://web.dev/get-installed-related-apps/ seems to mention that it also works on Windows (Edge only?)

Also as Android apps (and TWAs) can be installed on Chrome OS, does this work there? @mgiuca

[Update] above article says this works on Windows: Chrome 85 or later, Edge 85 or later

Maybe someone should update chromestatus.com :-)

Is this still a chrome-only thing? Has there been any discussion regarding the Mozilla alternative proposal? In line with the TAG Ethical Principles, we'd really like to see multi-stakeholder support.

chromestatus.com has been updated. As @kenchris mentioned the API works on Chrome and Edge for Windows and Android.

As for the alternative proposal, I'm not aware of any updates besides the doc from Martin that was shared on this issue.

Hi there,

The Mozilla position is that this feature increases the fingerprinting surface of browsers without sufficient safeguards, and they have spent time on making an alternative proposal. Unfortunately, it doesn't seem that this proposal has been seriously considered, which the TAG finds disappointing.

Thank you for taking our feedback on board, we still think you need to consider the fingerprinting issue and we look forward to hearing more about your experience of this through incubation in the WICG

Sorry for the delayed response.

We reviewed the proposal when the alternative proposal was shared. My main concern is that it addresses different use-cases that do not match the demand we see for gIRA.

I'm also not convinced about the impact of the drawbacks highlighted in the proposal. It seems to suggest that a coalition can divide users into ~1024 buckets assuming its website has 10 well-adopted related applications.

For one thing, the spec recommends having a UA-defined number of related apps to take into consideration. The number of related apps per manifest in current implementations is limited to 3, which would still make the API useful and severely reduce the tracking issue (8 buckets). I'll work on clarifying this in the spec further.

For another, I'm not sure how a coalition like that would work, is there data or examples around it? I'd assume the scale of users for coalitions in the proposed drawback is in the millions, making tracking is severely reduced.

That being said, the proposal does raise an interesting alternative, and we would be open to integrating parts of it. I'd like to see some more implementer interest, as well as different use cases and how they would address existing demand.

This thread was brought back to my attention today; thanks for pinging us @kenchris.

We did look at the proposal by Martin, but it required the ability to change all OSes that this feature is provided on. If another browser thinks they can get OS vendors to make changes that we don't have confidence that we can convince them to, I think we'd welcome them developing such an API. Usage of gIRA isn't super high right now, but is growing quickly, so the onus would appear to be on folks who have counter proposals to test them out soon:

https://chromestatus.com/metrics/feature/timeline/popularity/1870

On the fingerprinting question, gIRA is designed in the ususal asynchronous style that gives UAs full control over when and what to return, potentially allowing interposition of a user confirmation moment. To @rayankans's point about the restriction to 3 related items, it's reasonable for UAs to filter further, potentially in ways to prevent overlap, to preserve user privacy.