Define identity of a web app.

[marcoscaceres]

• what identifies an app? An origin?
• how does one update the app?
• what happens if the scope changes?

[marcoscaceres]

//cc @sicking

@mounirlamouri do you have any thoughts on the above?

[benfrancis]

The obvious answer is the manifest URL. Are there any other suggestions?

[sicking]

Given the lack of other ideas. I think we should simply go with the manifest URL yes.

[marcoscaceres]

I wouldn't say there is a "lack of ideas" - we just haven't gotten around to this yet.

[sicking]

I think this needs to be a very high priority as it's likely to affect a lot of other features. For example the ServiceWorker registration API might affect what we do here.

[marcoscaceres]

Prioritized. Will work on this next.

[opoto]

Shouldn't the spec state that the identifier is the manifest's canonicalized URL, so that: HTTP://my.domain.com:80/app/manifest.json and http://my.domain.com/app/images/../manifest.json are considered as same app identifier?

[sicking]

Yeah. That sounds right. Is there a difference between canonical URL and resolved URL? I.e. do you need to do anything extra to get the canonical URL after you resolve a URL against its base-URL?

[marcoscaceres]

To clarify, URLs are not their serialized string representations - they are objects. Once a string is parsed to a URL, paths are normalized. Hence, there is no such thing as canonical URLs or resolved URLs. There are just URLs.

The spec always treats URLs as being in their object form (being parsed from string input) - so adding clarifications like the above wouldn't really help too much.

[opoto]

This makes sense. Thanks for the clarification. Maybe it should be in the spec? Or maybe this is obvious to anyone else but me... BTW, I checked the "URL" dfn link, but it leads to https://url.spec.whatwg.org/#url-parsing, whereas I guess it should be https://url.spec.whatwg.org/#concept-url.

[marcoscaceres]

@opoto thanks! fixed the busted link. There is some ongoing work to fix cross-document references in the tool I'm using to generate the spec (Respec). That should allow for more seamless jumping between concepts and their definitions. I'm a bit hesitant to add (non-normative) clarifications for concepts defined in other specs, as every time I've done that it's not ended well: either the other document changes and there is a slight mismatch in definition (leading to confusion) - or the Editor of the other spec gets upset because I'm redefining their stuff.

[marcoscaceres]

Elsewhere, I proposed that identity be handled by the OS.

[jmajnert]

@marcosc - In https://github.com/w3c/manifest/commit/a2e8c31ecda1ca7d5673a02e08698e5cf64b5df2#commitcomment-9254539 you wrote:

With this current proposal, the identity of the app will change if the start URL changes (e.g. from index.php to index.html). If an already installed app had its start URL changed in the manifest, it would stop getting updates and be orphaned on the device.

It's identity would simply be updated to reflect the new start URL, and the manifest URL would remain the same. The application is updated from the manifest and hence, so long as the manifest can be accessed, an update can take place.

I'm afraid that I don't fully understand your notion of identity. Why do we even need to have application identity in the manifest spec? At one point the manifest was regarded as just another resource with additional info about the app. Application identity is hard to do right even in closed ecosystems like Android or iOS (author certs, setting up dev accounts, hosting apps in app-stores etc). Aren't we overreaching a bit when trying to define app identity for the whole web?

[benfrancis]

Counter-counter-proposal: identity is managed by OS (as in each application is given a unique identifier - which they will get regardless by the OS when they get put on the home screen). A user agent can use a manifest as a guide to check if an application is already installed (or if something is in scope) - given what it knows about the (URL) provenance of the manifest and the last known values of the manifest.

That sounds better.

This allows/consequences:

2.1 breaking the dependence on permissions based on origin - giving management of the application's storage, permissions, etc. to the OS. iOS shows that this is possible and even desirable [1].

Is it therefore left up to the OS to determine to which URL scope the granted permissions apply? I assume that scope could provide a hint, but that the maximum scope of permissions should still be limited to the app's origin?

1. Updates to occur solely based on the manifest URL - and no identity being tied to URLs that can change in fun and unpredictable ways.

So would it be fair to say that from the point of view of updates, the manifest URL does identify the app? It's just that for other purposes the OS may choose to use another identifier?

1. very tight integration between OS and web browser. Again, I think that's fine - though it will likely be impossible for third-party browsers to support this "install" functionality... though these browsers may do other interesting things with a manifest, apart from installation (e.g., fancy speed dial cells, richer bookmarking, alternative "home screen").

Hopefully it should still possible for third party browsers to provide "install" functionality if the OS provides the necessary APIs to install things.

1. Figuring out whose scope wins when linking is left to the implementation (use last installed app, display a dialog allowing user to choose, etc.).

Sounds good.

FWIW I think that an implementer could choose to use manifest URL as an app identifier if it wanted to (like Firefox OS does), so far the requirement of multiple apps per manifest URL has never come up.

[benfrancis]

Aren't we overreaching a bit when trying to define app identity for the whole web?

I actually think this would be hugely valuable to define here. Making a URL the identity of an app would be a big step in solving the current fragmentation of "web apps" on various platforms. Rather than app stores defining the identity of apps separately for each app store and OS, the web itself would be the single source of truth, app stores would just catalogue the apps available on the web, all OSs could share the same collection of apps, search engines could crawl the web to find web apps, and users could easily migrate their collection of apps from one OS to another.

It's a shame that standardising the manifest URL as the identifier of a web app seems to be a point of contention as that would seem like an obvious answer to me.

[jmajnert]

I just don't think that the manifest spec in its current form (with all the requirements and restrictions documented in this repo) is fit for defining identity. Please consider the requirement for multiple apps per manifest or the fact that start_url is not a mandatory member of the manifest. It seems that the manifest is just a collection of additional info about app(s).

Counter-counter-proposal: identity is managed by OS

So: define identity in the spec but leave its interpretation entirely to the user's OS+UA combination? How interoperable will that be?

[benfrancis]

I just don't think that the manifest spec in its current form (with all the requirements and restrictions documented in this repo) is fit for defining identity.

If defining the identity of a web app is outside the scope of the "Manifest for web applications" specification, then where should it be defined instead? It seems like an important thing to standardise and I'd like to have that conversation.

Please consider the requirement for multiple apps per manifest

I don't think anyone is suggesting multiple apps per manifest, just multiple manifests per manifest URL. I'm not sure where this requirement came from as I've never seen it in practice, but if genericmanifest.com really wanted to host generic manifests, couldn't they just append "?app=" or "#appid" to the URL for each app? Surely a manifest for a different app is a different resource and therefore by definition should have a different URL?

or the fact that start_url is not a mandatory member of the manifest

I think we've established that start_url would make a bad identifier, on the basis that it can change.

[jmajnert]

If defining the identity of a web app is outside the scope of the "Manifest for web applications" specification, then where should it be defined instead? It seems like an important thing to standardise and I'd like to have that conversation.

What I'm saying is that I just don't see how manifest URL could be an app identifier when:

• multiple manifests may have the same URL (dynamically chosen based on HTTP headers etc)
• multiple apps can use the same manifest hosted at the same URL
• the manifest itself doesn't have to point to a start_url and even if it does, it is just a hint for the UA, which may choose to ignore it. So it doesn't even need to tell the UA how to "start" the application

All of the above things are features of the manifest that make it a supplementary source of information, but not a defining entity.

Surely a manifest for a different app is a different resource and therefore by definition should have a different URL?

Not necessarily. An author may wish to create many apps and provide just one manifest to indicate the authorship, CSP policy, and other "common" data.

Having said that, I agree that having a web-wide identifier for apps would be a big win. Just not sure that the manifest, as currently drafted is a good basis for that.

[marcoscaceres]

On January 13, 2015 at 11:11:45 PM, Janusz Majnert (notifications@github.com) wrote:

I just don't think that the manifest spec in its current form (with all the requirements
and restrictions documented in this repo) is fit for defining identity.

Probably. It's why I left it out in the first place... however, it doesn't hurt to throw around a bunch of ideas to see what sticks. Clearly, it's possible to isolate and identify apps in OSs (even if problematic, as you pointed out). 

Please consider the requirement for multiple apps per manifest or the fact that start_url
is not a mandatory member of the manifest. 

To be clear, it doesn't matter that there is no mandatory start_url field, as the start URL is always derived from either the manifest or at the time when the user adds the app to the home screen. 

It seems that the manifest is just a collection
of additional info about app(s).

Correct. 

Counter-counter-proposal: identity is managed by OS

So: define identity in the spec but leave its interpretation entirely to the user's OS+UA
combination? How interoperable will that be?

"How interoperable will it NOT be?" is the interesting question. I'll have a shot a scaling this identity thing back. Then we can put it out for wider discussion. 

[marcoscaceres]

On January 14, 2015 at 12:17:49 AM, Janusz Majnert (notifications@github.com) wrote:

If defining the identity of a web app is outside the scope of the "Manifest for web applications"
specification, then where should it be defined instead? It seems like an important thing
to standardise and I'd like to have that conversation.

What I'm saying is that I just don't see how manifest URL could be an app identifier when:

• multiple manifests may have the same URL (dynamically chosen based on HTTP headers
  etc)
• multiple apps can use the same manifest hosted at the same URL
• the manifest itself doesn't have to point to a start_url and even if it does, it is just
  a hint for the UA, which may choose to ignore it. So it doesn't even need to tell the UA how
  to "start" the application

All of the above things are features of the manifest that make it a supplementary source
of information, but not a defining entity.

Agree. These kinds of URLs are not suitable identifiers for this purpose. IMO, best to just have the system identify an app for itself however it wants. 

Surely a manifest for a different app is a different resource and therefore by definition
should have a different URL?

Not necessarily. An author may wish to create many apps and provide just one manifest
to indicate the authorship, CSP policy, and other "common" data.

Just a clarification: we don't do CSP through the manifest for web apps; though it could be useful for packaged apps.    

Having said that, I agree that having a web-wide identifier for apps would be a big win.
Just not sure that the manifest, as currently drafted is a good basis for that.

The humble URL + having scope is "good enough", IMO. It covers the 80% use case, if not more.

 

[marcoscaceres]

@benfrancis, @jmajnert, how about https://github.com/w3c/manifest/commit/afe3bf8949af3fb9d70b9094fa4a6f385047a8e4 ?

[benfrancis]

@marcosc Despite the arguments put forward to the contrary I do still think the manifest URL would make the best identifier, but if not all implementers want to do this then I think leaving identity down to the implementation is OK.

If identity is left down to the implementation, does it even need mentioning in the spec? You mentioned before that the manifest URL can be used for the purpose of updates. Is there some other part of the spec that relies on defining the identity of the app for other purposes?

@sicking Do you have any input here?

[jmajnert]

afe3bf8 does a good job of not saying anything about constructing the identifier. @benfrancis question stands - where is the identity used in the manifest spec and can we do without it?

[marcoscaceres]

where is the identity used in the manifest spec and can we do without it?

Ok, will kill it.

[marcoscaceres]

Reopening based on discussion with Mozilla and Google. Proposal is to force same origin on manifest in the hope that manifest's identity makes the URI unique.

Note: this doesn't solve the issue, as you can have apps:

• foo.com/a/
• foo.com/b/
• foo.com/N/

All point to foo.com/manifest, so I don't see what this solves.

[jmajnert]

This would make some sense if the start_url was an obligatory field and it pointed to a single entry point of the application. This way app devs would find it hard to use the same manifest for different apps.

[marcoscaceres]

On Thursday, March 12, 2015, Janusz Majnert notifications@github.com wrote:

This would make some sense if the start_url was an obligatory field and it pointed to a single entry point of the application. This way app devs would find it hard to use the same manifest for different apps.

I love making stuff hard to use:). Specially when it's still easy to just dynamically bypass.

Anyway, I'm going to add the restriction and then let UAs deal with it. Still think this a terrible idea on so many levels, but whatever.

If I'm right, the issues will surface quickly and implementers will be forced to backtrack. If I'm wrong, it won't matter.

—

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

[jmajnert]

I love making stuff hard to use:). Specially when it's still easy to just dynamically bypass.

:-) As with every piece of tech, you can use it in ways that the creators didn't plan for and possibly shoot yourself in the foot.

The manifest can either be a collection of supplementary information about an app (or apps), or a document defining one application. It can't be both. We should decide which way we want it to go.

[jmajnert]

Reopening based on discussion with Mozilla and Google.

Was this discussion public and written down somewhere? Can I see it?

Proposal is to force same origin on manifest in the hope that manifest's identity makes the URI unique.

Wondering how that will help? Merely making manifest same origin with the app?

[benfrancis]

@jmajnert wrote:

The manifest can either be a collection of supplementary information about an app (or apps), or a document defining one application. It can't be both. We should decide which way we want it to go.

Yes, we discussed this and concluded that Mozilla's position is that it should define one application.

As with every piece of tech, you can use it in ways that the creators didn't plan for and possibly shoot yourself in the foot.

True, developers could try to create multiple apps with the same manifest (e.g. with the same name, icon and start_url), it's just likely to fail to install. So we should recommend against that.

Was this discussion public and written down somewhere? Can I see it?

Unfortunately not on this occasion, but happy to answer any questions.

Wondering how that will help? Merely making manifest same origin with the app?

As I understand it the idea is that the manifest URL authoritatively identifies an app, so the user wants to be sure that foo.com can not create a manifest for bar.com which it has no relationship with. This also makes it possible to resolve the start_url against the manifest URL rather than the document URL, though I don't think the spec says that yet. The manifest URL is used to reason about and to update the app so multiple apps with the same manifest URL can not be installed.

In building APIs for Firefox OS we've found many instances where apps need to be referred to by some globally unique identifier. Manifest URL makes a great identifier.

Manifest URL also makes a convenient identifier for search engines which can crawl the web for apps via link relations and know that a linked manifest is an authoritative description of an app.

[jmajnert]

Yes, we discussed this and concluded that Mozilla's position is that it should define one application.

Great! Are you planning to put some text into the spec that would stress this?

As I understand it the idea is that the manifest URL authoritatively identifies an app, so the user wants to be sure that foo.com can not create a manifest for bar.com which it has no relationship with. This also makes it possible to resolve the start_url against the manifest URL rather than the document URL, though I don't think the spec says that yet. The manifest URL is used to reason about and to update the app so multiple apps with the same manifest URL can not be installed.

In building APIs for Firefox OS we've found many instances where apps need to be referred to by some globally unique identifier. Manifest URL makes a great identifier. Manifest URL also makes a convenient identifier for search engines which can crawl the web for apps via link relations and know that a linked manifest is an authoritative description of an app.

OK, I get it now - same origin restriction makes it harder to create a manifest for someone else's app. But the manifest doesn't link to the actual application (start_url is not mandatory and is only a hint for UAs), it's the application that links to the manifest. So a sane developer would presumably only link his application to a manifest if they controlled both, right? So why make it harder to host the manifest elsewhere (eg on a CDN)?

Or we could go the other way (more appy, less webby):

• one app per manifest
• manifest on the same origin as app
• start_url mandatory in manifest and unambiguously defining application's entry point

[benfrancis]

start_url mandatory in manifest and unambiguously defining application's entry point

What about if start_url defaulted to "/" and was resolved against the manifest URL?

[jmajnert]

What about if start_url defaulted to "/" and was resolved against the manifest URL?

I think this would do.

[marcoscaceres]

On March 13, 2015 at 8:43:22 AM, Ben Francis (notifications@github.com) wrote:

In building APIs for Firefox OS we've found many instances where
apps need to be referred to by some globally unique identifier.

Can you please list what those many instances were? 

[marcoscaceres]

On March 13, 2015 at 8:43:22 AM, Ben Francis (notifications@github.com) wrote:

Manifest URL also makes a convenient identifier for search engines
which can crawl the web for apps via link relations and know that
a linked manifest is an authoritative description of an app.

Please also be careful not to make assumptions about how other implementers might use this. If we want an opinion of a search provider, we should involve them and not speak for them or speculate about how they might use it.  

[kenchris]

This didn't seem to close this issue. Should we close it?

[jmajnert]

Is it merged already?

[marcoscaceres]

Not yet. Janusz, do you still find the text to be unhelpful?

On Tuesday, March 17, 2015, Janusz Majnert notifications@github.com wrote:

Is it merged already?

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

[jmajnert]

Having seen the overall direction in which this seems to be going, I think I can live with this text. So no more objections from me.

[PaulKinlan]

I am frustrated I missed this. I don't believe that having the manifest locked to the same origin makes any sense at all especially in the scenario of managing static content with CDN's. It's not the origin that makes it mean that you can't say foo can't make the app for bar, it's the run time check to make sure that the start URL only ever launches from the origin that the manifest was associated from.

Manifest URL also makes a convenient identifier for search engines which can crawl the web for apps via link relations and know that a linked manifest is an authoritative description of an app.

Honestly, at this point in time,this assumption means 0 to us. If the developer on a page includes a link to a manifest that they don't own, that is their fault as long as the resolution of start_path is on their origin of the document.

[kenchris]

That still doesn't solve issues like third parties being able to set say a splash screen promoting a different product etc. Add stuff to the icons etc... maybe that is not a bit deal, but if there were a simple way of solving it, that would be nice.

If the manifest is linked from the site itself, a checksum would do. I think CSP 2.0 has something like that

[kenchris]

It is not CSP, but http://w3c.github.io/webappsec/specs/subresourceintegrity/

[marcoscaceres]

What if we (Mozilla) used same-origin manifests as an installability signal? That way, Mozilla's products could still enforce same-origin manifests and rely on the manifest as the identity without forcing the same origin behavior on other vendors? It also then gives other OSs the ability to choose their own identifiers.

We could then evaluate the threat of about that @kenchris mentioned (and potentially look at mitigating that with sub-resource integrity or whatever).

My 2c.

[benfrancis]

Pinging @sicking for input as I'm not sure I'm familiar with all of his arguments.

@marcosc wrote:

What if we (Mozilla) used same-origin manifests as an installability signal? That way, Mozilla's products could still enforce same-origin manifests and rely on the manifest as the identity without forcing the same origin behavior on other vendors?

I don't see what that would achieve except create incompatibility between browsers, with some apps only working in some browsers.

I think manifest URL being required to be same origin with the app is only loosely related to identity, it doesn't on its own enforce or prevent manifest URL being used to identify an app.

I know that in Mozilla's implementation of mozApps it's important for cases where an app is installed from another app (e.g. an app store app) rather than from a page of the app itself, and the manifest URL is used for granting permissions to the app origin. But neither of these are currently use cases supported by the W3C spec. I hope @sicking can elaborate on any other reasons.

It also then gives other OSs the ability to choose their own identifiers.

Saying that a manifest URL should be unique to each web app does not prevent OSs using their own identifiers, it just makes it possible to use manifest URL as an identifier and prevents duplicate conflicting apps trying to use the same manifest URL.

I have a question about that actually. If a manifest URL is used to update apps and two apps share the same manifest URL, what happens if the metadata of those two apps diverges? How would a user agent update the manifest URL of an app to a different one and know that it's still the same app?

[marcoscaceres]

I don't see what that would achieve except create incompatibility between browsers, with some apps only working in some browsers.

Won't this happen already? Google will have different installability signals to us (and already do!) - the same will be true with any other vendor that implements this. The signals are not standard and could change from one release to another for whatever arbitrary reason (e.g., Moz might say we only require icons to be at least 90x90px, while Google might demand at least 144x144px... and a million other little variations from there... like must be PNG etc. while some other vendor might demand .jpeg and a splash screen).

Saying that a manifest URL should be unique to each web app does not prevent OSs using their own identifiers, it just makes it possible to use manifest URL as an identifier and prevents duplicate conflicting apps trying to use the same manifest URL.

Sure, but there are still ways of working around this even with the proposed same origin restriction (foo.com/a and foo.com/b both use foo.com/manifest): so uniqueness is just a UA enforced thing irrespective of same origin... whichever app gets installed first is the one that wins.

There is no real way to solve this problem, AFAICT, because even if we force the manifest to live in the scope of foo.com/a, the manifest may say {"scope": "/"}. This again just creates a race condition about which application first squats a URI space (in either manifest or in scope).

I have a question about that actually. If a manifest URL is used to update apps and two apps share the same manifest URL, what happens if the metadata of those two apps diverges?

They just diverge.

How would a user agent update the manifest URL of an app to a different one and know that it's still the same app?

I'm not sure how you would update the manifest's URL (that doesn't change after install) - but you could always use the same manifest URL but just redirect it to the new URL, no? Then two apps could be redirected to different URLs.

But let's pretend you could change the manifest URL for whatever reason, it wouldn't really matter AFAICT: it would just be a new source of information for arbitrary metadata. It would be like a site changing from one JS library to another JS library - so long as the APIs are the same, the app would continue to work (same in this theoretical case). This is because the OS controls what the real identifier for the application is - and the manifest just serves as data source for metadata, no?

[benfrancis]

Won't this happen already? Google will have different installability signals to us (and already do!) - the same will be true with any other vendor that implements this. The signals are not standard and could change from one release to another for whatever arbitrary reason (e.g., Moz might say we only require icons to be at least 90x90px, while Google might demand at least 144x144px... and a million other little variations from there... like must be PNG etc. while some other vendor might demand .jpeg and a splash screen).

Ah, I didn't realise that's how you expected "installability signals" to be used. I thought they were just examples of the types of heuristics that the Chrome implementation is going to use to decide when to prompt the user to encourage them to install an app. I assumed the user can still always manually install an app with "add to home" if they want to. I didn't realise any vendors were planning on actively preventing an app being installed if it doesn't meet some arbitrary criteria. A requirement on the origin of the manifest seems like a big issue to leave down to the implementation.

Sure, but there are still ways of working around this even with the proposed same origin restriction (foo.com/a and foo.com/b both use foo.com/manifest): so uniqueness is just a UA enforced thing irrespective of same origin... whichever app gets installed first is the one that wins.

I agree the same-origin restriction doesn't enforce manifests being unique to an app in any way. I'm proposing that the specification explicitly recommend that apps do not share a manifest URL, because that is likely to prevent both apps being installed by at least some user agents which use that URL to identify an app.

There is no real way to solve this problem, AFAICT, because even if we force the manifest to live in the scope of foo.com/a, the manifest may say {"scope": "/"}. This again just creates a race condition about which application first squats a URI space (in either manifest or in scope).

Navigation scope is a separate issue, I'm not proposing that the manifest URL be forced to be within the URL scope of an app, although that would be an obvious design choice for an app developer. If user agents want to implement deep linking then I think it's an implementation detail how they want to handle overlapping capturing scope (e.g. longest prefix match, give the user a choice which app to use for a given navigation, don't allow apps with overlapping scope to be installed etc.).

They just diverge. I'm not sure how you would update the manifest's URL (that doesn't change after install) - but you could always use the same manifest URL but just redirect it to the new URL, no? Then two apps could be redirected to different URLs.

I don't understand how that would work. It sounds messy.

But let's pretend you could change the manifest URL for whatever reason, it wouldn't really matter AFAICT: it would just be a new source of information for arbitrary metadata. It would be like a site changing from one JS library to another JS library - so long as the APIs are the same, the app would continue to work (same in this theoretical case). This is because the OS controls what the real identifier for the application is - and the manifest just serves as data source for metadata, no?

I thought that's what we were trying to agree on in this thread. As I understand it the Mozilla position is that it should be possible to use a manifest URL to identify an app and therefore a manifest should be unique to an app.

[sicking]

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 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 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.

[anssiko]

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.

I think a fair expectation is to assume the metadata will grow over time (both standard, as well as proprietary extensions), so planning ahead to keep metadata off the critical path likely pays off. An example of what one is required to do today to cater for iDevices only: https://gist.github.com/tfausak/2222823

In that case the only sensible solution that I can see is to require that the metadata lives on the same origin, and that we enforce a mimetype.

This is close to what is spec'd:

• Obtaining a manifest (http://w3c.github.io/manifest/#obtaining) requires the manifest to be same-origin with its owner Document.
• MIME type is currently not enforced, but RECOMMENDED (http://w3c.github.io/manifest/#media-type-registration). A MUST will be problematic for people who are unable to configure the web server. For example, GitHub Pages currently does not recognize application/manifest+json and does not allow people to add new MIME types. Not sure about shared web hosting providers at large though.

[benfrancis]

Thanks for your detailed explanation @sicking.

If a web app is no different than a web page then I don't think there's really much point in the manifest.

lang can be provided by <html lang="en">, name can be provided by <title>, icon can be provided by <link rel=icon>, fullscreen display mode can be achieved with requestFullscreen(), orientation with screen.orientation.lock(), theme_color with <meta name="theme-color"> and start_url is irrelevant.

As you suggest, I think a web app is much more analogous to a web site, in that it is a collection of web pages. In my opinion the manifest only really becomes valuable because of the scope property. By defining a URL scope to which the manifest applies it allows the manifest to provide metadata not just for a single page, but for a collection of pages, and allows that metadata to be set in one place.

I think the only difference between a web site and a web app is that a web app has a manifest which allows it to be loaded inside an application context, rather than a browsing context. The spec defines an application context as a browsing context with a manifest applied. Once an application context is created the metadata applies to all pages loaded inside the context, and any navigation to a URL outside of that scope should exit the application context and enter a browsing context or another application context, without the properties of the manifest applied. This is different to an ordinary browsing context which can be navigated to any URL.

The standalone display mode coupled with the scope property allow a web app, at install time, to register with the user agent as handling a defined URL scope separately from the browser, in a standalone application context. Once installed they can also facilitate deep linking by capturing navigations in the browser which fall within their scope. I believe that web apps which can break out of the of the browser and stand alone as their own application in an operating system are the next evolution of the web. This also seems to be how implementers are implementing the manifest spec, using the manifest to describe a web app which can be used separately from the browser.

Installing a web app, then, is a different and complimentary action to bookmarking a web page. Bookmarking a page just saves a shortcut to a particular URL on the web, which is just one page of a web site or a web app. Installing a web app means registering that app with the user agent as handling a particular URL scope separately from the browser in a standalone application context.

I agree that a web app needs a URL to identify it. For a web app to be defined by the manifest, I believe the manifest needs to be unique to one app and for the manifest URL to be an identifier of the app. I agree that a good way to make sure that the manifest is an authoritative description of an app is to host it on the same origin of the app and to serve it with a particular content type header.

The current version of the spec already says that the manifest must be same-origin with the web app, I think that should continue to be the case. How do people feel about also making the manifest Content Type header compulsory, in order to provide an assurance that the owner of the web server intended the manifest to be an authoritative description of their web app?

[PaulKinlan]

We have lots of prior experience with content types being a bad Developer experience. I also don't agree with same origin requirements (using csp based scheme works for me - which I believe is a change of mind on my part.)

Same origin means that many large sites will struggle to implement this (or prioritise implementing it) because it doesn't play nicely with their cdns.

On Fri, 3 Apr 2015 19:59 Ben Francis notifications@github.com wrote:

Thanks for your detailed explanation @sicking https://github.com/sicking .

If a web app is no different than a web page then I don't think there's really much point in the manifest.

lang can be provided by , name can be provided by