Sounds good, thanks for the clarification! On Wednesday, March 18, 2026 at 11:49:54 AM UTC-4 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). 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. One day, the company decides to move the app >>>> to its own dedicated home at 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, 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 could not be migrated to 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/37c5c07c-5731-4d11-9e83-e9a24cb8e323n%40chromium.org.
