Dan: there's going to be a breakout on installation at tpac, but I can't be there. Sangwhan can you be there?

Sangwhan: yes

Tess: there was a breakout at TPAC that I attended - I gave the authors a lot for feedback. tl;dr the core idea navigator.install being an API that would invoke the UA's install flow - is a good idea - we should do something like that. Everything else is fuzzy - lots of additional complexity - they are imagining a fairly complex future where you have a web app that's an app store for other webapps.. I get why but it feels like a lot more complexity... If there's a user gesture restriction on navigator.install and same origin only - this seems sensible. It's easier to envision that flow as something browsers might be willing to expose to users. The indirect case ... might enable malicious actors...

Dan: there does need to be a permission granted from the webapp manifest file to which origins are allowed to install it...

Peter: they want to know if it's been installed...

Tess: they want to know if'ts already installed - but a malicious opt in ...

Dan: it would be interesting to see if we could get broad consensus for a same-origin only navigator.install - and then build from there...?

Tess: we shouldn't block the simple case that we already have consensus on ...

Lea: makes sense.

Peter: they say "the biggest risk is installation spam" - i don't think that's the biggest risk...

Tess: open question in browser land about PWAs and capabilities - because the user installed the thing do you give it more capabilities or not. Mozilla has held the line that you shouldn't. One concern here - if you trick a user into installing a thing - it's a PWA - but if the browser / OS platform gives additional capabilities to installed webapps then this now has those capabilities... Do PWAs get certain capabilities for free - this makes that attack more concerning. There's a coupling - the easier you make it to install a thing, the woser it is to allow PWAs to have additional capabilities...

Some initial feedback form our TAG breakout today:

We're concerned about potential abuse of the "Web app installation from associated domain" use case, especially in a world where installed webapps might be auto-granted additional permissions.

We're generally happy with the same-origin-bound use case of navigator.install(). We're wondering if you might consider a phased approach to this where phase 1 tackles the same origin case and phase 2 works on the more complex use cases - as this will give some opportunity to explore how the installation function itself works and will give time to explore and design mitigations for potential abuse cases for associated domain installation.

We think the expected venue should probably be Web Applications working group (after this graduates from WICG) and/or the WHATWG HTML workstream.

Dan: leaves comment

No reply from them since Sept, marked pending external feedback. Dan to nudge Diego

Dan: We received feedback from Diego...

assigned to Tess & Lea - noting that we got feedback from Diego and should therefor discuss this week assigned to 7b

Questioning what a manfest id is, and why use that instead of a url to the manifest.

Questioning why cross-origin re-invents a CORS-like mechanism for install sources.

• Discussed that the web needs a cross-server mechanism to declaratively set server beahviors, like setting headers.

Issues:

• Separate the two reviews

Same-origin:

• Related apps doesn't make sense without cross-origin version of the API

Cross-origin:

• CORS vs manifest fields
• What is a manifest id?

Hi @diekus, after reading your comment both @plinss were still confused about several aspects of this API:

Wrt related_applications:

• We don’t understand what the use cases are. Say, I have a website with a manifest file. Why would that website prefer to be installed from another repository instead of using itself as the source of truth? What are the use cases? Is it monetization? Analytics? Something else?
• Orthogonal to the use cases, it seems like it would require the Cross-Origin version of the API to work? How is related_applications useful if it's restricted to the same origin?

Wrt installing multiple PWAs from the same origin and related_applications / prefer_related_appliations:

When separating the API into a same-origin and a cross-origin version, it’s important that the separation is "clean", i.e. that the same origin version can be implemented independently and no parts of it should require the cross-origin version of the API. With that in mind:

• It is unclear to us what same origin use cases the parameters of the navigator.install() function serve, since it seems they are primarily geared around verification, which is not really needed in the same origin case.
• Same for the arbitrary referral-info parameter: what is the use case for it in a same-origin context?
• Same for related_applications / prefer_related_appliations: it seems that for these to function they require the cross-origin version of the API?

Also, given the text in the explainer, it is still unclear to use what the author flow is for e.g. having a website that includes multiple apps (website.com/foo, website.com/bar, etc.). A code example would help!

We also don’t quite understand the signature of navigator.install(): it seems that manifest_id is optional but it is possible to provide manifest_id without install_url. What is the use case of that in a same-origin context? It also seems like in the case of a single website containing multiple apps, one would probably want to provide an install_url, and it seems like it's the manifest id that should be optional?

Also please note that TAG principle around preferring a dictionary for optional arguments.

This is waiting on proponents still.

Peter: there is a lot of commonality with cross-origin... e.g. manifest IDs... a lot of these features in the same origin case seem to be tied into cross origin...

Dan: feels like same origin API should be the less contraversial and simpler thing...

Peter: .. i think certain things (like IDs) are in there to support the cross-origin cases. So why have an ID separate from the URL? Why not just the URL of the webapp? You're giving the URL of the webapp you's installing... so don't see what the ID does. The reason for having the ID in the API is when you're installing an app that doesn't have a manifest... so having that ID is only useful in the appstore context.

Dan: Having an ID ... unique ID ... that is extraneous to the URL for the APP... is adding developer complexity...

Peter: I'm ok with being OK with this API but pushing back on "why the ID"?

Hi @diekus we discussed on today's call. One thing we are not clear on is the need for the separate ID in the case of same origin installation. Are there other cases, not related to app store cases, that would require a separate ID (separate from the URL to the webapp itself)? Otherwise it seems like this could be simplified (and thereby reduce developer complexity) by removing the need for a separate ID?

Dan: leaves comment

Dan: outlines history

Jeffrey: seems like cross-origin case exists in order to compete with native apps so - do we think of new APIs as changing the web or changing the whole ecosystem... centralization/ decentralization...

Tess: I usually talk about ... camp that thinks that the web and native are in competition... and that's the battle ... there's another camp that sees them as complementary... The first camp can often come across as antagonistic towards native & think we need feature parity..

Tess: on same origin... are we agreed that any web site can call it? Originally there were a bunch of requirements - e.g. manifest, manifest can have a bunch of things in it... to me, as long as it's gated on a user gesture, it feels like any web site can call it.

We take a look at the explainer - it says

In order for an application/site to be installed, it must comply with installability criteria. This criteria is entirely up to the UA, can vary depending on the installation target, and can be optional.

Tess: I get that...

We're happy to see that the installability criteria is indicated as up to the UA.

We're going to close this for now with a satisfied label. Please ping us to re-open when you want a follow-up review.

Dan: we can review at the plenary.