Re: [manifest] Define identity of a web app. (#272)

I think the real question here is if we want to have the concept of "apps" on the web. Where "app" means something different from "web page". But possibly where "app" means "website".

"Apps" as a concept has been quite popular lately. It's something that both mozilla and google has reacted to as an area where native is putting competitive pressure on the web. "Apps" is what @slightlyoff asked me about when I suggested that we work on manifests together.

The term "app" can certainly mean many different things. They might have an icon or not on a desktop/homescreen/launcher. They might run outside of the browser or not. They may found through an app store or not. They might be installable or not. They might have a back button or not. They user might use them for tasks like picture sharing or document storage. The user might give them additional permissions such as storage or background processing or not. It may run as a separate OS process or not. They may be siloed from each other security-wise or not. Etc.

We don't need to agree on if an "app" can do any of those things. That can be debated separately, and likely better later.

The question we do need to come to an agreement on is if we should have a concept of "app", that's separate from the concept of "page".

### If "Yes, we want to create the concept of an 'app'"

In this case, such an "app" will need to have some form of metadata associated with it. Such as name, icon, URL of the start page, install handling, description platform provided UI such as a back button, description of how they handle external facing features like sharing and storage, security properties etc.

And, importantly, since we're talking about the web, they need to have a URL. Why exactly this is needed will depend on

And, because security is important, it needs to be possible to trust the information on that URL.

I can think of two solutions for providing an "app" a URL. Either we place the above mentioned "app" metadata at that URL, or we make the URL of an "app" be a HTML page, likely the start page of the "app", and have the "app" metadata be available through that HTML page.

If we put the metadata directly at the URL, then it seems like the same-origin model of the web will require that the URL lives on the same origin as the "app". This because we don't have any trustable mechanism for one origin to assert information about another origin.

We'd also need to protect websites which host user content on the origin of the website (which sadly is commonly done). One way to do that would be to put the manifest on some wellknown URL. Another way would be to require that the URL responds with a particular mimetype.

If we instead make the "app" medatata be reachable through a HTML page, then the easiest way to do that would be to place the app metadata in the HTML page directly.

### If "No, we don't think that a concept of 'app', separate from the concept of 'page' is useful".

In that case, then we might still need various pieces of metadata about the page. To enable use cases like "bookmark to desktop/homescreen/launcher".

However again, it seems like the simplest way to provide the page metadata would be directly in the page. The only advantage of putting the data in an external resource is to keep the HTML size down. But the metadata for "bookmark to desktop/homescreen/launcher" doesn't seem to be big enough that that indirection is really worth it.

Alternatively we could enable the page to set the metadata using a JS API. That provides more flexibility than using a declarative approach like the current spec, and would allow the page to dynamically load the metadata from a separate file, thus keeping the HTML size small.

If we do stick the bookmark metadata at a separate URL and host that URL on a CDN, then any time that the UA wants to update the bookmark metadata it needs to download the HTML page and see what the updated URL for the metadata is. This because any time you change the contents of a file on a CDN, its URL change. So this would be yet another argument against putting bookmark metadata at a separate URL, since it requires two GET requests for checking for icon updates.

### In summary

Either we do think that the concept of "app" is useful, or even *might* be useful in the future, and we want the "app" metadata to live as a separate resource. In that case the only sensible solution that I can see is to require that the the metadata lives on the same origin, and that we enforce a mimetype.

Otherwise it really seems like the simplest solution is to inline the metadata directly in the HTML markup. I.e. to simply go back to the original apple-introduced <meta> tags.

Using a separate manifest, but allowing it to be hosted on a CDN and then linking to it from the HTML seems strictly more complex than the <meta> approach without providing any more abilities or simplifications.

Personally I'm these days not that convinced that the "app" concept is needed. But I think it's a very big bet to say with certainty that it won't. So I'd much rather play it safe and put the same-origin restriction in place for now. We can always remove it later if it becomes clear that this whole "app" idea was a bad idea anyway.




---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/272#issuecomment-87495930