Use case for appuninstall event

[rmacklin]

I found a brief discussion in this issue #417 where an uninstall event was discussed and deemed not useful:

Regarding uninstall, I'm not sure this event makes a lot of sense

• Add installation prompt control flow #417 (comment)

You are probably right that uninstall is not that useful.

• Add installation prompt control flow #417 (comment)

Along a similar line, I found this comment in issue #161:

The architectural model that we've chosen for installable web apps is to not let the developer know if the app is installed or not (they should not care).

• Integration with service workers #161 (comment)

I'd like to offer a counterexample to these opinions, where I think it makes sense for the developer to care if the app is installed, and where an uninstall event would be useful.

Consider an app where private messages are shared between users. Because these messages can be considered sensitive data, the developer may decide it's better not to store these in IndexedDB for "regular" visitors. That way, if a user visited the app on a shared computer (e.g. at a library), their messages wouldn't be visible by another person who later inspected the IndexedDB contents in the browser developer tools. [1]

But when a user installs this app (either manually or in response to an install prompt), that would be a good indicator that the app can enable local data storage in IndexedDB. Users generally know, and even expect, that apps they install can store data locally for offline use. As a result, it seems unlikely that a user would install a web app on a shared computer; they're likely to only do this on more "trusted"/personal devices. In this way, the act of installing the web app can be viewed as the user consenting/opting in to local data storage. Enabling IndexedDB at this time seems natural and safe, and the appinstall event would allow this.

However, when a user uninstalls an app, they expect the data stored by that app to be deleted. An appuninstall event would allow the developer to hook into that event and clear their IndexedDB storage at that time.

[1] ^{Yes, you could consider always storing the sensitive data in IndexedDB, and clearing it when the user logs out. However, I think that would only work if the user physically logs out on that computer. And that's probably not a safe assumption: Some users may have automatic session expiry (which doesn't require them to manually log out), or they may log out via other means (e.g. log back in on another computer and select to "log me out elsewhere"; in these cases the other computer's session would be invalidated, but it would not be possible to clear the leftover IndexedDB storage). So it still seems like not using IndexedDB for "regular" visitors is a reasonable choice from a privacy/security standpoint.}

[valioDOTch]

I don't see why this would be a good use-case.
To solve your your case you could simply use a flag (e.g. on IDB) that indicates whether privacy-sensitive data should be stored in the local IDB or not. Such a flag can then be switched by the user and you can throw your uninstall event yourself.

User clients should could encouraged to offer simpler possibilities to clear any data to end users (in contrast to devs who know how to do just that). However that's not really a web standard thing IMO.

[raucao]

It doesn't get any simpler than automatically detecting an uninstall event. Everything else requires user interaction and additional UI, which has to be explained in this case, and which lets users shoot themselves in the foot, too. Personally, I can definitely understand this use case as described.

[rmacklin]

@valioDOTch, I agree that building something onto the UI could solve this issue. However, I tend to agree with @skddc about that approach adding complexity and confusion for users, particularly because they've become accustomed to the native app lifecycle where uninstalling removes local data.

I've been prototyping a PWA and I brought up this issue to the business lead for the project, and even suggested that (because there's no uninstall event today) we may need to ask users to explicitly opt into/out of local data storage, and he was very strongly against it for the same reasons (going so far as to say PWAs may not be viable for this yet, which I personally wouldn't conclude).

I think the biggest issue here is the mismatch with the native app model. If one of the goals of PWAs is to be pretty much indistinguishable from native apps to most users, this seems like an issue that warrants some thought.

[marcoscaceres]

However, I tend to agree with @skddc about that approach adding complexity and confusion for users, particularly because they've become accustomed to the native app lifecycle where uninstalling removes local data.

Regarding the event, I don't think spinning up the PWA to fire the event is appropriate.

Maybe the spec should say that, upon "uninstalling" (OS specific definition of whatever that means), the user agent must "clear persistent buckets" as per Web Storage spec. What's the new HTTP Header that was proposed to do that? Basically we could behave the same way here. That way, we don't need the event. The browser just does the right thing, which is purge locally stored data, as if the use had cleared site data manually.

[mgiuca]

I tend to agree that if the user is uninstalling an app, we shouldn't run code in that app.

User agents can purge the local data for an app being uninstalled (possibly having a checkbox in the uninstall prompt to also remove local data). This can be done without any standards change.

[marcoscaceres]

User agents can purge the local data for an app being uninstalled (possibly having a checkbox in the uninstall prompt to also remove local data). This can be done without any standards change.

Agree. We should probably mention something in a Priv/Sec section tho... as clearly, it's not something that all UAs are doing. It might be a current OS limitation tho, as I don't think Android was notifying the browser that an icon it added to the homescreen was removed by the user... this might have changed, but dunno.

[mgiuca]

It might have changed with WebAPKs, but I'm not sure.

Either way, this shouldn't be a requirement, but could be a recommendation.

[tomayac]

This just came up in a discussion with @surma:

1.) Install Twitter PWA (as a WebAPK).
2.) Use it, activate push notifications, etc.
3.) Uninstall Twitter PWA.
4.) Continue to get push notifications.

While notification permission and Service Worker installation are orthogonal, especially in the case of WebAPKs it feels unintended that one would continue to receive notifications.

Probably it would make sense to combine default behavior described above by @marcoscaceres with customizable cleanup (or maybe tracking?) actions.

[rmacklin]

@tomayac Thanks for your input - I agree that feels like undesired behavior. I still see these kinds of issues as a potential source of confusion for new PWA users, so hopefully we can come up with a solution.

[mgiuca]

I added a little section (in a PR): #678

[marcoscaceres]

Closed also via #836, as the eventing model has moved out of the spec.

[rmacklin]

Thanks. Discussion can be continued in a new issue in https://github.com/WICG/beforeinstallprompt

[mgiuca]

Done: WICG/manifest-incubations#4