- From: Daniel Murphy <notifications@github.com>
- Date: Thu, 25 Feb 2021 19:33:55 -0800
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/786387731@github.com>
> @fabricedesre wrote: > When work started on PWA manifests, I distinctly remember that a disagreement between the Mozilla and Google teams was about how to identify apps and the whole document origin/manifest origin/start url processing. To be honest I still don't understand why the document origin should have a role to play here. We felt that a lot of complexity with little justification was added to the spec. It's good to see that now there is a lot more data from the field to help make decisions. This was before my time :) I kind of see the 'rel' link as the source of truth here - if the start_url document has a `<link rel="manifest" href="manifest.json">` and that manifest is the one we are using, then we are 💯 . For example, if I was running a web app directory and someone submitted a manifest, then I would want to check that the document at start_url had a rel link back to that manifest to verify it. Maybe this doesn't really matter though. > > The new PWA based implementation we do for KaiOS keeps the manifest url as the app id, and in this regard is similar to Chrome for Android. Because of the form factor of our devices (non touch, small screens), we only provide store initiated installs, which means that we have a bit more control over the manifests that are installable. However I find the list of scenari quite interesting for when we'll offer browser initiated installs. I'm not sure I agree that all of them should be supported, but the intent is valid. I think this is also a similar model to how trusted web activities work in the Google Play store - since it is a curated model where the developer uploads their app. > We don't support data: urls for manifests, and have no plans to change that. It looks like instead a service worker could generate them with a "real" url? Yes, but not without developers changing their code / infrastructure :( > > Out of all the proposals in the explainer, I could live with the first one "start_url_origin + specified id". I feel this is reasonable since that doesn't introduce a new global identifier namespace, and provides a fallback for backward compatibility. Ideally, I would use "manifest origin + specified id" instead, but that prevents support of data: urls for manifests. > > Kind of a side question, but do you have data on how often start url has a different origin than the manifest url? Surprisingly I see none in the pwa-directory data, which is weird, as this used to be in there (see the [comment](https://github.com/w3c/manifest/issues/586#issuecomment-386820382) above), and it still has a different origin manifest: [https://www.spokeo.com](https://www.spokeo.com/) There's a chance that these [maybe got filtered out somehow](https://github.com/GoogleChromeLabs/gulliver/blob/17bc9c6199cf683c024658275f28a29b6035f23a/test/app/lib/manifest.js#L45)? Code I tried to find manifests that are not same origin as start_url (warning: I'm bad at jq): ``` curl -sSL 'https://pwa-directory.appspot.com/api/pwa/?limit=4200' | jq -r '.[] | (.manifestUrl | split("/")[2]) + " " + (.absoluteStartUrl | split("/")[2])' | awk '$1 != $2' ``` Maybe someone else can find another directory we can query, or other examples -- 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-786387731
Received on Friday, 26 February 2021 03:34:12 UTC