Design Review #668

#668: Add `id` member to web application manifest spec

Opened Aug 17, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of manifest unique id.

What uniquely identifies a web application is not defined in app manifest specification. This proposes adding an id member to the manifest with details about how it should be utilized during manifest parsing and update.

Explainer¹ (minimally containing user needs and example code): https://github.com/philloooo/pwa-unique-id/blob/main/explainer.md
Specification URL: https://github.com/w3c/manifest/pull/988
Tests: [wpt folder(s), if available] - https://github.com/web-platform-tests/wpt/pull/30409
Security and Privacy self-review²: No security and privacy risks are expected since this doesn't expose any user information.
GitHub repo (if you prefer feedback filed there): https://github.com/philloooo/pwa-unique-id/issues
Primary contacts (and their relationship to the specification):
- [Phillis Tang] (@philloooo), [Google], implementor
- [Daniel Murphy] (@dmurph), [Google], co-implementor
- [Marcos Cáceres] (@marcoscaceres), [W3C], spec editor
Organization(s)/project(s) driving the specification: Google
Key pieces of existing multi-stakeholder review or discussion of this specification: https://github.com/w3c/manifest/issues/586
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://www.chromestatus.com/features/6064014410907648

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: We would like to ship this in Chrome on M96, ideally if we can get reviewed by October it would be great.
The group where the work on this specification is currently being done: Web Applications Working Group
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Web Applications Working Group
Major unresolved issues with or opposition to this specification: none
This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

Discussions

Discussed Sep 1, 2021 (See Github)

set to proposed close

Comment by @philloooo Sep 10, 2021 (See Github)

Hi @kenchris @cynthia I am planning to move to Intent to Ship to blink-dev mid September, do you think if this can be reviewed?

Comment by @cynthia Sep 11, 2021 (See Github)

@philloooo We have this on our agenda for September 14 of our VF2F, so feedback will be provided on that day. Apologies for the delay!

Comment by @cynthia Sep 14, 2021 (See Github)

@kenchris and I looked at this today, and the use-case makes sense. Also, we were very happy to see that you put in a lot of thought for cases like takeover.

There are things that we would like some clarification in the explainer or spec before people start writing posts about this.

What constitutes a valid ID? Anything goes, or does it have to be limited to a specific subset of unicode?
What are good practices for an ID? (e.g. Don't use obvious words, like 'test')

One more thing to clarify - what venue will this end up in? We made an educated guess and assumed Web Apps, but let us know if that is not the case.

Comment by @cynthia Sep 14, 2021 (See Github)

(We think this issue should be closed, but leaving it open so that the OP can reply back.)

Comment by @marcoscaceres Sep 21, 2021 (See Github)

What constitutes a valid ID? Anything goes, or does it have to be limited to a specific subset of unicode?

It goes into the URL parser, so it's determined by the URL spec.

What are good practices for an ID? (e.g. Don't use obvious words, like 'test')

"test" would be fine, I think. The IDs are resolved against the start URL, short strings are actually good.

Things that are bad:

relative URLS "./foo", because you might end up with a new ID for every navigation if the start_url is missing.
URLs like "id": "file://foo" or other remote origins, as those will fail.

Comment by @philloooo Sep 21, 2021 (See Github)

Sorry for the late reply! Relative URLs are fine too because it's resolved against the app's origin. So "abc", "/abc", "./abc", "../abc" all resolves to the same "https://example.com/abc" But it's not the best because it can be misleading.

So we think the best practice is to always specify with a leading slash with a short id that's url path like. eg: "/<myappname>" or "/<short_random_id_string>" I will add a side note to the spec pull request for recommendation

Comment by @marcoscaceres Sep 22, 2021 (See Github)

relative URLS "./foo", because you might end up with a new ID for every navigation if the start_url is missing.

@philloooo pointed out to me that I'd misread this algorithm. The above is solved by always using the origin, which is stable.