Re: [w3ctag/design-reviews] TAG review for making app updates more predictable, `update_token` (Issue #1076)

Dp-Goog left a comment (w3ctag/design-reviews#1076)

Hi TAG folks,

Thank you for your feedback. We went back to the drawing board, and came up with a newer design.

> We have reservations about introducing an update_token member for this purpose. This mechanism appears unconventional within the web platform (which values would you expect there?), and there is a risk that developers may overlook the update_token field. Additionally, updating shortcuts seems to be handled differently by various engines: While Chromium-based browsers prompt users with a confirmation dialog for security-critical updates, WebKit appears not to update shortcuts once added to the home screen or dock.

That is understandable, which is why, our proposal is now looking at [changes in the icon urls in the manifest](https://github.com/WICG/manifest-incubations/blob/gh-pages/predictable-app-updating.md#proposal-perform-non-security-sensitive-field-updates-silently-icon-updates-only-when-icon-url-changes-and-security-sensitive-field-updates-are-optional-or-user-agent-mediated). This ensures that developers don't have to specify new fields in the manifest, and can rely on the old image metadata in the manifest to trigger updates themselves. This makes the proposal much simpler, reducing the need for an image difference algorithm and also matches what happens for `Cache-Control: immutable` in the Web Platform. We have also chatted about this extensively with WebKit, and have concluded that the ability to update icon names and icons is a fundamental requirement of an app installed on a platform, thus figuring out a speced way of determining when it happens and doing so is necessary.

> We believe updating app shortcuts and icons after installation must be possible, but there should be a single approach to it. We recommend that you start a broader discussion within the WebApps working group to explore an approach that ideally works across various engines and platforms. The results of this discussion could enhance the Updating the manifest section of the Web App Manifest specification, which currently lacks a detailed description (see https://www.w3.org/TR/appmanifest/#updating).

Agreed, and this is the whole point of the explainer. We plan on specing it [in the manifest update spec](https://www.w3.org/TR/appmanifest/#updating) so that all user agents can implement a similar algorithm. 

> As one possible solution to the issue with CDN re-encodings, we suggest treating icons as Cache-Control: immutable, which means that there is no guarantee that the icon would update unless the URL changes (that would be down to UA choices). This would achieve a similar outcome to your proposal without needing an update_token. The consequence being that authors relying on automatic icon updates would have to be informed about this change, though (as above) that's already uncertain.

We have incorporated this feedback into the new proposal that is in the explainer linked above. We also slightly tweaked the security and privacy questionnaire, changing the answer of [temporary identifiers the feature creates or exposes to the web](https://github.com/WICG/manifest-incubations/blob/gh-pages/predictable-app-updating-security-privacy-questionnaire.md#what-temporary-identifiers-do-the-features-in-this-specification-create-or-expose-to-the-web) to be `N/A`.

Please take another look!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1076#issuecomment-2860286981
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1076/2860286981@github.com>