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/5a73cd62-fb4c-4ab4-a4c5-c564a7dd540fn%40chromium.org.
