Tell HN: Cisco WebEx on OS X uses the same pre-installer tricks as Zoom

The founder of Zoom used to work at WebEx before it was acquired. Wouldn’t be surprised if he brought along some WebEx folks as well.

Is it officially considered malware by apple? If so… feds don’t screw about. Those guys could be in serious trouble.

the founder of zoom brought tons of people from WebEx (know someone who was part of the early webex team and now zoom)

Having to download a separate uninstaller or having complicated uninstallation instructions does not in any way, shape, or form indicate there’s anything funny going on with the pkg installer. Any pkg installer (or any app bundle, if you want to completely remove all traces of it) would require a separate uninstaller to install, and any pkg installing to multiple directories will be complicated to uninstall, not even considering user data. lsbom | xargs rm is about as close as a native uninstallation method, but you will have user data and possibly things like launch agents left behind.

The uninstallation page basically describes how to completely uninstall any nontrivial Mac application.

I believe this is not hard to detect. Apple should detect this and report such an installer as particularly risky. Chances are the majority of installers working this way actually are malware, legitimate apps like Zoom and WebEx probably are exceptions.

>>> Malware on macOS isn’t prevalent.

I’d beg to differ on that. If anything, I’d bet MacOS is now be the platform with the most malware (adware specifically).

I’ve had to check laptops from wife and step family (all apple users) in the past year and they all turned out to be infected with a truckload of mac adware, that they only noticed after it replaced their homepage browser or spammed unending popups on the desktop.

While browsing for help on safari, pages were filled with ads and popups trying to send you more malware. That is, when pages are not right away sending you some executable files (just like pages sending you .apk on android devices). MacOS is as unsafe as everything else nowadays.

> the usability of macOS software installation is terrible and no, the App Store is not an acceptable alternative. macOS software install UX is worse than Windows. It’s worse than Android and iOS. It’s better than Linux but that doesn’t say much.

Sounds questionable in all the parts.

Mac: Just click-mount an installation disk image and drag an app icon to the Applicationss folder – isn’t this a perfect install UX? If an app installed this way wants to handle some URLs it should declare that in its metadata. No app should be allowed to modify files outside its dedicated directories unless modifying those files is its actual mission.

Linux: just type “sudo apt install app_name” – what can be more handy?

Windows: let every app you install do anything it wants with all the system files, leaving traces after uninstallation is a norm.

The only problems with iOS are it removes a user’s right to program his own device freely and demands too much money from 3rd party devs.

> 1. Genuine one or two-click install of software from the web, without the App Store being involved and without requiring sandboxing

I disagree with this. Why is going via the app store a bad thing? The app store is the solution here. Zoom should be able to tell apple “Hey I’d like to handle zoom://” links, and clicking one will redirect you to either zoom or the app store (without the source of your link knowing where you ended up), where you can have a one click install.

I also firmly disagree with the concept that sandboxing shouldn’t be enforced. There is _no_ reason for any software (particularly software like Zoom, Webex, Slack) to have unfettered access to my machine,

Why do these apps require installers at all? What are they installing—presumably any of their proprietary tech can run in userspace unprivileged.

Personally, my best guess is because that’s the flow the product manager expected.

It seems unnecessary for core functionality at least — I installed Zoom by unpacking the .app from the .pkg by hand (without running any installer scripts) and it works fine.

Mind throwing me the name of or link to the program you used to unpack the .app? I’d like to do that myself, and remember stumbling on a program that did that, but can’t recall the name.

7-Zip, now there’s a fantastic piece of software. It opens damn near everything, has an ultra-lightweight interface and doesn’t have any near-malicious money grubbing schemes.

Another reason could be to ensure that you have at most one copy of the application ever, since you can force it to install stuff always at the same location.

On an unrelated product we learned that users ended up with many different copies of the app scattered throughout the system, if they were allowed to use the traditional bundle + DMG distribution method.
Spotlight would then helpfully pick one random copy, with obvious consequences wrt. project file versioning.
That is despite the DMG having the usual symlink to /Applications for a drag-and-drop installation.

yes, it’s a total pain. users send you a crash log, you see that they’re on an old version, ask them to update. They say they do, you get the next crash log, and it’s still the old version. And then you get a screenshot and you see 12 different versions of your .app, in the desktop, in ~/Applications, in /Applications…

It’s because they have specific strategic things they want to do.

As an example, I noticed the Docker installer starts off doing telemetry before anything has been installed.

Other less nefarious uses are to ask about telemetry / GDPR before installation.

Apple documentation on installers specifically says — you don’t even have to have an installer. And most software really doesn’t.

With Zoom, apparently there’s the app bundle, some browser plugins, and an audio kernel extension (the latter two of which are majorly deprecated?)

The standard way to install an application on the Mac is to simply drag it into the Applications folder. That’s what is expected by users. For the vast majority of applications this should be enough. Whenever I see a Windows-style “installer” the first thing I think is… what kind of shenanigans are going on?

This standard way doesn’t work in corp environments (which WebEx and Zoom are targeting primarily), where machines are remotely provisioned. For decent macOS remote installs and updates you need the PKG format scripts.

What is so hard about remotely provisioning app bundles in a standard place? I ask because I have been tangentially involved in both image and script based provisioning and interacting with PKGs would seem to complicate, not simplify, both processes.

And the wacky PKG files used by Zoom (until recently) and WebEx are likely to be incompatible with those provisioning methods, because they don’t unpack their contents and finish installing normally.

The installer has to ask too though, doesn’t it? So using an installer still provides no benefit.

Yes, but the point is that most Mac apps should need neither installer nor admin privileges.

I believe the privileged process requests this on use; I am not sure how you’d trigger it during install

This is apples fault. Not for not blocking it but for not making the download-and-installed as streamlined as it needs to be. Being forced to drag something to a folder is not the UX you expect.

Would distribution via the App Store work? I mean that is the easiest and most trustworthy way – from a consumer’s point of view – to install software.

As a Mac-user since the mid 2000’s, that’s exactly what I expect. Whenever I see an installer I know that it’s some multiplatform/slightly crapware software I’m about to use.

I still don’t understand the issue with this: it’s not using this feature as intended, but they’re not exploiting any vulnerabilities or attempting to exploit a privilege escalation bug in macOS. Apple’s installers allow these scripts to do anything (and I believe there’s a prompt along the lines of “this installer will run a script to determine if the package can be installed”).

> “this installer will run a script _to determine if the package can be installed_”

Why would the user expect that script to install the application, or even modify their system in any way?

Instead of silently breaking they could have a popup like “Do you allow the preinstall script to write into /this/folder?” on a write operation outside of the sandbox.

“This installer will run a script to determine if the package can be installed.”

Not “This installer will run a script that installs this package without asking further questions, then terminate abruptly without going through the rest of the install process and giving you a chance to decide exactly where it should go”.

I always read the subtext as “This installer will run a script whose stated goal is to determine if the package can be installed, but y’know, it’s a script, and its existence is warranted for doing supposedly helpful yet nonstandard checks that the pkg API-or-something doesn’t provide, thus can’t be sandboxed, and therefore can do anything else it wants to. Would you like to assume trust and proceed anyway, or would you rather cancel and possibly audit the thing beforehand?”.

But that’s my paranoid tech background speaking. I can totally understand technical naïveté though.

They may not be exploiting vulnerabilities but they are breaking the contact with the expectations users have of how installers work.

>with the expectations users have of how installers work

Tbh I think that most people here on hn are experiencing cognitive bias because of additional knowledge – reality is that most of regular users do not give a damn about what installer does, they just want working app.

But why are they even using Installer.app? First, why use an installer at all; second, if they really want an installer, why not make a custom installer app and avoid the “run a script” prompt? Installer.app doesn’t have special privileges. Is the script approach just easier?

It isn’t a _security_ issue, because the script doesn’t circumvent any security restrictions, but it is a _trust_ issue, because the script abuses pre-install functionality to install the program without explicit user agreement: A Mac user expects a confirmation prompt, but never receives one.

This is an issue with the installers. The fact that installers on macOS still work like in the 90s baffles me — I thought they had done something smart with sandboxes, APIs for system privileges, and a “secure path” where user consent uses system-controlled GUI.

This issue mainly tells me that macOS installers are largely like a Windows .exe and Linux curl | sh (well, that’s not true since it still needs to be signed…).

Installers aren’t really the preferred way to distribute software on a Mac, unless you need special access to the system for some reason. Most Mac software is distributed as an application bundle that’s dragged wherever you want on the file system and then run by double-clicking.

I would go as far to say that a good chunk of more technically inclined Mac users have a tendency to view any user facing software that requires an installer with suspicion.

I hate it when the software I am trying to use installs itself on my computer after I click on it.

Has anyone checked that it doesn’t have the same uninstalled bugs? Namely the remote code exec rce that dropped a few months back..

This is not malicious. This is simply easing up the installation process. If the files can be copied directly into applications then do so rather than trigger a password prompt.

I would do the same.

Everyone who’s spent 3 hours talking a parent through downloading and installing a Zoom client understands exactly why they’re doing this. Mine are unable to (1) reliably download a zip file; (2) navigate to that file using Finder; (3) run something inside it.

By the time we were done — I use copilot (basically VNC with NAT punching built in) — and I got control of the laptop to just do it myself, there were 7 downloads and 4 unzip attempts.

My MIL and I have literally had facetime pointed at her laptop while I directed her where to to get copilot running for the quarterly cleansing-of-the-spyware.

While I agree with you that this aspect of Mac app installation is confusing (especially with Safari where your download just disappears into the top right toolbar) – they need to have figured that out before getting this far into the installer. Once your in the installer its all about hitting buttons.

> My MIL and I have literally had facetime pointed at her laptop while I directed her where to to get copilot running for the quarterly cleansing-of-the-spyware.

I haven’t used it, but macOS does have screen sharing built into Messages.

If that problem exists it needs to be solved at the OS level, not worked around in shady ways. BTW, can’t Web pages link to the app store?

I would say they should put pressure on Apple to make the install flow better, but what am I saying; this is Apple.

Haha 🙂 Tiny companies should put pressure on $1T Apple to change the install flow…

I wonder how could Apple take 30% their revenue out of this — yeah, by forcing them to submit the apps to the AppStore instead!

> BTW, can’t Web pages link to the app store?

Yes. But neither are distributed on the App Store, so…

And how exactly does this type of script help? The hard part is done before the script runs.

The Mac App Store is a trap – The sandboxed APIs are severely limited, and no large company is going to let Apple get even more in-between them and their customers.

First, they can use the sandbox without going through the Mac App Store. Sandboxing is a good idea regardless of distribution method. That would improve security for everybody, without needing to ‘let Apple get in between them and their customers’.

Second, Zoom already runs sandboxed for the other two ways you can run their client on Apple operating systems: the (iOS) App Store and the web. The Mac sandbox is the least strict of the three. So whatever they do, it doesn’t seem to be hindered by ‘severe limitations’.

I have yet to hear any feature that a legitimate videoconferencing application would need that would be disallowed by the macOS sandbox. Lots of other video chat apps are on the Mac App Store, like Facebook Messenger. Is the issue simply that Zoom is being sketchy and wants to continue to be sketchy, and sandboxing would not allow them to? That’s not because the MAS is ‘a trap’. That’s its main feature.

The sandboxed APIs should be more than enough for a video conferencing client. (Which, after all, can run in a browser…)

If Apple didn’t make the app store shit, it would help. Gouging on dollars, breaking opening from Finder, etc.

These are free apps.

And these apps deserve to have “breaking opening from Finder” and even more restrictions considering they have shown themselves to be completely untrustworthy, insecure, invasive and hostile.

I had this problem with Office. Powerpoint had fidgety dialogs every time I wanted to open a pptx file from a different directory. I wasted two weeks, deleted it, and reinstalled from the direct download.

This highlights a problem we should have addressed long ago – engineer a method to reliably educate old people about using modern computers so they could develop the same kind of intuitive understanding we have.

I used to do FT-on-iPhone-pointed-at-computer also. Now it’s easy to do screen sharing via Messages (formerly iMessage). Comes with built-in audio also, so you don’t even need to make a phone call.