They are basically solving a self-inflicted problem. The real issue there is the fact that macOS doesn't provide a standarized way to completely uninstall an app.
I would say that what Zoom did was have their app intentionally install malware that bypassed this normal uninstall.
I do think that it would be great to have a more thoroughly sandboxed idea of what an “app” is on the desktop, though.
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.
> 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.
This is correct, but such a package should not make it into the distribution's package repositories.
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?
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.
Does the ZoomOpener app have malicious intentions towards you, your computing resources, or your data? Not just “could it be unintentionally exploited” - note the unintentionality! - but specifically “this was intended to harm”.
If not, then you need to reconsider your use of the word “malware” - a word shortened from “malicious software” - and find a better way to describe software design patterns that aren’t compatible with “drag it to the trash” but also aren’t intended to harm.
Adobe Creative Cloud, any $$$$ audio software DRM, and HP printer drivers all use similar patterns of “can’t just drag it to the trash”, and are all similarly annoying to remove - but they are not malware, any more than this ZoomOpener is.
And Windows does? Uninstallers are completely at the behest of application developers. No consumer OS but iOS actually provides any sort of true app level sandboxing.
Control Panel “add and remove programs” usually works?
There’s no equivalent on Mac. Yes, dragging the app to the trash is a thing but that leaves behind content in ~/Library/caches, ~/Library/Application Support, and ~/Library/Preferences . It’s been somewhat of an issue with Mac ever since they first put a hard drive on the original ones back in the 80s...
Edit: I literally cleared several GB of junk out of my application support folder left behind by just one app today, so it’s fresh on my mind. OmniDiskSweeper is great for finding this stuff.
All that does is launch the app’s uninstall process. The app is free to leave whatever crap it wants to on your system.
And why is it filled with stuff from Apple programs?
Citation needed. That was the case in the 90s, these days most apps (device drivers aside) uninstall fairly cleanly with only settings/configurations stored in the registry still resident afterwards. Startup programs remaining after an uninstall is straight-up a bug.
Citation needed.
Instead an installer is driven by a number of "database" tables that specify the installer actions in a declarative way.
There are several benefits to this approach. The declarative actions are reversible and the uninstall actions can thus be inferred automatically. This removes the burden on install authors to create a script to reverse the install operations.
This includes registering services/daemons (will unregister on uninstall), registering protocol handlers, filetype/program associations, desktop shortcuts etc.
The declarative approach also allows the installer to roll back in case of an error during installation. This even includes "undeleting" files that were deleted. (https://docs.microsoft.com/en-us/windows/win32/msi/rollback-...)
The author of the install script can (non-Store installers) escape and execute a specific program during the install process. This is rarely needed, though. So the default is that the uninstaller will uninstall by completely reversing the install actions.
https://docs.microsoft.com/en-us/windows/win32/msi/windows-i...
Also, Add/Remove only works if the program adds itself there. And remove only works if the program added an uninstaller. Also, even then, it still leaves crap behind.
iTrash [1] is also worth mentioning. It uses the Levenshtein distance algorithm [2] to find all of the junk related to an app.
What do you think about this one?
Zoom is even available in Flathub, and that's how I use it.
Android does, too.
I mean, maybe you need a "user data" bundle of sorts tied to the specific application. If you delete the app, it deletes all the user data bundles as well.
The default installer and bundle runners should be controlling the process. "XYZ App is attempting to write data files outside of its bundle location. These may not be cleaned up if you delete the application. Do you want to continue?"
The unix permissions system and the Mac bundle format should completely solve this problem. I honestly just don't get why this still happens. Doesn't iOS at least get this right?
There is already a concept of a "user data" directory for the app, which is determined just like on iOS. There are also other directories for things like caches that the system can clear if it's low on disk space.
Of course they could sandbox Mac apps just like on iOS, and Mac App Store apps essentially already work that way.
I can assure you, though, that any barrier they put in the way of letting non-App Store apps run however they always have will be met by strong resistance. It's easy to point to this occurrence with Zoom and call it unreasonable, but prompts like what you're describing will undoubtedly disrupt what other people see as totally valid use cases and ruining of the UX.
[1] By "things", I mean things like a separate web server process. Apps do store files in app-specific folders like "Application Support" by convention, but not for separate processes.
But what I don't get, why even have an "Application Support" directory at all. There is absolutely nothing of value added to me (as a user) to have files stored there. It's just one more place I have to look to clean up after an application is deleted. So dumb and adds zero value.
I'll put my files into Documents (or whatever). And you (as an application developer) put your files in your app bundle directory. That should be the contract for most (all?) user space applications.
I agree my prompt idea is generally poor and wouldn't work, it was mostly just for discussion purposes. But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.
The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support").
That would include mostly anything the app persists to disk that the user didn't explicitly choose, like an sqlite database or something.
> But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.
I see where you're coming from, but I think this is really the only balance Apple can strike here. That balance is essentially that non-App Store apps/installers are not sandboxed and can mostly do whatever they want, but Apple can step in with X-Protect (like they did here) and remove anything egregious.
They've also moved forward recently with the concept of notarizing, which will still allow apps/installers to do whatever they want, but they'll at least need to be validly signed by a verifiable private key that Apple can then revoke if you (as the developer who signed things with it) do anything egregious.
Again--it seems unreasonable in this case, but there are undoubtedly numerous very popular unsandboxed Mac apps that do sketchier things for more valid use cases. Any prompts or restrictions are going to be very disruptive and prompt a new wave of blog and HN posts about Apple trying to kill app distribution outside the App Stores.
> The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support").
I don't buy this. If you are writing "anything at all" into Application Support, this is no different than writing to the bundle. An executable binary written into Application Support is just as effectively the same thing as an executable binary written into the bundle itself. I don't see a difference between a program rewriting its own code vs. writing an executable into another location.
There's no added security and no added user value to writing into Application Support vs. the App Bundle itself.
Not arguing with you, I appreciate you explaining the current state and conventions. Thanks for the discussion.
/Applications/SomeApp.app/users/taftster/user.specific.data
/Users/taftster/Library/Application Support/SomeApp/user.specific.data
And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.
By design choice user data of any App should be only be readable and modifiable by the active user. If user data is stored somewhere under home folder, this mechanism comes for free for the App developer and the OS handle it. If you want that same level of privacy in the App Bundle developers would have to handle it themselves (and well).
But then what happen when you uninstall ? Either you are blocked because you can’t remove data from another user or you somehow require escalation to admin privileges to remove data of all users at once. Which might or might not make other users happy if they were unaware of the uninstall...
With current data model choice (pretty much shared across all UNIX world and even Windows). If user A delete the App but user B still needed it you just have to reinstall to keep user B unharmed.
Your proposal is not bad to optimize for disk space gain at removal, it just happen that (quite rightfully) OS vendors chooses to rather optimize for data persistence and security.
This doesn't work well for a few reasons:
- The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app.
- Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image.
- If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk.
- It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature.
- If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two.
- If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.)
> And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well.
Do you?
- What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle.
- What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data.
- Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters.
Applications should be treated as hostile, just like a user is treated in a multi-user system.
I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out.
I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem.
In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download.
It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.
However, the OS should perhaps insist on a particular location within "Application Support/" that each app can write to, and when the application bundle is deleted, provide a way to delete those support files as well, either for that user alone or for all users within permission (can be a system-wide configuration).
Your second paragraph though is probably closer to a realistic solution. That is, the OS provisions an Application Support directory and restricts the application to using it exclusively. Any application uninstalls can (via admin prompting or configuration settings) then also delete the support directories as well.
As an application developer, I want to be able to drop a new bundle over the old version and NOT LOSE ANY USER DATA. The only way to do that is separate them completely.
- You want to uninstall/re-install an app without removing the application's data - The application's data can become large (think raw audio or video libraries) and users request to store it in a separate disk - Users want to personally organize the data they make with your app (by project, client, personal/work, etc.), or use it with other apps - Your "installer" is just a zip of the .app bundle and there is no obvious opportunity to assume admin privileges make the bundle writeable
Most of these could be solved by having a separate "sandbox" a la iOS or MAS that can be moved or, at the user's option, remain on disk when uninstalling; as far as I know neither system offers these capabilities.
For example, Steam games stored in Application Support. Why?? If I install a game from Steam, it should be installed somewhere in the Steam app bundle. When I delete the Steam app, I delete everything related. So dumb.
They clearly could have made other choices and they have their own logic, but that clearly not on Apple role to oversight how their concurrents operate.
Antitrust, geeks and media network would instantly gather pitchforks to run on Apple if they even dare to hypothetically mention it.
If you uninstall a .deb or .rpm or AppImage, the files you wrote into XDG_CONFIG_HOME (defaults to ~/.config) won't magically get cleaned up.
I'd love to be wrong here, BTW! I've had several PhotoStructure users try to reset their configuration by uninstall/reinstall, but that just removes the files in the installer, it doesn't do anything to files in user directories (and I'd be really surprised if that was ever a thing). Can you imagine the havoc from `apt remove vscode` and having it remove user's keybindings, extensions, and anything else?
Isn't this what apt purge appname does ? or is something missing
Form the apt-get docs:
purge - purge is identical to remove except that packages are removed and purged (any configuration files are deleted too).
If you do that, the entire system stops working. Everyone will just click "ok" and then still gets mad when uninstalling doesn't fully clean things up.
Maybe the app bundle runner should be logging files written outside of the bundle folder? Then the uninstall process will wipe those out?
Not even Apple follows that ideology though, I can't be the only one who has had to delete the gigs of Garageband data from ~/Library/Application Support on an under-specced company laptop 128GB SSD
If we are talking about OS updates, OSX has the same thing.
You are not required to use Windows Installer. And even if you do, you are not guaranteed that everything will be removed, be it due to malice or incompetence.
Not even Linux can guarantee that. Something like the Nix package manager would be closer to what's required. Plus a sandbox.
> This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enables users to avoid this extra click before joining every meeting.
https://blog.zoom.us/wordpress/2019/07/08/response-to-video-...
Edit: Once you consider social sites with user-submitted content, like reddit, it might be best if you’re prompted every time.
So I think you could argue Apple might want to let you override that, I don't know what the language is and whether there's a "click here to skip this next time" box on the dialogue. It's possible they got the annoyance versus security tradeoff wrong.
But imho they didn't break the correct behavior any more than Microsoft "broke the correct behavior" of privilege escalation by adding a dialogue box with UAC in Windows 7 .
well, it did a shitton didn't it ? to this day, most people I know disable UAC because of how annyoing it is.
I've been out of the MacOS app dev scene for too long, it seems.
The developers in this case didn't bother trying to use it.