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

For KaiOS, the currently released devices uses the Open Web Apps (OWA) manifest from Firefox OS, while the new upcoming major release will use PWA manifests.

Let me talk a bit about the history here - keep in mind this work started in 2011 :)
In OWA, we always used the manifest url as the application id. This is explicit in the API itself, where many operations take the manifest url as the only parameter. I think overall it worked well because this was a very simple model. For instance this allows to manage app updates in a straightforward way: fetch the new manifest, check with etag and/or hash if it changed, and apply the update after verification that the app name hasn't changed to prevent spoofing.
We enforce that start_url is relative to the manifest url, and we don't care about the document url or origin. There is no scope either (we added something similar later for KaiOS though). We partitioned cookies and storage per manifest url, providing something close to the current Firefox containers.

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.

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

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?



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