Specifying manifests vs documents

[mikewest]

Copy/pasting from @LiaHiscock's comments in #4 (comment):

"""
Off the top of my head, there are a couple complications with requiring only a manifest file. The main one brought up was that manifests can be served over different domains via CDN, which opens the door for spoofing issues, and would require additional validation, likely something like -

1. Load the manifest file in the background.
2. Parse the start_url, and load that in the background.
3. Verify that the document at start_url contains a link back to same manifest from step 1.

This extra loading could be avoided but would exclude manifests served via CDN, as noted by Dan in his recent reply -

One thought for manifest_url only install - This seems maybe OK if we require the manifest is same-origin as the start_url. Most manifests we see satisfy this. I could see this simplifying the cross-origin install, although the tradeoff is potentially stale manifest urls.

We're definitely open to iterating on the attribute design, especially given that a direct manifesturl link would enable custom rendering in the button, but given that our mutually established goal was to OT/ship a basic element to start getting developer feedback, we thought proposing a 1:1 matching of declarative attributes to API parameters would make the most sense. This will also give us more time to discuss design, usability tradeoffs, and technical implementation with Dan and co, without holding up the initial declarative OT.
"""

[dmurph]

From my duplicate issue #14

I want to make sure this proposal is outlined at least for evaluation. Given our history of issues here with installUrl, I'm a bit more convinced that this might be better / acceptable to have, especially if we want a cross-origin install element to be performant getting a name and icon. But - I'm not sure and I would love thoughts from others.

Proposal:

• Allow the dev to specify a manifestUrl instead of an installUrl, with the requirements/changes:
  • Parsing fails if the manifest specifies a start_url/id/etc that is NOT the same origin as the manifest_url. (so this means that sites hosting a manifest on a CDN would have to host on their origin instead). CDN usage for manifest exists but isn't huge.
    • e.g. https://www.example.com/manifest.json has to have the start_url & id evaluate to a url in https://www.example.com/ - it cannot, say, have those urls point to https://word.microsoft.com.
  • For specifying, we can say manifest is parsed setting the documentUrl as the origin of the manifestUrl. But we likely want to change the manifest spec more for this, especially as we will also want to fetch things like icons as a.... independent / non-document-attached network request (so no going through serviceworkers, no document context stuff, etc)

Pros:

• Much simpler installation path here, using far less resources to show a name and icon for the site (no background page needing to be loaded).
• Due to cheapness of fetch, not having a manifestId attribute seems totally fine (or having that optional), as fetching the manifest is so easy.

Cons:

• Potential issue for devs that use a version / hash for the manifest name, as third party installs would potentially use an outdated manifest. But this might work itself out as the install button would break due to the manifest no longer being there, which the store dev can fix / deal with as we would report that error.
• Apps that use CDN urls for the manifest are not eligible.
• This type of install doesn't allow 'online instal offline launch', as the app doesn't have an opportunity to install a serviceworker. So we would likely want to follow up with adding back a serviceworker field to the manifest, however that might work.

Future considerations:

• Adding the serviceworker member in the manifest.