Hacker News Reader

Comment by krono | Hacker News Reader

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.

View on HN

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.

[1]: https://gist.github.com/caldwell/c212119fffd92a1d706c0a9b00f...

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.

> No privileges, no special installation

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.

What are you arguing for actually? Using ChromeOS and never installing a native app?

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.

Agree, Dropbox is another app that asks for admin privileges.

Been using maestral.app for my Dropbox client and it’s been fairly good. (Make sure you backup your Dropbox first as it corrupted my photos library)

‘Corrupted my photos library’

‘Been fairly good’

Those can’t both be true

No prompts to ask for the root password though

Zoom needs a ton of probably admin rights required access for it's features - raw access to mic and camera, screen sharing, remote control, etc.

Nope, that's what the protected resources API is for.

https://developer.apple.com/documentation/bundleresources/in...

Doesn't Zoom predate these by like years?

You never needed root for any of this on macOS.

Even remote control?

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.

So a well behaved app is harder to install by your own standards. Not surprised Zoom skipped that for a more streamlined setup. UX is king

Then Zoom should ask for those permissions, like every other app does. If we make it an admin, we have problems like these.

If the app needs to access a feature, ask for it via the native app, isn't that what phones do? (I think?)

Chrome has to go through the hoops on Mac every time it updates to re-allow it in Privacy Settings for Google Hangouts to work. It's such a pain.

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.

Here's a workaround, it's ridiculous and probably a bug (any Apple SEs in the audience please move along, nothing to see here) but it works:

- Open the "Audio MIDI Setup" app that comes pre-installed with the OS

- Bottom left plus icon > "Create Aggregate Device" and optionally name it

- Add your built-in microphone to this new device by dragging it from the sidebar to the left

- Open your sound settings, and select the aggregate device as your main sound input

After this it should no longer change the main input device when you connect something else.

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.

Sound has worked better for me on Linux than it did on Mac and Windows. Albeit, I haven’t used Windows in 5 years or so.

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.

Even web apps have access to these (when they ask for it)

Reply on news.ycombinator.com