I got a few questions:

• Is it true that any random Origins will be able to show an APP installing permission? That sounds like a spam to me. Maybe a "don't show any" option would make sense?
• Does the APP need to go through some reviews or be the existing APPs in a former APP store? Or will there be any restrictions/warning? If not, this means allowing users to jump outside the security boundary of the browser by a browser prompt in a sudden to a world that the APP might access every information.

Hi @diekus we discussed briefly in today's TAG session and someone from TAG will be at the breakout session you're holding at TPAC next week so we hope to progress then.

Hi @diekus - thanks for this and thanks also for the TPAC session on this topic which was really interesting!

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.

Hi @diekus any update on this from your PoV? Thanks!

Hola TAG. I've missed you ✨.

So getting back to business. We've completely reworked the shape of the API. Both explainers (for same and cross-origin) have been updated and I am pleased to inform you of the following:

(cc @iVanlIsh)

• an origin can request permission to install web applications, the same way it can request for geolocation and camera access. Even if this permission is granted by the user, web apps/PWAs would need to list this origin in its install_sources for them to be installed. This means that the origin can't simply start installing random content or apps even if it has permissions. These permissions can also be set to expire by the implementor. I agree that having a "don't show any" option on the prompt is a good idea, and in a similar way to expiration, this is relevant to the specific browser UX implementation.

• the content/app does not need to go through review neither does it need to be already in an app store. This would be terribly limiting to a lot of content and would put the final decision of installation in the hands of a few app stores, defeating the purpose of a better, fairer and more democratic distribution process. We believe the user is the one that should always be in control of what content they want to install. The idea of the API is not to comply to existing reviews or guidelines set by app stores... it is only to install an app. For same-origin content, this is not different to going onto Safari and adding the content to the Dock, or in a Chromium browser to add the app to the homescreen/start menu. For cross-origin content, the app will comply with installability criteria that is defined by the browser. In Chromium this means it must have a manifest with a field that allows the installation from the installation origin, is delivered over HTTPS and complies with a set of security and privacy considerations. It doesn't allow users to jump outside of the security boundary of the browser since the app that is being installed is web content.

(cc @torgo)

• the main use case is to allow installation of web content (apps). Content installed using the navigator.install method does not inherit or auto-grant permissions from the installation origin. The API does not break the same-origin security model of the web. These remain independent and fully customizable by the user. Nothing is actually changing here, as each origin has its own set of permissions and there is no scenario or use case where a third party domain could set these for the installed app.

• We have considered a phased approach, starting with same-origin (and looking for consensus with other vendors, which is something I am excited about tbh) and then cross-origin. Both scenarios are quite similar in how they are used, we wanted to achieve consistency between both use cases and make them very similar. I must note that the cross-origin scenario has tougher security constraints, as it is a new capability that until now hasn't been possible in the web platform. Same-origin installs is something that is already doable on the Web.

We've got several store partners in line to try it, including 3P developers that are very excited about the possibilities to democratise application distribution!

I whole heartly agree with you that WebApps WG is the right place for this work 💖.

Given that the request has split into same-origin and cross-origin versions, we split the review accordingly (as we feel one may be able to proceed faster than the other). This review is now about the same-origin behavior, the cross-origin behavior issue is here

This generally looked good to us. Our only comment relates to "related applications". We did not understand what this is for, but it seems to require the Cross-origin version of the API to work. If that assumption is correct, it should be moved there. It is also unclear how navigator.install() supports the use case of multiple PWAs that live under the same origin.

Hola @LeaVerou, thanks for your valuable feedback.

The related_applications part refers to the behaviour an implementer might take when the install API is invoked and that field is present in the manifest file. If present, this means that the developer would prefer their app to be installed from another repository (like the itunes store or the play store) instead. If this is the case, this field points to the appropriate repositories per platform and the UA may decide to handoff the installation to that repository. The alternative is the default method where a web app is packaged and installed by the browser.

Regarding multiple apps on a same origin, they can be installed as they can have different manifest ids and different scopes. For example, https://example.com/app1 and https://example.com/app2 can both be installed even if from the same origin.

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.