Sketch out the possible ways to reference 'manifest_url', or using a reference to a webapp

[dmurph]

It might be better to model the 'manifest_url' approach as a 'reference', and then go into some options:

reference =

• manifest_url
  • pros - works well & makes sense, one thing to set as developer.
  • cons - the manifest unique id (explicit or implied using start_url) could change, and if that happens, we would not update the old app & instead install a new one. Also, how do we verify that it is a correct subapp & not a security issue (e.g. the manifest could be for a totally different site, the url could be, say the youtube music app url, or the manifest could just be a copy of the youtube music manifest)
  • note - would be nice to 'verify' that the start_url of the manifest contains a manifest link back to the same manifest, as required for normal webapps. Would fail API call. This would help with one of the cons - the copied manifest of youtube music.
• manifest_url + id, manifest resolved id must match id.
  • pros - prevents incorrect double-installation of an app if the manifest id changes, as this would fail the API call
  • cons - more complicated for developer. same security issues as above
• start_url
  • pros - works well & makes sense, one thing to set as developer. If the start_url has changed (but the manifest link still points to a manifest that has the same id), then we update correctly.
  • cons - ? same security issues as above without the 'copied' manifest security issue

The main 'identifier' for a webapp, in my opinion, is the manifest list (<link rel="manifest" href="manifest.json">). This, which is in the start_url html, basically confirms "yes, this is a web app, and the manifest is here, and we are connected".

So the security issues I'm also seeing here (maybe I should make issues for these):

• Is it WAI that the website can specify any app as a subapp? Or are we intending to limit them to same-origin apps?
• If using manifest_url, then is it WAI that the start_url / app itself could be different origin? Or are intending to enforce same origin for the app start_url?

I will also note that these approaches will make the start_url pages are actually installable in their own right, where the user could just install those pages if they visit the url.. although they, I guess, would be nested in the parent app, so we wouldn't show the install icon.

Even if we did show the install icon & the user installed the sub-apps before the main app added them, we could still easily just update them to being a 'managed' app.

[ivansandrk]

1) Should we go with start_url then? You know this part much better than I do.

2) A big +1 for same-origin. It makes sense to me to draw the security boundary around the origin.

3) > I will also note that these approaches will make the start_url pages are actually installable in their own right

I think this is fine, and perhaps even good; devs can test sub-parts of their big app on their own, and it's not really an issue if users can poke around.

[reillyeon]

I also favor the start_url approach with the requirement that start_url has to be same-origin with the page calling the API.