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

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

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