Re: [w3ctag/design-reviews] Web Install API - Cross-Origin (Issue #946)

Thanks for bearing with us. Looking at this proposal again from first principles, it seems like a way to reduce the friction between discovering an app and installing it. The web doesn't need any new APIs for someone to build an application repository to search for apps; that's just a filter in a search engine. We don't need a new API to let someone curate the results in such a search engine according to their current trustworthiness. Without this proposal, the quickest route from an app-search results page to installing an app seems to be:

1. User clicks the result.
2. Landing page presents an "Install me" button. (The landing page can't just request an installation dialog because of the [gesture requirement of the same-origin `navigator.install`](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_same_domain.md#preventing-installation-prompt-spamming-from-third-parties)).
3. User clicks the "Install me" button.
4. Browser presents the installation dialog.

With this proposal, a browser could eliminate the middle two steps:

1. User clicks the result.
2. Browser presents the target app and an installation dialog.

The TAG is split on whether that's potentially an improvement, with a majority thinking it isn't. Given that any given app is installed just once in its lifetime, one click is not a high price. There are several benefits to that: installation is controlled by the origin that will be installed, it doesn't require the creation of a bunch of machinery, and the installation is both attributable and accountable to the correct entity. If you think we need to eliminate that click, your explainer should present some supporting evidence.

If you persist here, and you have UI in mind to deal with all of those issues, we think that a declarative model is likely to work better than the current imperative proposal. You identified a link attribute in your Alternatives Considered section, but maybe a new link relation type would work better than a new `target` keyword. That gives user agents some flexibility in terms of how they handle the request to install, from just ignoring it and navigating, to doing something more actively.

It is not clear to us why sites need to be able to control which stores can install them.  This is the most centralizing aspect of the proposal: if a newly-created store needs to get the approval of hundreds of apps before it can be a viable store, you've created a moat around the incumbents.  What would make that necessary in this model?

The proposed `navigator.getInstalledApps()` sounds plausible on its face, but there are some unresolved issues.  It could be awkward when (for privacy reasons) a store shows an app as not-yet-installed even though the user installed it directly or via a different store. But there's a more serious privacy issue in telling stores whether an app has later been uninstalled: how can users be adequately informed about who's getting that information? It's not clear that the cross-origin signal there is justified.  Keying off DNT/GPC seems like the wrong tool to use as those relate to something orthogonal. If there's a good justification for exposing uninstallation information, a mechanism like `:visited`, which exposes 1 target at a time, might be better than the full list returned by the current proposal.

The TAG remains conflicted on this proposal.  A number of us are firmly of the view that this feature is unnecessary, both in terms of its justification and in terms of the cost.  While that is the prevailing view, others are looking to find ways to enable browser experimentation that minimize the potential harm, especially to users and browsers that don't adopt this change.

Overall, we'd prefer to see this not go ahead at all, but if it does, we'd like to keep talking through the above options or others that might reduce the potential harm.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/946#issuecomment-2345373071
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/946/2345373071@github.com>