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

Hola TAG. I've missed you ✨.

So getting back to business. We've completely reworked the shape of the API. Both explainers (for [same](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_same_domain.md) and [cross-origin](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_cross_domain.md)) 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](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_cross_domain.md#privacy-and-security-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](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WebInstall/explainer_cross_domain.md#privacy-and-security-considerations), 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 💖. 

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

Message ID: <w3ctag/design-reviews/issues/888/1898536219@github.com>

Received on Thursday, 18 January 2024 14:01:53 UTC