Nothing good has ever come from apps that required admin privileges to install for no obvious reason. They either abuse the rights, or end up with massive security holes that are completely neglected for months or longer.
It's frustrating because the App absolutely doesn't need it. I use the native .app, but I've never run their installer. Instead you can just unpack it using command line tools (I even wrote a script to do this [1]) and… it runs just fine! No privileges, no special installation. As best I can tell, the installer is there to install a bunch of ancillary nonsense.
I did one other thing when I discovered their app auto installing a launchd auto-update service:
rm -rf ~/.zoomus
sudo touch ~/.zoomus
This makes a file with root permissions where they hide their auto-update script directory. This causes their code to (silently) err out and viola, no more launchd junk.
A lot of software has moved from using dmgs to mpkgs, and apart from some terribly written apps that need some hackery in PostInstall scripts, most of them don’t really care about it.
The UX for packages also sucks. With DMGs you just mount and then drag to the Applications folder… even the most basic macOS users have done this.
It still has way, way more privileges than a webapp. And arguably, if you have all your valuable information in a single user account, it has the crown jewels already, no admin needed.
Indeed, it's crazy that some OSes even make this the default way of installing applications (i.e., become admin -> then install)
E.g. Unix was built around the idea that other users should not be trusted but applications can be trusted; it is becoming painfully clear that this idea is wrong.
The one thing that has come of this is that products that do this have 0.5% less friction (they can auto-update quicker), achieved this faster and with less engineering effort (no need for a clever workaround, just use the biggest hammer), and have 0.5% less customer support burden (since everyone is on the latest version all the time). As a result, this can help a product dominate their competition the way Zoom has. I say this as a security conscious person who wishes this type of app would just go away, but has worked in the industry long enough to understand the economic realities.
Honestly, this is the number 1 confounding factor for me in terms of the “app stores should be more open” argument. Sure, Apple is stifling innovation in phone applications by disallowing this type of thing, but also the Zoom app is much better behaved on iPhone because it has to be. Personally I am happy trading off some convenience for security, but I am unsure if there is a “correct” answer here. My personal hope is that VMs will become useful enough that it will become viable to have a crude per-shitty-application sandbox for folks that are security conscious. I already have done this with tools like docker from time to time, which admittedly isn’t a great experience.
Even remote control, or, in general, input interception/injection. That's done via accessibility APIs I believe, and these do need to be enabled once per app in the system preferences, and this does require root password or touch id, but a well-behaved app would not bypass that. A well-behaved app would guide you through granting it this permission in a supported way.
The only thing I can think of that Zoom needs root for is its (very helpful!) offer to restart Mac's audio subsystem when it crashes (which it does fairly regularly in my experience).
That said, it could just ask for your password at the time.
I thought the audio subsystem in Mac OS was the best of the bunch (Windows, Mac, and Linux). At least that's what I was told by my old audio geek friends that swore by Mac OS. Why would a video chat app need to be regularly restarting a crashed subsystem? Also, even if the subsystem crashed why wouldn't launchd or the kernel take care of restarting it?
Idk about latency but UX wise it has some weird limitations - you can't mark an external audio jack connected device as input or output only, with the weird result that when i connect my external microphone it considers it an output too, and automatically switches to it as output too, which of course doesn't work. Windows and Linux ask me what did i just connect and adapt accordingly.
It might be better in terms of latency (I have no idea) but it's way buggier than Windows'. Crashes all the time for me. Plus it has some stupid missing features like volume control isn't implemented for HDMI audio (it is on Windows) and you can't capture the audio output - at least without fairly extreme hacks. It's a lot easier on Windows.
I haven't used sound on Linux for a long time but when I did it was in a completely different league to Mac and Windows - in a bad way.
> I haven't used sound on Linux for a long time but when I did it was in a completely different league to Mac and Windows - in a bad way.
I am not a sound engineer. I don't do music composition. I am simply a user who wants things to work.
Sound hasn't been an issue for me in Linux (as a user) for a long time. There was a period when the audio system was replaced with Pulse, which was terrible as they published Beta software to end users, but that quickly fixed itself and we are talking 20 years ago. Linux audio has been by far the best for usability for me.
I also understand that the latency issue has been dramatically improved over the decades with the current situation with Pipewire being excellent. If it has been a long time since you have used Linux sound, then just be aware that it is not the same as it was.
My Mac refusing to adjust the volume via HDMI I assumed was a feature to push towards buying an Apple display.
It is the best, it's low latency and very stable contrary to Windows shitty high latency direct sound API which is a complete mess. So much that Steinberg had to develop some respectable universal audio drivers for windows called ASIO, Microsoft never cared about the issue.
