Peter and Martin are inclined to close this issue as unsatisfied. Thoughts follow...

This whole ID business is distracting. Can we focus on the use case and legitimacy of it, or not?

A site can provide a link to another website. With a same-origin install, a website can initiate an installation. Enough?

The ID of a manifest is a URL. However, that URL is not expected to be resolved, which is weird (note: ask Marcos Caceres why). If it resolved to a manifest, a lot of things would be easier. If it resolves to nothing, that's fine too. The manifest is what is provided to navigator.install() as options.

The presumption here is that trust is a finite resource. People trust a limited number of sites. So in deciding what sites to trust or not, they end up picking just a few. Having an app store as a trusted sites is convenient, because it enables people to broker that trust into multiple app installations from multiple sources. But what power does that confer to the app store over those installations? A mobile app store has a considerable level of control over what apps can or cannot do. They can withdraw an app that violates those terms. This is antithetical to a web that rejects the notion of centralized control.

https://github.com/w3ctag/ethical-web-principles/issues/120 --> https://github.com/w3ctag/ethical-web-principles/issues/120#issuecomment-2272278572

Tess: If we think this is a bad idea, we should lead and trail with "this isn't a great idea", but we can include advice in between.

[Missed some minutes]

Tess: There are lots of things app stores do. Do they make sense as separate APIs? We should try to tease apart the use cases, and evaluate each one.

Tess: If we encourage them at all, are we doing them a disservice?

Martin: It's not them who gets the disservice. It's what it does to the web.

Jeffrey: Note that https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_cross_domain.md#non-goals includes several of Tess's orthogonal pieces.

Martin to draft a new proposed comment in https://github.com/w3ctag/design-reviews-private-brainstorming/issues/27.

we discuss how this is related to Ethical Web Principle issue 120

we discuss the security characteristcs of apps and how web inherently doesn't need this

we discuss the discoverability use cases

given that the discoverability use case is the key one, is it enough the warrant to the added complexity / potential security issues

Jeffrey: there is the security argument - some web sites are malicious and will trick you into entering your credit card - safe browsing is the thing... user's browser will block sites... a store might do a better job. this API doesn't allow the store to do the better job... One defence for this if it improves security - and it doesn't. This is not a discoverability mechanism... but without it, there is an "extra click". That sounds like a rel attribute to me, "please install this", and then the browser can decide whether or not to do it.

Tess: yes exactly... One counter-argument - why it's an API... a rel attribute value is not gated by user activation... you can cause the link to be followed from script. But the browser could tell and only do the special thing if activation is observed...

Dan: It would be declarative that way.... So yeah... Maybe this would be a good idea?

Tess: rel="install"

Dan: there's another goal, the 'app store' to know whether I've installed it or not and provide a different UX if so

Tess: right now we allow a visual distinction between visited and unvisited links, and sites cannot detect visited link styling so they can't tell if you've gone there or not. There's ane xisting mechanism for us to do something different for different kinds of links on the page. The browser could know. Different pages which link to the same app should not know that I instaslled it from somewhere else. But arguement to expose it to the original page

Dan: other goals - they want to track the fact you installed and report back

Tess: it's clear a rel="install" doesn't get you everything that the API gets you. We could do a styling thing to visually distinguis (I don't think it's a good idea). Tradeoffs. If a rel="install" gets you 80% of what you want simply and declarative

Dan: wondering if web app scope extensions could help in some way. Same people. Bidirectional agreement between origins. If we say we don't think they should be able to do cross origin installation, but if they used this declarative appraoch and there was a bidirectional agreement between the parties. You could do that out of band.

Tess: something in the web manifest, which is more or less what they already had. Also rev.

Dan: if I follow a link that says rel="install" because of the referer header it will know where the link came from.

Tess: you don't even need to rely on that. If you want to require an opt in what you would probably do is just fetch the manifest immediately. Could prefetch the manifest for every link on the page

Dan: a way to achieve all their goals without building a whole new api

Tess: it doesn't handle the payment and conversion tracking cases. In the same origin case .. in safari and macos you can add to dock any website. User doesn't care about the manifest. Weird disconnect between same origin and cross origin. Cross origin requires a bunch of infrastructure. There's an arguement for it, but if yo've already adopted the same origin install api on your own site and someone reaches out to include the app.. the hoops to do that are a lot. A rel install wouldn't require those extra hoops.. it's a bonus, but..

Dan: The browser is going to that place where the app is, which it needs to do anyway. The delivery of the code is not centralised.

Tess: the UI flow in the browser for a rel install could be streamlined; a double opt in from both sides. If there's no opt in the browser might get more in your face to the user about whether they want to do it.

Jeffrey: will write notes into issue. We may want to invite them to talk to us directly.

Proposed comment: https://github.com/w3ctag/design-reviews-private-brainstorming/issues/27#issuecomment-2339370537

Jeffrey: I think there's nothing to discuss this week...

Peter: Ok let's punt...

Jeffrey: to talk to the WICG folks about including it in the discussion at TPAC

Waiting on proponents.

We spoke at TPAC and there is no new information.