4 ms·

Snapd, flatpak, appimage all can do this on Linux. Even docker/singularity can sort of do the same for some, if you pass through all the necessary devices and s

Snapd, flatpak, appimage all can do this on Linux. Even docker/singularity can sort of do the same for some, if you pass through all the necessary devices and sockets from the host. When you remove the app (or container) all the files it brought with it or created during runtime are now gone. Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled. The downside to these is they don't track files created at runtime so a lot of the config or cache files created can be left over if the package itself doesn't remove them.

tomjakubowski 7y ago
A sandboxed macOS app would offer similar protections as what snapd, flatpak, etc provide on Linux. > Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled. Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans.
- jxcl 7y ago
  > Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans. This is correct, but such a package should not make it into the distribution's package repositories.
  - Twisell 7y ago
    And likewise Zoom didn’t make it to the AppStore...
hunter2_ 7y ago
> 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.
Rapzid 7y ago
The install scripts in rpm/deb can do all sorts of stuff that doesn't get tracked/reversed. There are package linters to help detect some of this buts it's largely a faith based endeavor either way.

tomjakubowski 7y ago

A sandboxed macOS app would offer similar protections as what snapd, flatpak, etc provide on Linux. > Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled. Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans.

jxcl 7y ago
> Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans. This is correct, but such a package should not make it into the distribution's package repositories.
- Twisell 7y ago
  And likewise Zoom didn’t make it to the AppStore...

hunter2_ 7y ago

> 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.

Rapzid 7y ago

The install scripts in rpm/deb can do all sorts of stuff that doesn't get tracked/reversed. There are package linters to help detect some of this buts it's largely a faith based endeavor either way.