[Web Install] Feedback

[FluorescentHallucinogen]

Non-goals

• Replace beforeinstallprompt or associated behaviour (this is the way to install from the same-domain).
• Change the way the UA currently prompts for installation of a PWA.

1. As a developer, I want to have a single unified API for both installing web app(s) from another domain as well as from the same domain. So, navigator.install() should completely replace the beforeinstallprompt API.

The beforeinstallprompt API is very poorly designed and has bad DX (developers should listen and catch the event, etc.). I know that @firtman and @b1tr0t agree with that.

Currently, the beforeinstallprompt is implemented only in some Chromium-based browsers (primarily desktop). E.g. on Android it works only in Chrome. In other third-party Android browsers, it is either not implemented at all or the beforeinstallprompt event never fires, despite feature detection reporting it to be supported (e.g. see the Meta Quest Browser case).

(This is partly due to the fact that third-party browsers on Android don't have access to the WebAPK minting server (see https://crbug.com/1243583). So these browsers can't provide the same level of UX as Chrome, i.e. deeper integration with the OS: app icon shortcuts, share targets, etc. None of this is possible without packaging PWA into an APK. That's why these browsers don't promote PWA installation.)

In the other non-Chromium browsers (Firefox, Safari) the beforeinstallprompt is not implemented at all. Moreover, the consensus on beforeinstallprompt and prompt() was not reached (see mozilla/standards-positions#84). So, it's not a part of web standard.

This means that we should think about the design of a new API without fear of breaking the web (backwards compatibility), without looking back at poor beforeinstallprompt API technical/architectural decisions. Moreover, we should try again and give the new Web Install API a chance to reach consensus and finally become a web standard and thus replace the beforeinstallprompt API.

2. PWA install prompt should be a permission request just like any other permission request to access camera, microphone, geolocation or display push notifications. Think of it as "permission request to install web app(s) on the device".

This solves many problems. It fits perfectly with the idea of a system based on a user's likelihood to actually need or want one.

In this case any heuristics, policies and ideas for other permission requests could be applied to install permission too! E.g. automatic permission request blocking with backoff ("embargo") (see https://crbug..com/679877). Or Quieter permission UI for notifications. Or Time-limited Permissions.

It also solves the problem that currently the end user has no browser-level toggle to disable PWA install promotions. This is a very requested feature, by the way! PWA criteria/requirements was relaxed. The valid web app manifest is enough. What happens in the future when every second or even first website is PWA? And the end user has no browser-level toggle to disable these promotions.

See the attached image:

[FluorescentHallucinogen]

3. Consider installing multiple apps similar to downloading multiple files:

[diekus]

Thanks for your feedback @FluorescentHallucinogen. We're internally looking at some changes to the API, and the feedback from developers has been really insightful. I'll get back to you asap!

[amandabaker]

@FluorescentHallucinogen
Your 1st concern around beforeinstallprompt has been addressed with the addition of the same-origin explainer, and the 2nd item suggesting to use a permission is addressed in the cross-origin explainer under Preventing installation prompt spamming from third parties

WRT the 3rd suggestion about installing multiple apps at once, do you imagine that the user would click one "Install" button in a webpage to trigger installation of multiple apps (as opposed to clicking "Install" once per app)? If so, what use case do you imagine here?

[FluorescentHallucinogen]

@amandabaker Sorry for the late reply.

Here are the use cases from top of my head:

• The user clicks one single button e.g. "Install Microsoft Office" and 3 separate PWAs (from different subdomains or even domains) are installed at once: "Word", "Excel", "PowerPoint". The user can then delete the unwanted ones, while the others will remain installed on the device.

• The user can explore the web app store/catalog (view screenshots, watch ratings and read reviews from other users) and add PWAs to the cart/favorites. After that, install them all by pressing one single button.

• Some publishers or just other users may publish web app bundles e.g. collections of the best games, tools, etc. The user can press just one single button and choose e.g. by checkboxes what they want to install from this set.

• Super-apps. The user can press just one single button and choose which services they want to install.

• Easily deploy multiple web apps to a large number of corporate employee devices.

[amandabaker]

Although I see the value in the multi-install case, I find it concerning from a security perspective. Currently, we're depending on a UA-provided install dialog to show the user info about the app before it's installed. The specific info is up to the UA, but Chrome and Edge, for example, show a minimum of the origin of the app and the app name. This gives the user a chance to validate that the app they're installing matches their expectations, so they hopefully don't install a spoof of the intended app.

However, in the multi-install scenario, there's a limit to how much info can be reasonably fit into that dialog without overwhelming the user such that they're likely to miss a malicious site spoofing another origin. Would the UA need to set a max number of installs allowed at once? If there's a limit what would be an appropriate number?

Also, the current shape of the API doesn't support multiple installs at once, so maybe if we can design a robust solution to keep users safe from spoofs in the multi-install case and there's sufficient feedback that this is a desired feature, we could follow up with navigator.installMultiple(). WDYT?