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

On January 12, 2015 at 10:29:26 PM, Ben Francis (notifications@github.com) wrote:
> > Because the manifest can live on a different origin (e.g., a CDN) and two apps can share  
> the same manifest for whatever reason.
>  
> I'm still not convinced that a manifest should be allowed to be hosted at a URL on a different  
> origin from the document referencing it,

Please note multiple origins is independent to the problem of identity. More below... 

> but even if it can, why does that prevent it being  
> used to identify an app?

Because two apps can use the same manifest. For instance: 

https://cnd.genericmanifests.com/manifest.json 

App 1 - Foo!: 
```HTML
<link rel=manifest href="https://cnd.genericmanifests.com/manifest.json">
```

App2 - Bar!: 
```HTML
<link rel=manifest href="https://cnd.genericmanifests.com/manifest.json">
```

> What are the use cases for two apps sharing the same manifest? I can't think of any.

There are many reasons why one might want to host a static resource (CSS, JS, images, videos, sounds, and a manifest) on a different origin. For example, assets may be managed by a different organization or teams. Or it may be for performance or localizations reasons. The key thing is, the manifest is just another resource and it breaks developer expectation to restrict to one origin in any way (when compared to CSS, JS, HTML, or other media, which are not restricted).  

In cases where two apps make use of the same manifest URL, the actual content of the manifest can vary by the value of the Referer, Origin header - or even via a Cookie.

```
if(http.req.headers.origin ~ "foo.com"){
    http.response( ... foo's specific manifest ... ); 
} 
```

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

Where it gets weird is when start URL and scope contradict each other in an update. For instance:

```JSON
{
  "scope": "/foo/",
  "start_url": "scope_buster.html"   
}
```

The spec defaults to "unbounded" for scope in such a case. 

Additionally, an update may grow the scope from, say: `/myapp1/`, to: `/`. 

Where one might have "/myapp2/" also as a registered scope. I think that might be kinda ok, because the domain owner might choose to capture more scope in myapp1 - or as a means of deprecating another app (myapp2)*.

* note, my working assumption is that a domain that shares multiple applications has a sensible policy in place for its app developers. If app developers decide to trample each others' scopes, that's their prerogative. That doesn't affect any other origin, so that is ok.    

> The user  
> would presumably have to re-install the app and delete the old instance? If the start  
> URL was previously undefined,

To be clear, start URL can't ever be undefined. That's guaranteed by the spec. 

> and then is set to "/", would that count as being a different  
> app?

No. Just the start URL has moved. However, there could be a race condition. 

1. User has installed Foo! previously. 
1. User launches browser. 
1. foo.com updates its manifest to a new start_url. 
1. user goes to foo.com, selects add to home screen.
1. because installed Foo! hasn't got its update yet, it doesn't know it's identity has changed. 
1. There are now Foo! (old version) and Foo! (new version) on the home screen. 
1. Foo! (old version) gets updated. 
1. Foo! and Foo! are now the same - but different.
 
So, this leads me to believe that identities have to be managed by the OS... more below. Once something becomes an "app", it integrates with the OSs security and privacy settings and is no longer managed by the browser. Just like in [1]. 

> Counter-proposal: The manifest URL should identify an app and the start URL can change  
> over time like all the other properties of the manifest.

As above, this is not practical because two apps can have the same manifest URL (and can, for instance, vary by some HTTP header). Also, the start URL was already free to change...   

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. 

This allows/consequences: 
1. the same application to be installed more than once (sometimes) - which is fine, IMO. Heuristics can help avoid this, but can be left as implementation detail. 
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]. 
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. 
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").  
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.). 

[1] http://w3c-webmob.github.io/installable-webapps/#security-and-privacy

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/commit/a2e8c31ecda1ca7d5673a02e08698e5cf64b5df2#commitcomment-9254539