Re: [w3ctag/design-reviews] Incubation: PWA (same-site) Origin Migration (Issue #1164)

mkruisselbrink left a comment (w3ctag/design-reviews#1164)

Thank you for the review. https://github.com/WICG/manifest-incubations/pull/135 updates the explainer, to try to address several of your concerns. Below are our specific responses to your feedback:

> We believe that the proposal, in its current form, is based on assumptions and specifications that don’t seem to have cross-vendor consensus. For example, web apps can also be installed without a manifest and, thus, without an explicit ID (i.e., it will get a computed one based on the rules set forth in the spec). Acknowledging the "ID footgun," we ask you to discuss this restriction (which would _only_ apply to migrations) with the other vendors in the Web Apps WG.

Personally I don't feel strongly about the ID requirement, I'd be happy to drop it if that is the consensus of the Web Apps WG; I'll reach out. However, it is important to note that the proposal does not require an explicit ID for the app being migrated _from_; it explicitly supports migrating away from manifest-less web applications.

The ID requirement applies only to the destination app. Since the destination must provide a manifest to declare `migrate_from`, requiring an explicit `id` there does not significantly increase the burden on web developers, and ensures a stable identity for  the new PWA from the start without imposing new constraints on existing legacy apps.

> The URL used for the handshake reuses the location from Scope Extensions, which also does not have cross-vendor support.

This is a fair point, though we note that neither [Mozilla](https://github.com/mozilla/standards-positions/issues/904) nor [WebKit](https://github.com/WebKit/standards-positions/issues/265) have expressed a position on Scope Extensions yet. I'm not sure if the lack of a position is the same as lack of support (although it certainly isn't a signal of actual support).

From a practical standpoint, partners interested in migration often require Scope Extensions as well, so reusing the file location felt natural. Architecturally, we view the  .well-known/web-app-origin-association file as a shared configuration resource. A user agent can implement the migration handshake without implementing any logic related to Scope Extensions.

> Regarding permissions, we recommend _not_ migrating any existing permissions. Denying a permission as part of the migration after it was previously granted by a user seems problematic for user experience. We understand that this could be an inconvenience for users, but doing permission migration might lead to more confusion and complexity.
  
We agree. Following further discussion with our partners and your feedback, we have removed permission migration from the initial proposal.

> Also, we are unsure if developers should be able to choose between the `"force"` and `"suggest"` update modes. Would developers not want to `"force"` an update in the default case? However, in that case, they would only be allowed to change the URL during the migration, and might not be able to perform the branding update in the same step.

We believe the distinction is valuable. For rebranding or architecture changes where the old endpoint remains functional, developers may prefer a "gentle" transition (Suggest) rather than a hard block (Force).

Ultimately, the `behavior` field is a signal to the User Agent. UAs retain discretion on how to present the update. If "force" behavior becomes the de-facto standard for all migrations, the field can be deprecated later without breaking anything. User Agents should always feel free to provide whatever UX makes sense to them, ignoring the `behavior` field if that seems the right choice to them.

> We would like you to consider an HTTP redirect as an alternative. This approach is not bound to manifests, and might be a little more versatile. For example, this could be limited to 301 Moved Permanently (i.e., `"force"` update mode), require appropriate headers to be set in the request and/or response (similar to CORS), or a redirect with a certain JSON payload that might give instructions on how to migrate permissions and data.

Redirects are a valid trigger for discovery, but they do not cover the full scope of App Identity migration.
 
Relying solely on HTTP redirects would prevent migrations where the URL does not change. For example, a developer might have accidentally (or intentionally) created multiple PWA installations on the same origin (e.g., via different start_url paths) and now wishes to consolidate them into a single identity. In this "Split App" scenario, there is no HTTP redirect because the paths remain valid; only the manifest identity is changing.

Therefore, while UAs should be able to use redirects as a signal to fetch a new manifest, the manifest-based handshake is necessary to handle the full range of identity migration scenarios, including those on the same origin.


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

Message ID: <w3ctag/design-reviews/issues/1164/3887786472@github.com>