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

> This is a good question - and I think this is actually the 2. global id = id (default processed manifest url). 

Yes sorry, that's the section I intended to link to. The difference being that `id` would be an absolute URL, rather than just a string which is concatenated with the start URL's origin.

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

Ah, yes. That does look bad.

Just out of curiosity, and I'm sure I'm missing something here, but although this looks scary, what problems does it actually create? If the `id` URL is just an arbitrary URL used for identification purposes (which could be a manifest URL, or any other URL) and is never actually fetched or used for anything else, does it actually pose a security risk if a developer does something unexpected like use someone else's origin for their ID?

If a URL as an ID worked as I suggested and is only allowed to update an existing `id`-less app if the origin matches the original manifest URL, is it actually possible for malware.com to "take over" an app? I guess it is possible for the user to install malware.com's app first, which could then prevent them from later installing an app from google.com with a conflicting `id`? That does seem messy.

This does bring me back to an earlier point though - if `id` is a field inside the manifest what happens if two different web app manifests claim the same `id`? Is it not possible for user agents to get stuck in an update loop where they keep switching between two or more manifests linked from different web pages as the user happens to navigate to them? This is arguably another benefit of making the manifest URL the global identifier because that can't easily happen.

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

...

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

Losing the linkability/explicit discoverability of web app manifests does feel like a missed opportunity, as does further tying manifest processing to a document URL which limits use cases for manifests outside of a web browser (app stores, app provisioning, kiosks etc. as discussed above).

But if we really have created a situation where it's no longer possible to use manifest URL as an identifier because identity was left undefined in the specification for so long, and it's not even possible to use manifest URL as a default, then I agree with @ralphch0 that scope URL might be the next least worst option.

I used the processed scope URL as an ID for storing web apps in a [Firefox OS tablet prototype](https://github.com/mozilla-b2g/gecko-tablet) and it seemed to work OK, but it was just a prototype. The thing that concerned me about it was the potential for overlapping scopes between web apps, but that's probably fine as long as two web apps don't use the exact same scope (see the comment about multiple manifests claiming the same ID above).

@wanderview wrote:
> The plan of record in service-worker-land is to default to scope when using the legacy single scope attribute and there is no id. If you are using the new-fangled-scope attribute that supports multiple scope values, etc, then you are required to set an explicit id.

That's interesting, and eases my concern about multiple scopes inside a manifest. Is there a draft that we can read anywhere? Aligning manifest with Service Worker in this respect seems attractive.

The [advantages of using scope](https://github.com/philloooo/pwa-unique-id/blob/main/explainer.md#processed-scope) listed in the explainer are also quite attractive and the disadvantages boil down to it being equally inconvenient for everyone!

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