LGTM2
On 3/18/26 11:49 a.m., Marijn Kruisselbrink wrote:
The migration does not effect the state of any storage, so yes if a
site wishes to transfer cookies or other state they'd have to do so
themselves (since migration is limited to same-site cases I believe
you could use an iframe or similar to access the old state from the
new page or vice versa).
Marijn
On Wed, Mar 18, 2026 at 8:25 AM Vladimir Levin <[email protected]>
wrote:
Hey,
I was wondering if the same-origin cookies are lost during this
migration? I couldn't find anything relevant mentioned in the
explainer
Thanks,
Vlad
On Wednesday, March 18, 2026 at 11:20:57 AM UTC-4 Alex Russell wrote:
An enthusiastic LGTM1; thank you for getting this done!
On Monday, March 16, 2026 at 4:56:39 PM UTC-7 Chromestatus wrote:
*Contact emails*
[email protected], [email protected],
[email protected], [email protected]
*Explainer*
https://github.com/WICG/manifest-incubations/blob/gh-pages/pwa-migration-explainer.md
*Specification*
https://github.com/WICG/manifest-incubations/pull/136
*Summary*
When a user installs a Progressive Web App (PWA), its
identity and security context are tightly bound to its web
origin (e.g., app.example.com <https://app.example.com>).
This presents a significant challenge for developers who
need to change their PWA's origin due to rebranding,
domain restructuring, or technical re-architecture.
Currently, such a change forces users to manually
uninstall the old app and reinstall the new one, leading
to a disruptive experience and potential user loss. This
proposal introduces a mechanism for developers to
seamlessly migrate an installed PWA to a new, same-site
origin, preserving user trust and permissions.
Administrator force-install policy will block migration.
Since enterprise policies around web applications are
primarily based on URLs and origins, there is a risk that
a migration would bypass certain policies an admin might
have configured. As such no migration will be offered to
the user when an app is force-installed by their
enterprise administrator, and instead a banner will be
shown explaining this to the user.
*Blink component*
UI>Browser>WebAppInstalls
<https://issues.chromium.org/issues?q=customfield1222907:%22UI%3EBrowser%3EWebAppInstalls%22>
*Web Feature ID*
manifest <https://webstatus.dev/features/manifest>
*Motivation*
Imagine you have the "SocialApp" app installed on your
computer from www.example.com/social
<https://www.example.com/social>. One day, the company
decides to move the app to its own dedicated home at
social.example.com <https://social.example.com>. Without a
migration mechanism, the app you have installed would
either break or redirect you to the new site in a generic
browser window, losing its app-like feel. You would have
to figure out that you need to uninstall the old app and
install the new one from the new address. You might also
lose your settings, like whether you've allowed the app to
send notifications. This feature aims to make that
transition seamless. Instead of a broken experience, the
app would notify you of an available update. With your
approval, the app would relaunch from its new home at
social.example.com <https://social.example.com>, with your
notification settings intact.
*Initial public proposal*
https://github.com/WICG/manifest-incubations/pull/121
*Search tags*
app migration <http:///features#tags:app%20migration>,
manifest update <http:///features#tags:manifest%20update>
*TAG review*
https://github.com/w3ctag/design-reviews/issues/1164
*TAG review status*
Pending
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
By its nature, this is a feature that a site might use for
some amount of time while migrating their Web Applications
to a different origin, but where longtime usage by any
particular site is unlikely, as the whole purpose of this
feature is to get users away from sites that use this
feature. As such, the risks around making breaking changes
in the future are significantly lower than for other web
platform features. This is not a feature any website will
rely on long term, instead at different points in time
different websites can make use of it.
/Gecko/: No
signal (https://github.com/mozilla/standards-positions/issues/1313)
/WebKit/: No
signal (https://github.com/WebKit/standards-positions/issues/568)
/Web developers/: No signals
/Other signals/:
*Ergonomics*
One common way this API is likely to be used is in
combination with Scope Extensions and HTTP redirects (by
redirecting the old app to the new location, while using
Scope Extensions to treat the new location in scope for
the old app). As such we designed this API explicitly to
work well in that situation. Usage of this API should not
have any effect on Chrome performance, it is merely a
signal to Chrome to display UI to the user to allow
migration of the Web Application.
*Activation*
We are planning on either adding new documentation or
updating the existing manifest updating docs to mention
this new feature, to help educate developers about this
feature. Besides that usage of this feature shouldn't be
particularly challenging for developers, as long as they
have the ability to host the
.well-known/web-app-origin-associations file on the origin
they are migrating away from.
*Security*
The primary security threat is a hostile takeover, where a
malicious actor could try to migrate a legitimate PWA to a
phishing site. The same-site restriction is the critical
defense here. Since an attacker cannot control a different
eTLD+1, they cannot hijack a PWA. For example, example.com
<https://example.com> could not be migrated to
evil-phishing-site.com <https://evil-phishing-site.com>.
In addition the old origin needs to explicitly allow
migrations to the new location via its
.well-known/web-app-origin-association file.
*WebView application risks*
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
/No information provided/
*Debuggability*
The existing DevTools support for the manifest will show
any parsing or validation errors around these new
migration related manifest fields.
*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android
WebView)?*
No
This feature is currently only targeting desktop
platforms. While Android does have support for PWAs,
installation and update mechanisms are very different from
what is done on desktop platforms, where implementing this
feature would possibly require changes at a much lower level.
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
No
There is no web exposed effect of usage of this API, as
such there isn't much that makes sense to test using Web
Platform Tests. It would be nice however to at least have
web platform tests for the manifest parsing/processing
steps, but that requires a feature such as
https://github.com/w3c/manifest/issues/1179 so a test can
read back the processed manifest.
*DevTrial instructions*
https://googlechrome.github.io/samples/pwa-migration
*Flag name on about://flags*
chrome://flags/#web-app-migration-api
*Finch feature name*
WebAppMigrationApi
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
True
*Tracking bug*
https://issues.chromium.org/396504527
*Launch bug*
https://launch.corp.google.com/launch/4453101
*Measurement*
We will measure both the presence of these new manifest
fields in manifests, as well as activation of the
migration by users.
*Estimated milestones*
Shipping on desktop 148
DevTrial on desktop 147
*Anticipated spec changes*
Open questions about a feature may be a source of future
web compat or interop issues. Please list open issues
(e.g. links to known github issues in the project for the
feature specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure
of the API in a non-backward-compatible way).
/No information provided/
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5123349239955456?gate=5094079474040832
*Links to previous Intent discussions*
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6903a614.050a0220.56be2.0983.GAE%40google.com
This intent message was generated by Chrome Platform
Status <https://chromestatus.com>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVahfw-5mQCcbWsOTBq6B9r94_tseO2BMWeJc6%2BDFtiF%2BA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVahfw-5mQCcbWsOTBq6B9r94_tseO2BMWeJc6%2BDFtiF%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2db80252-01c7-42a0-91a7-bb4a9242cd6b%40chromium.org.
