- From: Ben Francis <notifications@github.com>
- Date: Wed, 03 Feb 2021 06:29:44 -0800
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/772551059@github.com>
@dominickng wrote: > It is a legitimate use case to host a manifest on a different origin to the start URL (e.g. a CDN). music.bing.com could have an identifier of cdn.bing.com in that case. Yes that's fine, by using the URL the manifest was served from as the ID, by definition and ID of `https://cdn.bing.com/manifest.json` can only be served from `https://cdn.bing.com/manifest.json`. There still can't be a manifest at `https://malware.com/manifest.json` with an ID of `https://cdn.bing.com/manifest.json`. > And while start_url currently has to be same-origin as document URL, #670 proposes to change that to the parent path of the manifest URL. Yes, that would be awesome. But as I understand it, even if that change finally lands, it just means that if `https://malware.com/manifest.json` doesn't provide a `start_url` then its `start_url` defaults to `https://malware.com/`. It still can't provide a `start_url` of `https://music.bing.malware.com` because if both the document URL and `start_url` are provided they still have to be same-origin. Even if #668 succeeds in detaching manifest processing from the document URL entirely (which would be even more awesome), there still couldn't be a manifest at `https://malware.com/manifest.json` with an ID of `https://cdn.bing.com/manifest.json`. I'm looking forward to reading Google's latest analysis, but so far from this 3.5 year thread my personal conclusion is that it really boils down to whether enabling URL versioning of manifests without needing to set up HTTP redirects is worth all the added complexity of: 1. Inventing a new ID/serialisation/linking system for web apps, parallel to web URLs, making web apps less directly linkable and discoverable 2. Making manifest updates a more complex multi-step process for operating systems, which can only take place when a user happens to visit a page which links to a manifest with a matching ID, using the same user agent they used to install the application 3. Dealing with the case of different manifests from different URLs claiming the same ID, which could itself be a security issue if not handled carefully I think you could argue this risks compromising four [key attributes](https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/) of Progressive Web Apps: linkable, discoverable, safe and fresh. I realise using manifest URL as the identifier would mean changing the current behaviour of Chrome desktop, but that seems like a comparatively small price to pay (which @dmurph has already volunteered to take on 😉). -- 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-772551059
Received on Wednesday, 3 February 2021 14:29:57 UTC