Re: [w3c/manifest] Add a unique identifier for a PWA (#586)

> ...

> @benfrancis wrote:
> @philloooo wrote:
> > I also tried to explain in detail that doing 301 redirect for use case of changing manifest_url either doesn't really support the use case, or ends up with unreliable behaviors for user agents.
> 
> I still think this could be workable. The worst case scenario is that users end up installing duplicate apps on the same device (if they don't remember they already installed it) or with different manifest URLs across different devices, which need de-duping as user agents follow redirects or synchronise with a server. I don't think it would be necessary for documents to always link to the original manifest URL, or for user agents to check all their manifests every time they encounter a new one.

This is an edge case that is bad for users -  we strongly want to avoid the case where duplicate apps would exist for a user, or the user would see an 'install' icon when that shouldn't be applicable (for this case & other cases). These types of issues are also really big for enterprise users who more often than not difficult-to-change infrastructure and need their user flows to go EXACTLY as expected. Weird things like install icons showing up or duplicate apps appearing.

> @benfrancis wrote:
> > @philloooo wrote:
> > > * Change of implicit expectations for desktop WebApp developers
> 
> Whatever solution is chosen, the behaviour of some user agents (including at least one of Chrome desktop and Chrome for Android) will need to change

Kind of - the no default global_id has the option of no migration, but then kind of specs an opt-in migration with the legacy ids.

> @benfrancis 
> > > @philloooo write:
> > > * S6: Apps that specify manifest as data URL will not be updatable
> 
> Agreed, but this already isn't possible on most user agents today (Chromium desktop being the exception). This seems like a reasonable tradeoff given it is inherent in the nature of data URLs. Developers can switch to an HTTP manifest URL if they want to start supporting updates, requiring a one-off re-installation.

It does break existing behavior that developers are relying upon. I would be interested in getting stats here too.

> 
> > > * PWA stores will recognize different versions of manifest URLs as different web apps.
> 
> Depending on how PWA stores collect manifests (developer submission/user submission vs. web crawling) they may temporarily end up with duplicate records which need merging the next time a listing is updated. I agree this is the biggest disadvantage (and impacts sync services too), but I am of the view that developers should be discouraged from versioning their manifest URLs (like 92% of existing web apps), which would help reduce the impact.

Same comment above - bad for users to have this happening, and it would happen, possibly with big properties. 

> @benfrancis wrote:
> > > * If the manifest_url is hosted under a CDN, they will need to stick to that CDN provider.
> 
> I don't agree, they can redirect to a new one.

CDNs go out of business -  it's dependency that people already rely on. Maybe it would never be an issue, but worth mentioning as a Con I think.

> @benfrancis 
> > As I stated in the doc, safari doesn't support updating/looking up installed PWAs, so it doesn't add any use cases relevant to the unique ID problem.
> 
> I don't think it's fair to exclude Safari from the analysis on this basis, given the specification doesn't currently define how to update a manifest it can't be expected for user agents to already support this. As I understand it Safari on iOS does store metadata from web app manifests when adding web apps to the home screen, so what it uses as an identifier to store those data still seems relevant. It should be assumed that Safari on iOS may support updating web apps in the future, if and when that feature is defined in the specification.

I'm guess I'm confused why you mentioned them then. Excited to help get that support prioritized though by figuring out this spec :)

> @benfrancis wrote:
> I'm wondering whether a better compromise between the best conceptual solution and the practical reality might be to add an `id` field as proposed, but make that `id` member an absolute URL and use [processed manifest URL as the default](https://github.com/philloooo/pwa-unique-id/blob/main/explainer.md#processed-manifest_url-as-default-global_id). That would mean picking what Chrome for Android currently does as the default behaviour rather than what Chrome desktop does. It would allow start URL and scope to change without issues and allow developers who want to change the manifest URL to specify an ID inside the manifest in order to do so. Developers who don't want to change the manifest URL (but may want to change the start URL) can continue to use it as an identifier and don't need to use the optional `id` field at all.
....skipping some text...
> If the ID is an absolute URL rather than being resolved against the document URL, could this be possible (providing the new manifest URL has the same origin as the old one)?

This is a good question - and I think this is actually the [2. global id = id (default processed manifest url)](https://github.com/philloooo/pwa-unique-id/blob/main/explainer.md#2-global_id--id-default-processed-manifest_url). This would let someone make this manifest:

```
{
  ...
  id: 'https://www.google.com/manifest.json',
  start_url: "https://malware.com/step_3_profit",
  ...
}
```

I'm not sure how we would have this sort of malware takeover not happen. Let me know if you're thinking of something different here though.



I guess my perspective here is that, while not perfect, our proposed solution allows us to support all of the use cases, keeps all of the relevant information declaratively in the manifest & document (not needing to support redirects for edge cases, possibly forever), but sacrifices:
 * explicit discoverability 
 * android webapp developer expectations (only option which doesn't change someone's expectations is the 'no default global id' one)
 * Migration cost (which exists for someone for all options, but at least is a one-time migration).

which, since the expectations & migration cost would happen here no matter what somewhere, the sacrifice would be discoverability. I think this is solvable by indexes & crawling, so it seems like the best solution to me. I don't think it's acceptable for us to  break data urls and manifest versioning, and with some of the 301 workarounds I don't see how we could support the use cases without nasty user agent edge cases (e.g. "should I show install icon" check would need to re-fetch all existing manifests for an origin to see if any of them now redirect to the manifest listed in the html page). But maybe I'm not seeing something here.


(Ironically, this still would mean that Chromium desktop would still need migration work due to our sync implementation not ignoring 'bad' ids - but that's not really relevant, for this doc, as we're mostly focused on the use cases here.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/586#issuecomment-780775313