Web Install API - Cross-Origin

[plinss]

Hola TAG!
I'm requesting an early TAG review of the Web Install API.

The Web Install API allows a web site to install a web app (cross domain). This functionality allows the creation of web based catalogues that can install PWAs directly from the web and into multiple platforms.

• Explainer¹ (minimally containing user needs and example code): Explainer
• User research: N/A
• Security and Privacy self-review²: Security Questionnaire
• GitHub repo (if you prefer feedback filed there): GitHub repo
• Primary contacts (and their relationship to the specification):
  Diego Gonzalez, GitHub, Microsoft
• Organization/project driving the design: Microsoft Edge
• External status/issue trackers for this feature: Chrome Status

Further details:

• [ X ] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future):
• The group where standardization of this work is intended to be done ("unknown" if not known): Unknown/webapps
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Microsoft Edge

You should also know that...

there's plenty of positive developer feedback for an API like this one!

[LeaVerou]

@plinss, @hober and I looked at this today during a breakout. We didn't quite understand how the flow is supposed to work for the app store use case. How would the app store get manifest ids, given that it seems the only way to procure a manifest id is after installation? Why not simply provide URLs to manifest files? What does the additional complexity of a manifest id get us?

Also, the install_sources field seems to largely be replicating CORS functionality. Obviously, installing is a markedly different use case than reading, so there needs to be some way to declare the author intent that not every website that can read the manifest should be able to install the app, but an Access-Control-Allow-* header seems like a more natural fit for this.

[hober]

@diekus, did you see @LeaVerou's questions above?

[diekus]

Hola @hober @plinss and @LeaVerou,

Thanks for your patience! In the app store use case, the developer must already have this information. Could be asked when an app is being submitted or previous information that someone wanting to link and install 3P apps can easily find out. For cross-origin installs, the installing origin needs to have the to-be-installed origin's manifest id beforehand. Part of the reason we prefer to have an id for the app instead of pointing to the manifest's URL is because this URL can change. The id does not point to a resource that can be navigated to. It is just a unique way to identify the application.

About CORS I think this is good feedback! I'd like to keep CORS functionality implementation open to a future/parallel expansion of Web Install for sure. To start though, CORS is a bit less developer friendly, and thinking about developer ergonomics I'd like to have the install origins definition not rely (only) on headers.

If both CORS and manifest install_sources were to be supported in the future, do you see this as an acceptable solution?

cc @amandabaker @dmurph

[hober]

@diekus wrote:

For cross-origin installs, the installing origin needs to have the to-be-installed origin's manifest id beforehand.

Why? Having a manifest at all isn't required for the same-origin installation case, so why require it in the cross-origin one?

[hober]

@diekus wrote:

For cross-origin installs, the installing origin needs to have the to-be-installed origin's manifest id beforehand.

Why? Having a manifest at all isn't required for the same-origin installation case, so why require it in the cross-origin one?

Put another way: if any website can provide a button for the user to add it to the Home Screen or Dock, and if it's reasonable for some other website to be able to initiate that on the original site's behalf (a premise I'm not personally sold on but let's grant it for the sake of this conversation), why would we limit the second scenario to a(n inscrutable to the user) subset of websites?

[diekus]

Hola @hober, thanks for your feedback, we've been pondering about the implications of navigator.install for same/cross-origin installations and the requirement of an id. I've reviewed the current designs for the API and think some changes are needed to warrant consistency between the same/cross origin use case (this is a very valid point you bring up!) and futureproofing the API.

First, we want to make both use cases require an id. This doesn't have to be a manifest id, it could be any string that the developer uses to identify or refer to the content. If this is a cross-origin scenario for a web app, then highly likely this will be a manifest id. In a same-origin scenario, where there might not even be a manifest present, the developer could call the install method with an arbitrary id they give their content (i.e. navigator.install('myinstallid123')). If in the future they wanted to add a manifest file to that (non-app) content, they could do so and use the same string they used as an id and the app could continue updating without any issues.

This resolves the concern in a way that makes the API consistent independent of the use case (same/cross-origin) and doesn't require the same-origin to-be-installed-content to have a manifest id or to be a web app. We believe it prevents developers from creating a bad app ecosystem as well.

In the case of cross-origin installations, the requirement is to be an installable app and to require a manifest due to bad actor potential and avoiding a bad site to install any URL. This is achieved by opting into the installation sources field, which is present in a manifest file.

cc @amandabaker @dmurph

[dmurph]

In case it's helpful, I modified my earlier proposal here to match what Diego is proposing after we had a discussion. I am in alignment with Diego here, and that doc goes a little more in depth into the use-cases & edge cases here related to supplying an id field.