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

@dmurph wrote:
> It seems like the main sticking point here is the 4th scenario - changing the manifest url. We know many sites do this, and crawling the data from https://pwa-directory.appspot.com shows us about 8.4% of manifests seem to have versions.

Thank you for sharing this list, it helps illustrate the problem well. Although this also means 92% of manifests _don't_ version their manifest URLs, I acknowledge that it has created a real problem.

> If chromium never supported a changing manifest url, then this scenario wouldn't be as important, but unfortunately it was supported and thus people now rely on it. Seems to be the story of the web platform, for better or worse :/

This is very frustrating to me, and a worrying sign of things to come for the web platform given Chromium's increasing dominance, but we are where we are.

The positives I see regarding Google's proposed solution are:
1. The `id` field in the manifest is optional
2. In practice all IDs are HTTP URLs, which is better than inventing a new non-web ID namespace (albeit URLs which don't resolve to a useful resource)

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.

A manifest with URL https://www.example.com/manifest.webmanifest but no `id` field would have the ID `https://www.example.com/manifest.webmanifest` 

If the developer wants to change the manifest URL, they can add an `id` field to the manifest which matches the original manifest URL.

https://www.example.com/manifest.webmanifest?v=2


```
{
  "id": "https://www.example.com/manifest.webmanifest"
}
```

Apps would only be allowed to update using the approach if the origin of the manifest URL stays the same (switching origins could be supported using HTTP redirects, which would happen far less often than the versioned URL use case).

Regarding the potential disadvantages:

>> S6: Manifests with data URL won’t be supported/updatable.

At first glance the approach above could work for data URLs too, by using the original data URL as an id inside the new data URL. Unfortunately because data URLs are treated as unique opaque origins that wouldn't be allowed, because otherwise any new manifest could claim to replace any existing manifest which uses a data URL.

This is the biggest downside, but seems like a reasonable tradeoff for that edge case given it is inherent to the nature of data URLs. Developers can always switch to an HTTP URL if they want to start supporting updates, requiring a one-off re-installation. Updating from a data URL is already not supported on any user agent except for Chromium desktop.

>> Change of implicit expectations for desktop WebApp developers

This is balanced out by the default behavior remaining the same for all those Chromium-based browsers on Android (and KaiOS).

>> S7: manifest is hosted under a different origin: could be a security concern to use a URL from different origin as the global key.

I would like to understand this better. What are the potential risks?

>> When S7: manifest is hosted under a different origin needs to change manifest_url, they can’t create an id field that matches previous manifest_url to keep the identity.

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)? 

>> S2: installed apps on desktop need to handle migration.

But all the Chromium-based browsers on Android don't.

>> S8: web apps that don’t have manifest URLs won’t be supported, they will have to use a different ID system and need to be migrated when they “upgrade”to have a manifest_url.

Is this about web pages which are added to the homescreen but don't have a manifest? It seems desirable to me that if a page starts linking to a manifest, the resultant app should be treated as separate to what is effectively a bookmark to a particular page within the app. Migrating from one to the other probably shouldn't be attempted.

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