How to check if target web app meets PWA criterias without visiting it?

[FluorescentHallucinogen]

@PEConn First of all, thanks for this proposal/explainer!

Not only PWA catalogs/stores like https://pwa-directory.appspot.com, https://appsco.pe, https://outweb.mariusclaret.com, https://pwa-store.web.app, https://findpwa.com, https://pwainside.com, https://progressiveapp.store, etc. will benefit from this.

Another use case is an automatic enrollment of enterprise PWA to a large number of corporate devices. See https://stackoverflow.com/q/57481961 for a similar request. You can add this use case into explainer.

This API would allow a website to request the installation of another target website without visiting it. But how to check if target web app meets PWA criterias without visiting it? Ok, browser can fetch the manifest and service worker (under the hood in the background). BTW, should we bring back the "serviceworker" member into web app manifest? But what about detecting real PWA offline support?

[PEConn]

So for the enterprise use case, the flow would be something like the following?

1. The company asks their employee to visit a certain web page.
2. That web page triggers the web install API (maybe without any user interaction) to install some PWAs.

I'm assuming that the company could set some enterprise policy (eg, to allowlist their website or disable requiring user gestures).

I think my main question would be why would they do this instead of just force installing the WebAPKs through Android methods (which I assume they can do, I'm not 100% sure?).

As for the main question here, that's a good point about the manifest serviceworker field. This will depend somewhat on the UI we settle on as well - if we're going for the Try Before You Buy mode, the user would end up visiting the site before installing it. For the other UI options, my current thinking is that we would probably have to visit the website in the background and figure out the security/privacy implications.

[b1tr0t]

This use case makes sense to me in the case of a large organization that isn't using the Enterprise product. If I understand correctly, it would allow an administrator to create a "software center" type web page that users could browse to in the corporate Intranet and install software from a pre-selected list.

(For organizations using Chrome Enterprise, the administrator can already bulk remote install PWAs, so I assume this isn't for the enterprise case.)

[FluorescentHallucinogen]

I think my main question would be why would they do this instead of just force installing the WebAPKs through Android methods

(For organizations using Chrome Enterprise, the administrator can already bulk remote install PWAs, so I assume this isn't for the enterprise case.)

PWA (and this API) is not for Chrome and Android only. Isn't is? This API should cover other other browsers and platforms.

web page that users could browse to in the corporate Intranet and install software from a pre-selected list.

Yes, I think we should provide the way to ask the user and install the multiple (array of) PWAs at once. What do you think?

[PEConn]

PWA (and this API) is not for Chrome and Android only. Isn't is? This API should cover other other browsers and platforms.

Oh of course, sorry, I was stuck in my Android mindset. You're right.

Yes, I think we should provide the way to ask the user and install the multiple (array of) PWAs at once. What do you think?

Do you think this would be useful outside of the enterprise use case? If it isn't (which is what I'm thinking), that makes designing this (powerful) capability much easier - it can only be activated on websites that are set by enterprise policy.

To be clear, I'm suggesting we have a normal Web Install API gated behind user gesture/permission/browser UI, but then a more seamless approach that's accessible to enterprise websites.