4 ms·

> all the files it brought with it or created during runtime are now gone. How would this work with apps that create things that a user would expect to persist

> all the files it brought with it or created during runtime are now gone. How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.? It could have some rule like "let it be if it's in the user home directory" or "only remove stuff in these system directories" but it seems kind of fragile, like what if you use a text editor to create a system config file and then uninstall the text editor?

pstch 7y ago
> How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.? I can't see how it would. Making the uninstall remove all the files created at runtime is the wrong solution to a real problem, which is better solved by forcing all packages to be self-contained and making their installation an idempotent operation. If we're able to do this, there's not much to clean up afterwards, and we ensure there's no privileged malware left (such as Zoom's one) as both the package install scripts and runtime would be able to run unprivileged. I use NixOS, an OS built on Nix, a functional package manager that does this, and being able to set my system to a known state without going through the steps of formatting and reinstalling is really nice.
pishpash 7y ago
Such a system would not allow the application to write to any place outside of its sandbox or a designated user document volume. The system can't be touched. If you want to create a system config file, you are responsible to break the glass and move it and then all bets are off.
- hunter2_ 7y ago
  I can imagine an allowance to "break the glass" within the context of the app so long as the app invokes an obvious-to-the-user common dialog (like the typical file>save / file>open / choose-a-folder), but there would be no "breaking the glass" in an invisible / programmatic manner. That sounds quite nice.
  - layoutIfNeeded 7y ago
    That’s exactly how the macOS AppStore apps work. Your app gets permission only to those files that were intentionally opened by the user via the system open dialog.

pstch 7y ago

> How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.? I can't see how it would. Making the uninstall remove all the files created at runtime is the wrong solution to a real problem, which is better solved by forcing all packages to be self-contained and making their installation an idempotent operation. If we're able to do this, there's not much to clean up afterwards, and we ensure there's no privileged malware left (such as Zoom's one) as both the package install scripts and runtime would be able to run unprivileged. I use NixOS, an OS built on Nix, a functional package manager that does this, and being able to set my system to a known state without going through the steps of formatting and reinstalling is really nice.

pishpash 7y ago

Such a system would not allow the application to write to any place outside of its sandbox or a designated user document volume. The system can't be touched. If you want to create a system config file, you are responsible to break the glass and move it and then all bets are off.

hunter2_ 7y ago
I can imagine an allowance to "break the glass" within the context of the app so long as the app invokes an obvious-to-the-user common dialog (like the typical file>save / file>open / choose-a-folder), but there would be no "breaking the glass" in an invisible / programmatic manner. That sounds quite nice.
- layoutIfNeeded 7y ago
  That’s exactly how the macOS AppStore apps work. Your app gets permission only to those files that were intentionally opened by the user via the system open dialog.