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

> @benfrancis wrote:
> > @dmurph wrote:
> > 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 would let malware 'take over' an app, as they would just set their `id` field to the manifest url. Even if we decided to 'verify' the start_url has a link to this new manifest, they could change the start_url in their bad manifest & it would look valid.

> 
> 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 think the real 'trusted' aspect here is the `<link rel="manifest" href="...relative or absolute url here...">` part. This is, in a sense, the source of truth here, and I think we would treat the manifest linked from the start_url as the authoritative one. I think would have to be the same for all solutions here, even `manifest_url` - stores and browsers would verify that the start_url's manifest link actually links to the given manifest, and if it doesn't use the linked one.
 
> @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) as a default listed in the explainer are also quite attractive and the disadvantages boil down to it being equally inconvenient for everyone!

Yeah, and most importantly here we would be breaking the expectations / infrastructure of all WebApp devs, as they are relying on either `start_url` or `manifest_url`implementations, instead of just one set of WebApp devs. Hard to say if it will continue to "just work" for most of them.



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