Re: [w3c/manifest] user initiated 'uninstall' event (#1201)

marcoscaceres left a comment (w3c/manifest#1201)

Proposing we close this.

The underlying problems are real and worth stating plainly: uninstalling a PWA can leave the service worker, caches, storage, and (worst of all) an active push subscription behind, so a user can keep getting notifications from an app they thought they removed. There is also no friendly way to reclaim that storage. Those are genuine bugs.

But firing a site-observable "uninstall" event into the service worker is the wrong fix, and mostly a privacy and user-agency problem:

- Uninstalling is a private decision between the user and the OS/user agent. The site has no legitimate claim to be told it is being removed. (This was already the concern raised earlier in this thread.)
- Notifying a server on uninstall hands sites a perfect, timestamped abandonment signal and enables out-of-band re-engagement: "why did you uninstall our app?" emails, or cross-device win-back campaigns, the moment the user walks away. That is harassment facilitated by a browser API.
- The proposed ability to *decline* an uninstall is straightforwardly hostile. User agency over removal must be absolute; a site veto is malware behaviour.
- The proposed ability to *prompt* during uninstall is a dark pattern (the "wait, here is 10% off!" hostage dialog). If uninstalling a PWA became a guilt-trip gauntlet, people would just stop installing PWAs.
- Install and uninstall are not symmetric. The install-side event (`appinstalled`) fires when a user invites the site in; uninstall is the user ending the relationship. An install event does not justify exposing its reverse.
- It cannot fire reliably anyway. The OS often removes the app (via native settings, or automatically under storage pressure) without giving the browser a chance to wake the service worker. A cleanup mechanism that only sometimes runs is not one, and queuing "notify" telemetry for later would mean the browser keeps a hidden record of an app the user asked to wipe.
- It runs counter to where the platform is going: running arbitrary JS during teardown is already discouraged and unreliable (`unload` is bfcache-incompatible and, in Chrome, no longer fired on navigation). A higher-stakes teardown event goes the wrong way.
- Second-order: it normalises "apps get to observe and react to their own removal", adds a fingerprinting/telemetry surface, and sets a precedent for other removal surfaces (clearing site data, permission revocation) becoming site-observable.

The legitimate needs are all *cleanup*, not *code execution*, and are better solved by the user agent without exposing anything to the site:

- On uninstall, the UA should unregister the service worker, drop the push subscription, and clear app-scoped storage (an "also delete site data" affordance in the uninstall flow, or simply the default for app-scoped profiles). This kills the zombie-notification bug: once the subscription is gone, the app server's next push is rejected by the push service (a 404 per the Web Push protocol), with no site code involved.
- Declarative storage lifecycle (e.g. storage buckets with eager deletion) lets developers mark app assets for automatic removal on uninstall while leaving user documents intact.

Both were already suggested in this thread, and neither needs a manifest-level uninstall event. Given the privacy cost, and that the real bugs live in service-worker/push/storage lifecycle rather than in the manifest, I think this should be closed here and the cleanup behaviour pursued as UA-driven data clearing. Happy to point to the right follow-ups if useful.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1201#issuecomment-5064539422
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1201/5064539422@github.com>