Tell HN: Cisco WebEx on OS X uses the same pre-installer tricks as Zoom
180 comments
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.
I would love to see a lawsuit about stolen malware IP.
Is it officially considered malware by apple? If so... feds don’t screw about. Those guys could be in serious trouble.
Well then they’re lucky that law enforcement has a slightly more involved process to determine criminality than checking Apple’s malware filter list.
But should they?
Yes, I've always been a fan of not giving corporations the right to have people arrested and imprisoned without due process
It was when they pushed the update to remove the zoom webserver.
No wonder their uninstallation instructions[1] are hilariously complicated. They somewhat-helpfully point to an actual separate uninstaller package to download, but it doesn't even remove all the things mentioned on this page.
1. https://help.webex.com/en-us/WBX38280/How-Do-I-Uninstall-Web...
1. https://help.webex.com/en-us/WBX38280/How-Do-I-Uninstall-Web...
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.
The uninstallation page basically describes how to completely uninstall any nontrivial Mac application.
That seems pretty ridiculous coming from Linux, where the vast majority of software will be installed via a package manager, making clean removal trivial.
Under windows, I would consider any software that requires a separate removal tool to be suspect. Software wanting you to download a separate tool, fill out unavoidable surveys or linking you to a site to track uninstallations is all very seedy practices.
Why isn't it expected of Mac software to keep an installation manifest and provide a way for removing the software?
Under windows, I would consider any software that requires a separate removal tool to be suspect. Software wanting you to download a separate tool, fill out unavoidable surveys or linking you to a site to track uninstallations is all very seedy practices.
Why isn't it expected of Mac software to keep an installation manifest and provide a way for removing the software?
> Why isn't it expected of Mac software to keep an installation manifest and provide a way for removing the software?
It is dead simple to remove a .app from the Applications folder. Sadly the pkg installers also throw files everywhere. Some software does include an uninstaller pkg, like Windows apps will include an uninstall.exe. But like windows, not everyone is meticulous about making sure you can uninstall cleanly.
It is dead simple to remove a .app from the Applications folder. Sadly the pkg installers also throw files everywhere. Some software does include an uninstaller pkg, like Windows apps will include an uninstall.exe. But like windows, not everyone is meticulous about making sure you can uninstall cleanly.
macOS not having a standardised uninstaller format nor an equivalent to the Windows Add/Remove Programs is a strange deficiency. You are lucky if a pkg-installed program comes with an uninstaller, alas.
Re installation manifest: I did point out you can lsbom to get the list of installed files from a package (well, unless you use a trick like discussed here; you can do anything in postinstall scripts too on Linux, at least with apt). But programs generate config, state, and data, and those need to removed if you want to “completely uninstall” a program.
Linux certainly does not make clean removal (/etc, /var, dotfiles/directories) easy.
Oh, and the “separate tool” can be pre-bundled, whether you have to download it separately is orthogonal. Pretty much every Windows program has a separate uninstaller, because on Windows you simply can’t uninstall yourself.
https://ss64.com/osx/lsbom.html
Linux certainly does not make clean removal (/etc, /var, dotfiles/directories) easy.
Oh, and the “separate tool” can be pre-bundled, whether you have to download it separately is orthogonal. Pretty much every Windows program has a separate uninstaller, because on Windows you simply can’t uninstall yourself.
https://ss64.com/osx/lsbom.html
> That seems pretty ridiculous coming from Linux, where the vast majority of software will be installed via a package manager, making clean removal trivial.
Except that packaging (in the package manager sense) and distributing proprietary software for Linux, with its too-many distros and even-more-too-many library versions, is such a pain in the ass that almost no one does it in the first place.
Now AppImage, that's trivial.
Except that packaging (in the package manager sense) and distributing proprietary software for Linux, with its too-many distros and even-more-too-many library versions, is such a pain in the ass that almost no one does it in the first place.
Now AppImage, that's trivial.
What's real great is they didn't notorize the app. So on Mac you have to individually allow about 30 java bits in a row.
Yes - holy crap is it annoying. I found the best way was to only launch meetings from their desktop client :S
Beautiful mondegreen for notarize.
I was surprised that when I ran a WebEx exe on windows to join a meeting, after the meeting concluded a window appeared with my calendar information pulled from outlook.
It really highlights how on desktop apps can do what they like. Whilst on mobile platforms at least you have to grant specific access.
It really highlights how on desktop apps can do what they like. Whilst on mobile platforms at least you have to grant specific access.
I'll admit as a web dev I sometimes take some of the "omg JavaScript" a little personally. Some of the usual pile on articles (granted their complaints aren't technically 'wrong') sometimes imply the browser is a bad place for a lot of things that are happening there privacy wise and etc.
I always wonder ... "Uh, do you want platform specific desktop apps? You're not much better protected there man... and app availability becomes limited / a pain."
I always wonder ... "Uh, do you want platform specific desktop apps? You're not much better protected there man... and app availability becomes limited / a pain."
There's no fundamental technical reason why apps can't run as their own users (like apache
and postgres have done for 20 years) and and use something like oauth to control sharing data with other apps. Just laziness.
The Android security model. Running nvim and getting a prompt "Do you want NeoVim to access your home?".
The UNIX-y solution to this is to ban proprietary apps and run only vetted free software, interoperate with protocols, not implementations.
The UNIX-y solution to this is to ban proprietary apps and run only vetted free software, interoperate with protocols, not implementations.
Well the zoom vulnerability from last year was a failure to consider full consequences of javascript.
They thought binding a web server to localhost and having a browser make requests to it was OK. They did not consider that literally any other web page can make the same requests.
They thought binding a web server to localhost and having a browser make requests to it was OK. They did not consider that literally any other web page can make the same requests.
The answer is simple, just have server-side logic only! /s
Webex can sync with your corporate calendar. Its possible by signing into Webex, it checked your corporation calendar and synced that.
There is also a system with Webex, that is separate, and if you have Webex meetings registered against your email, it will provide you those meetings if you are not signed in.
There is also a system with Webex, that is separate, and if you have Webex meetings registered against your email, it will provide you those meetings if you are not signed in.
I installed webex recently and was also surprised because I didn't even sign in to webex, I just ran it as "guest" and it still pulled across my calendar from outlook somehow.
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.
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.
Suspicious Package and Pacifist are great tools, but you can do it with the built-in pkgutil command:
% pkgutil --expand foo-1.0.pkg foo_pkg
% cd foo_pkg
% ls -Al
total 352
-rw-r--r-- 1 magervalp staff 44491 16 Mar 12:19 Bom
-rw-r--r-- 1 magervalp staff 566 9 Apr 13:51 PackageInfo
-rw-r--r--@ 1 magervalp staff 67794 16 Mar 12:19 Payload
drwxr-xr-x 4 magervalp staff 128 9 Apr 13:51 Scripts
% mv Payload Payload.cpio.gz
% open Payload.cpio.gzBeen using 'Suspicious Package' lately: https://www.mothersruin.com/software/SuspiciousPackage/
I'll throw in a plug for the tool I've written, unpkg: https://www.timdoug.com/unpkg/
This is what I used, but it looks unmaintained; I'd try others' suggestions first: https://www.macupdate.com/app/mac/45385/payload-extractor
Got me curious too. Answer Just a google search away.
https://stackoverflow.com/questions/11298855/how-to-unpack-a...
https://stackoverflow.com/questions/11298855/how-to-unpack-a...
Pacifist used to be the go-to app for this; probably still is.
7-Zip can do it on windows, maybe there's an osx port?
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.
It's not safe to process untrusted files with 7zip
https://news.ycombinator.com/item?id=16985460
https://news.ycombinator.com/item?id=16985460
7-zip is great. The Unarchiver is its equivalent on Mac. Suspicious Package is better for this particular file format because it shows what the installer will do, not just what it has in it.
Keka is my go-to for this, actively maintained by its author.
https://www.keka.io/
https://www.keka.io/
brew install p7zip
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.
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...
Even worse when they don't copy it off the DMG. Just leave the DMG mounted.. forever.
What's the problem with leaving the exe in the DMG instead of copying it out? As a user and a developer I don't see any problem with this whatsoever unless the application is poorly built.
Oh wow, I had no idea about the unintended consequences of the DMG + App bundle installation mechanism.
Maybe the issue could be ameliorated with a self-updater built-in into the app? Not a separate daemon, but something that by running inside the app, would be able to know what's the path of the old version that should be thrown away.
Maybe the issue could be ameliorated with a self-updater built-in into the app? Not a separate daemon, but something that by running inside the app, would be able to know what's the path of the old version that should be thrown away.
Some apps offer to move themselves to /Applications on first launch.
Still, there's the possibility of users clicking "Cancel". Even then, it's a bit more code to write, test and pay for (from the POV of a client).
Wrapping the bundle inside a .pkg instead of a .dmg solves the problem "for free".
Still, there's the possibility of users clicking "Cancel". Even then, it's a bit more code to write, test and pay for (from the POV of a client).
Wrapping the bundle inside a .pkg instead of a .dmg solves the problem "for free".
The de facto standard for this is Sparkle.framework, and it's excellent.
That's good. It's called a portable app and it reduces pollution of your environment.
It's a simple partial implementation of something like Docker.
All fine and dandy until they accidentally eject the DMG and can't figure out where their browser went.
Maybe, but that's also an advantage. Often it is useful to have two versions of the same application available, for example if you are testing one of them, or if a feature or compatibility was broken somewhere along the way. Typical package manager software installation does not accommodate such use cases.
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.
It's the processes. Every update will have to go through change requests, loads of approvals, ...
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.
They work just fine with the remote via Jamf or what have you.
Deprovisionig might not work right, but that's rarely needed.
Deprovisionig might not work right, but that's rarely needed.
it's not like the app couldn't do those shenanigans when it's first started...
It would have to ask for Admin role to do so, though.
Still plenty of evil things you can do without admin privileges, like running a server in the background that launches Zoom (as they tried previously).
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 that (when I wrote and installer for internal use while at Apple) it needn't require admin to drop an app in, say, ~/Applications.
With Zoom, apparently there's the app bundle, some browser plugins, and an audio kernel extension (the latter two of which are majorly deprecated?)
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.
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.
> Other less nefarious uses are to ask about telemetry / GDPR before installation.
I’d imagine you’d want to gate this through the process itself to ensure users have actually accepted, especially as EULA enforceability varies from place to place.
I’d imagine you’d want to gate this through the process itself to ensure users have actually accepted, especially as EULA enforceability varies from place to place.
Do these apps request accessibility permissions for screen sharing and the like during install?
I believe the privileged process requests this on use; I am not sure how you’d trigger it during install
What's more bizarre is that they have a fully functioning Chrome app that works almost just as well as the desktop client. It installs in a click and doesn't go through any sort of installation process.
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?
Why would the user expect that script to install the application, or even modify their system in any way?
The fact that Apple allows an application to be installed in this step is an issue with Apple's design.
It’s a script, though; should they sandbox the preinstall phase? That would break most packages.
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.
99% of users will have no fucking idea what that means. They will either click 'Allow' (which makes this feature useless for 99% of people) or contact tech support (adds friction to installation, which is bad especially for conferencing software) or just give up and not use the product (which is bad for the company).
To be fair, it would at least ruin Zoom's incentive to do any of this, since they wanted a streamlined process that prompts the user less.
Why they didn't just use a dmg that has you drag the application into /Applications/ is something I still don't understand though. Surely that is the simplest most user friendly way to have non-technical users install applications without using the appstore.
Why they didn't just use a dmg that has you drag the application into /Applications/ is something I still don't understand though. Surely that is the simplest most user friendly way to have non-technical users install applications without using the appstore.
Maybe so, but that doesn't excuse those exploiting that flaw.
To be fair, Apple has rectified this flaw by writing the Mac App Store, where applications can't pull these shenanigans and are properly sandboxed from one another.
Why is the store relevant to sandboxing?
They only allow sandboxed apps to be placed on the store.
“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”.
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.
But that's my paranoid tech background speaking. I can totally understand technical naïveté though.
Zoom and WebEx are certainly taking that subtext but I am pretty sure that is not the intended subtext of that statement. :)
MacOS stupidly runs that script as a user with write permissions.
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.
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?
The built-in installer gives developers a lot of freebies like permission escalation and gets around "hey, you're trying to run a program from the internet" prompt. That is at least until developers start bending over backwards with crazy shell scripts like the one found in the zoom installer.
The interesting thing is that if you hit Command-I and Command-L you can see exactly what the package is doing, and the most recent one just seems to be moving an app to /Applications. For this sort of thing: download a zip, open the zip from your browser's download panel and then have the app move itself to /Applications when you open the extracted app is a much nicer flow that is semi-widespread.
Enterprise deployment?
Being only sub-consciously aware of the difference is still an impact. The repetition of the install process should lead toward more familiarity with how the process works. The zoom and cisco installers are breaking that repetition and replacing it with something unexpected.
The thing is that Zoom isn't installing the package either! If you look at the list of installed pkgs after installing Zoom there is no Zoom package.
They are using a .pkg only for the side effect of running a pre installation script that simply copies Zoom.app in the /Application directory. That is to a software develper garbage, why doing so, when all other macOS application require the user a single drag and drop?
Sure, that is probably not malware, but is a very poor practice, gives the user a bad experience, for no reason. These are the things that let's you wonder if the installation is managed in such a poor way how is the rest of the infrastructure.
They are using a .pkg only for the side effect of running a pre installation script that simply copies Zoom.app in the /Application directory. That is to a software develper garbage, why doing so, when all other macOS application require the user a single drag and drop?
Sure, that is probably not malware, but is a very poor practice, gives the user a bad experience, for no reason. These are the things that let's you wonder if the installation is managed in such a poor way how is the rest of the infrastructure.
Why are they doing that? How is it easier than just having the app self install?
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.
Can you point to data which shows that Mac users expect confirmation prompts? Because my thoughts are that no, Mac users don't have any expectations from installers other than to get out of the way as quickly as possible (which the script approach achieves).
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…).
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.
The zoom guys are ex-WebEx guys. I saw the same zoom-bombing problem in WebEx few years back. we just enforce adding passcode/PIN to each meeting to remediate customer escalation.
Why aren't more apps like Zoom and this one distributed via the app store? I mean besides the installer hackery they are legitimate and free apps right?
Or would that mean that their premium services would require paying the fees to Apple, which they avoid this way?
Or would that mean that their premium services would require paying the fees to Apple, which they avoid this way?
Because logging in, downloading and installing from the App Store is higher friction than how it works now. Typically Zoom is installed for the first time at the very moment a meeting is starting. Seconds matter.
Can you even use the app store with a company mac? Who has the login - your personal account or some corporate one?
Good question, I think it should be the corporate one, and even if it might be a bit more work to setup, it's definitely in the company's interest, since then the applications that are installed can be sandboxed and be vetted/whitelisted more easily.
On my company computer we can login to the App Store however we want. I created a new Apple ID with my work email but there would have been nothing stopping me from re-using an existing one.
Sure, you just make an account with your company email.
I know at least slack from the App Store can’t screen share for some reason. Maybe it’s not available as a permission from the App Store.
[edit] apparently this may be old info
Yes it can.
well that's interesting! i have to look that up again. i have it in our on boarding manual to not install it from the app store for that specific reason. thanks for the update
The app store is disabled on my work mac where I am most likely to need zoom/WebEx.
This is fair enough for managed situations where your company has signed-off on certain apps that they let you install.
But when everyone and their dog is using Zoom on their personal machines, Mac App Store should be an option.
But when everyone and their dog is using Zoom on their personal machines, Mac App Store should be an option.
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.
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.
> 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.
I haven't used it, but macOS does have screen sharing built into Messages.
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.
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?
So you want Zoom and Webex to submit a patch to OSX?
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!
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…
Yes. But neither are distributed on the App Store, so…
They need to do the work to get on the Mac App Store
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.
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 issue is not technical. It is political. Apple is arbitrary and capricious, and no one sensible wants every update to their software to be held hostage to Apple's whims. Large companies like Facebook can cut special deals.
The sandboxed APIs should be more than enough for a video conferencing client. (Which, after all, can run in a browser…)
Then I'm simply not going to install it. The only apps I have ever installed from the App Store are OS upgrades and I think Apple's office software, since neither is available outside of the store.
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.
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.
And how exactly does this type of script help? The hard part is done before the script runs.
Surely it would be easier for your parent / MIL to install from the Mac App Store.
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.
The problem is that you don't even need this; use a conferencing solution that works in the browser, such as Whereby.
It even works in Safari on an iPhone (!!!!!!).
It even works in Safari on an iPhone (!!!!!!).
zoom works in the browser, iirc
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.
That would be good, but it seems to take kids a few years to learn the ropes. I don't feel like older people have the patience or peer pressure.
Would love to be proved wrong, though. I would have paid money to make that problem go away when I had it with Skype.
User education does seem like a good solution to most of the problems being discussed, but that's certainly not a trivial thing to do, and I'm not 100% convinced that it can be fully solved. Learning to use a computer (well) is a decent amount of work.
I hate it when the software I am trying to use installs itself on my computer after I click on it.
I work in a tech company. The number of people you see who have their desktop filled with permanently mounted DMGs, launching their apps by opening said DMG and launching their trusty old Chrome version 53 by double-clicking the icon would blow your mind.
Users don't use your software as you would like them to. Zoom now requires ~4 clicks to update when a new version is released as you click through the installer steps. You have to click the single frickin' disk icon (which is the only disk 99.9% of Apple users are going to have... still you have click on it) in one of the steps for the Next button to activate. Result: I fully expect a large percentage of the users to never update their Zoom successfully again. Great win for the users, the software which you downloaded, then clicked to install, no longer executes that scary pre-install script.
Users don't use your software as you would like them to. Zoom now requires ~4 clicks to update when a new version is released as you click through the installer steps. You have to click the single frickin' disk icon (which is the only disk 99.9% of Apple users are going to have... still you have click on it) in one of the steps for the Next button to activate. Result: I fully expect a large percentage of the users to never update their Zoom successfully again. Great win for the users, the software which you downloaded, then clicked to install, no longer executes that scary pre-install script.
Not sure about what clicking disk icon you are talking about, but today's update showed up as regular pkg installer ("Next", "Next", "Accept", "Finish").
Chrome uses an DMG, and the result is that people are using ancient versions of it straight out of their Downloads or Desktop folders.
Zoom uses an .pkg, and have now removed the one-click install script. So every update to Zoom now runs through the same multi-step Next process as well (with one of the steps inactive until you select your disk, as is customary). If you think that isn't a problem for users, you've never walked grandma through the steps while she's trying to show her screen though the phone to you.
Zoom uses an .pkg, and have now removed the one-click install script. So every update to Zoom now runs through the same multi-step Next process as well (with one of the steps inactive until you select your disk, as is customary). If you think that isn't a problem for users, you've never walked grandma through the steps while she's trying to show her screen though the phone to you.
I believe you that in some configurations you have to select a disk where you want update to be installed but in my case it's selected automatically so as I mentioned in the previous post, it's matter of clicking "Next" buttons.
I don't understand. How is difficulty completing the initial installer relevant to autoinstalling updates?
Zoom's updates also runs though the entire installer again as of today.
Why is this necessary, though? There are examples of other apps, not distributed on the Mac App Store, that don't require the whole pkg flow for every update. Steam and Skype are examples.
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.
That's extremely unlikely.
Malware on macOS isn't prevalent. There is no market for anti-virus vendors on macOS, and Apple have been repeatedly tightening the approval process for macOS software. Gatekeeper only ever gets more aggressive, not less. Meanwhile videocall software is widespread, it's rapidly become a necessity for a large part of the world's population. I wouldn't be surprised if on macOS it's now in second place as a category behind web browsers.
No.
What Apple should, MUST do as quickly as possible, is understand and react to what developers here are trying to tell them - 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.
If Apple want to end these practices, they need to deliver:
1. Genuine one or two-click install of software from the web, without the App Store being involved and without requiring sandboxing, allowing install scripts and for signed/notarised software, without any security popups. DMG style installs require drag and drop AND device unmounting, which isn't especially discoverable and hardly used on mobile platforms so some users can't figure it out (hence the reliance on PKG files).
2. Removal of the scary popup that Safari shows when a user clicks a non-http URL.
Desktop software on macOS relies on these techniques because measuring the ratio of number of downloads to number of successful app starts shows that far fewer people make it through the process than they should, for instance, fewer than on Windows. This is a bit of an open secret in the desktop software world for many years now; Google for instance has detailed data on the problem. Each click you add causes the success rate to drop and macOS requires far more clicks than is justifiable. Additionally, the web server trick Zoom uses is because otherwise some non-trivial proportion of Safari users just automatically click cancel on the security popup when a web page tries to open a meeting, without even reading it. They don't understand what they're being asked or why, but figure if Apple want to double check with them it's safer to say no. Then they fail to join a meeting and if they're an important participant, that means the meeting fails for everyone.
Note that this usability problem is Safari-specific. On other platforms and browsers such workarounds aren't needed.
People need to stop giving Apple the benefit of the doubt here. Videoconf firms aren't doing this extra work because they're malicious or incompetent or because they inexplicably like doing work. They're doing it because otherwise a lot of Mac users fail to achieve the task they set out to do, and that hurts the usage of the video platform. It's ultimately Apple's problem to fix.
Malware on macOS isn't prevalent. There is no market for anti-virus vendors on macOS, and Apple have been repeatedly tightening the approval process for macOS software. Gatekeeper only ever gets more aggressive, not less. Meanwhile videocall software is widespread, it's rapidly become a necessity for a large part of the world's population. I wouldn't be surprised if on macOS it's now in second place as a category behind web browsers.
No.
What Apple should, MUST do as quickly as possible, is understand and react to what developers here are trying to tell them - 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.
If Apple want to end these practices, they need to deliver:
1. Genuine one or two-click install of software from the web, without the App Store being involved and without requiring sandboxing, allowing install scripts and for signed/notarised software, without any security popups. DMG style installs require drag and drop AND device unmounting, which isn't especially discoverable and hardly used on mobile platforms so some users can't figure it out (hence the reliance on PKG files).
2. Removal of the scary popup that Safari shows when a user clicks a non-http URL.
Desktop software on macOS relies on these techniques because measuring the ratio of number of downloads to number of successful app starts shows that far fewer people make it through the process than they should, for instance, fewer than on Windows. This is a bit of an open secret in the desktop software world for many years now; Google for instance has detailed data on the problem. Each click you add causes the success rate to drop and macOS requires far more clicks than is justifiable. Additionally, the web server trick Zoom uses is because otherwise some non-trivial proportion of Safari users just automatically click cancel on the security popup when a web page tries to open a meeting, without even reading it. They don't understand what they're being asked or why, but figure if Apple want to double check with them it's safer to say no. Then they fail to join a meeting and if they're an important participant, that means the meeting fails for everyone.
Note that this usability problem is Safari-specific. On other platforms and browsers such workarounds aren't needed.
People need to stop giving Apple the benefit of the doubt here. Videoconf firms aren't doing this extra work because they're malicious or incompetent or because they inexplicably like doing work. They're doing it because otherwise a lot of Mac users fail to achieve the task they set out to do, and that hurts the usage of the video platform. It's ultimately Apple's problem to fix.
> 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.
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.
Linux doesn't work that way for the software outside the repo, you either have to go find a deb/rpm and install it using another tool, or god forbid the thing you need needs another repo, which only works on x minor version of the OS in this distro and will cause the other widget you installed from the distro's provided repo to break because dependencies are different. AppImage/Snap are both trying to fix this, but for now it still sucks.
On the Mac, the whole "drag an app to the trash to delete" thing has always been a lie, since most applications spew things in ~/Library, /Library, and other app support directories, which means you miss lots of stuff that AppCleaner has to find. It's still a terrible experience, and if you don't know that then downloading a new copy of the app won't fix anything because all of its preferences and extra files are in a directory you didn't think to clean out because its hidden by the system.
On the Mac, the whole "drag an app to the trash to delete" thing has always been a lie, since most applications spew things in ~/Library, /Library, and other app support directories, which means you miss lots of stuff that AppCleaner has to find. It's still a terrible experience, and if you don't know that then downloading a new copy of the app won't fix anything because all of its preferences and extra files are in a directory you didn't think to clean out because its hidden by the system.
Just click-mount an installation disk image and drag an app icon to the Applicationss folder - isn't this a perfect install UX?
No. Please do set up a usability test in a lab and watch people try.
You will find:
1. Many users struggle with unusual mouse/trackpad movements like drag and drop, right clicking. That's why the Mac theoretically has a one-button mouse.
2. The instructions for what to do differ between DMGs and usually consists of a single arrow if present at all. This isn't clear enough to communicate "drag and drop" to people.
3. If the user figures out or has been shown that they have to drag and drop, they may then be confused when it appears nothing has happened, or by a small dialog that appears and then quickly disappears. It's now not clear how to actually start the app. Nothing appears in the dock, the app itself doesn't start. Launchpad made this better some years back because now there's at least a button to push to show you all apps and let you search for them iOS style, but the user has to realise they haven't started the app.
Note that if you use the App Store there's a sort of animation that (if the user sees it) suggests the app has been deposited into the launchpad. But you don't get that with out-of-store installs.
4. If the user isn't very familiar with this DMG process they may double click the app to start it from the DMG itself, which will look like they successfully installed it (because the app starts) but which may (a) break the app in subtle ways if it expects to be able to write to its own directory, (b) confuse the user when the folder disappears along with the downloaded file button in their browser, thus giving no obvious way to get back to it, except via a realisation that the window which popped up was a folder despite not looking like one and thus could be perhaps relocated via the Finder, unless you rebooted in between in which case maybe not.
Bizarrely and against all rules of good UX design the right thing to do isn't the simplest action that appears to work, but rather, several more steps in between.
5. If they do manage to drag it, find it in Launchpad and start it, very likely they won't realise they're supposed to "eject" the DMG to get rid of the prior copy, even though nothing is actually being physically ejected anywhere. They may also be confused by the presence of two icons that should be equivalent but aren't. If they do know they're meant to eject/unmount it there's nothing obvious to let you do that, for instance there's no button labelled "Eject", but rather you're meant to find the icon for the DMG on the desktop (which is covered), realise it's an icon that represents the window you saw earlier although in the absence of a branded icon there's no indication of that, be mystified by the strange metal object in the icon (who has seen a real HDD these days?) and then realise you're meant to start dragging it again to the trash can, which magically turns into an eject symbol? Or you could try using the Finder, in which case the sidebar entry for the DMG is going to be under "Locations" in a scrollable area that doesn't have scrollbars, and no visual indication it can be scrolled, and the icons next to the name of the app don't indicate what they do, and if your Finder is set to use e.g. tree mode then clicking it shows a view totally different to the one you saw earlier!
The entire UX is something only a UNIX hacker could ever think makes sense. Unless you have a really solid grip on filesystems, nested folders, mount points etc this whole thing is just totally mystifying and a lot of pointless busywork too.
Some Mac apps have code that detects when the user has made these sorts of mistakes and will offer to move the app to /Applications for them. It's intended to partly work around these usability problems, but ultimately, a PKG is still much better especially for videoconf apps where the standard way to start them is via the browser and not by finding an icon in Mission Control.
Windows: let every app you install do anything it wants with all the system files, leaving traces after uninstallation is a norm.
Mac apps leave stuff behind all the time too because they don't have any uninstallation procedure. On Windows it's at least a bug in the uninstaller which could be fixed. On macOS it's a fundamental design issue with the OS itself.
No. Please do set up a usability test in a lab and watch people try.
You will find:
1. Many users struggle with unusual mouse/trackpad movements like drag and drop, right clicking. That's why the Mac theoretically has a one-button mouse.
2. The instructions for what to do differ between DMGs and usually consists of a single arrow if present at all. This isn't clear enough to communicate "drag and drop" to people.
3. If the user figures out or has been shown that they have to drag and drop, they may then be confused when it appears nothing has happened, or by a small dialog that appears and then quickly disappears. It's now not clear how to actually start the app. Nothing appears in the dock, the app itself doesn't start. Launchpad made this better some years back because now there's at least a button to push to show you all apps and let you search for them iOS style, but the user has to realise they haven't started the app.
Note that if you use the App Store there's a sort of animation that (if the user sees it) suggests the app has been deposited into the launchpad. But you don't get that with out-of-store installs.
4. If the user isn't very familiar with this DMG process they may double click the app to start it from the DMG itself, which will look like they successfully installed it (because the app starts) but which may (a) break the app in subtle ways if it expects to be able to write to its own directory, (b) confuse the user when the folder disappears along with the downloaded file button in their browser, thus giving no obvious way to get back to it, except via a realisation that the window which popped up was a folder despite not looking like one and thus could be perhaps relocated via the Finder, unless you rebooted in between in which case maybe not.
Bizarrely and against all rules of good UX design the right thing to do isn't the simplest action that appears to work, but rather, several more steps in between.
5. If they do manage to drag it, find it in Launchpad and start it, very likely they won't realise they're supposed to "eject" the DMG to get rid of the prior copy, even though nothing is actually being physically ejected anywhere. They may also be confused by the presence of two icons that should be equivalent but aren't. If they do know they're meant to eject/unmount it there's nothing obvious to let you do that, for instance there's no button labelled "Eject", but rather you're meant to find the icon for the DMG on the desktop (which is covered), realise it's an icon that represents the window you saw earlier although in the absence of a branded icon there's no indication of that, be mystified by the strange metal object in the icon (who has seen a real HDD these days?) and then realise you're meant to start dragging it again to the trash can, which magically turns into an eject symbol? Or you could try using the Finder, in which case the sidebar entry for the DMG is going to be under "Locations" in a scrollable area that doesn't have scrollbars, and no visual indication it can be scrolled, and the icons next to the name of the app don't indicate what they do, and if your Finder is set to use e.g. tree mode then clicking it shows a view totally different to the one you saw earlier!
The entire UX is something only a UNIX hacker could ever think makes sense. Unless you have a really solid grip on filesystems, nested folders, mount points etc this whole thing is just totally mystifying and a lot of pointless busywork too.
Some Mac apps have code that detects when the user has made these sorts of mistakes and will offer to move the app to /Applications for them. It's intended to partly work around these usability problems, but ultimately, a PKG is still much better especially for videoconf apps where the standard way to start them is via the browser and not by finding an icon in Mission Control.
Windows: let every app you install do anything it wants with all the system files, leaving traces after uninstallation is a norm.
Mac apps leave stuff behind all the time too because they don't have any uninstallation procedure. On Windows it's at least a bug in the uninstaller which could be fixed. On macOS it's a fundamental design issue with the OS itself.
>>> 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.
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.
> 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,
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,
No company that has a choice is going to pay Apple their tax. That's why the MacOS sure is always going to be the same as the Windows store: a home of loser apps. Since another install procedure is available, only losers will use the app store. Ergo, any software available through the app store is a loser app.
And yet Microsoft Office is available via the macOS App Store, alongside venerable packages like Adobe Lightroom and Photoshop, Logic and Final Cut (Apple-owned software), the Omni suite of software, Autodesk software, Pixelmator, etc.
The App Store has problems, but all apps there being "loser apps" is not one of them.
The App Store has problems, but all apps there being "loser apps" is not one of them.
You can't pay for Office through the App Store though, you have to activate it with a personal or corporate Office 365 account. If you bought a perpetual license, I believe you have to go get it through Microsoft regardless.
Which is by the way against the App Store policies, so they must have cut some special deal.
I'd agree that an app store may be a solution.
But I would vociferously disagree that an app store can be the only solution.
Giving anyone that much power over a platform is antithetical to the promise of computing.
Ergo, as GP noted, Apple has a lot of work to do on making non-app store installs a viable alternative.
But I would vociferously disagree that an app store can be the only solution.
Giving anyone that much power over a platform is antithetical to the promise of computing.
Ergo, as GP noted, Apple has a lot of work to do on making non-app store installs a viable alternative.
App Stores have a lot of problems that push developers away from them:
1. Apple have a history of convoluted review processes and arbitrary rejections. It has a terrible reputation amongst devs.
2. Thanks to unpredictable reviews you can't time when a new upgrade becomes available to coincide with e.g. website changes, emails.
3. The App Store can't upgrade apps whilst they're running.
4. App Store 30% standard cut is far too high when a developer could sell direct from their website and pay 2% or less to a card processor.
5. The App Store UX is itself pretty bad. There's no flexibility or ability to customise how your app appears.
6. Devs are forced to allow app reviews and ratings although they may not wish to have that e.g. because users use reviews as a way to request support instead of an actual support system, but you can't reply.
7. App Stores often create problems for corporate or managed desktop deployments.
8. For software that is billed, despite exhorbitant fees their billing engines can be primitive. For instance even years after launch the Windows app store had no ability to do bulk discounts or other kinds of completely normal retail strategies. I don't know if it does these days, but I do know of an app developer who shipped via the WAS and whose business was badly hurt by Microsoft's lackadaisical attitude towards basic features like that. They could have sold big into education but couldn't get much traction because there was no way to offer reduced rates to schools.
9. App Stores enforce random policies unrelated to the core mission of app distribution. For instance the Mac App Store is extremely vague about to what extent plugin mechanisms are allowed. Good luck implementing an IDE or browser in the MAS; you'll always be living in a grey zone. It also forbids any kind of custom licensing mechanism or copy protection, so when Apple's is insufficient you're SOL and requires all languages to be in the same bundle yielding huge downloads (=lower conversion rate due to failed downloads). Those are just implementation limitations but you aren't allowed to do better.
Basically, Apple don't have a good track record of creating an excellent developer experience with their app stores. On mobile they forced devs into it against their will. On desktop where backwards compatibility prevents it, devs have nearly universally rejected app stores ... even when an app is in it, it's common for websites to direct users to their own distribution points.
1. Apple have a history of convoluted review processes and arbitrary rejections. It has a terrible reputation amongst devs.
2. Thanks to unpredictable reviews you can't time when a new upgrade becomes available to coincide with e.g. website changes, emails.
3. The App Store can't upgrade apps whilst they're running.
4. App Store 30% standard cut is far too high when a developer could sell direct from their website and pay 2% or less to a card processor.
5. The App Store UX is itself pretty bad. There's no flexibility or ability to customise how your app appears.
6. Devs are forced to allow app reviews and ratings although they may not wish to have that e.g. because users use reviews as a way to request support instead of an actual support system, but you can't reply.
7. App Stores often create problems for corporate or managed desktop deployments.
8. For software that is billed, despite exhorbitant fees their billing engines can be primitive. For instance even years after launch the Windows app store had no ability to do bulk discounts or other kinds of completely normal retail strategies. I don't know if it does these days, but I do know of an app developer who shipped via the WAS and whose business was badly hurt by Microsoft's lackadaisical attitude towards basic features like that. They could have sold big into education but couldn't get much traction because there was no way to offer reduced rates to schools.
9. App Stores enforce random policies unrelated to the core mission of app distribution. For instance the Mac App Store is extremely vague about to what extent plugin mechanisms are allowed. Good luck implementing an IDE or browser in the MAS; you'll always be living in a grey zone. It also forbids any kind of custom licensing mechanism or copy protection, so when Apple's is insufficient you're SOL and requires all languages to be in the same bundle yielding huge downloads (=lower conversion rate due to failed downloads). Those are just implementation limitations but you aren't allowed to do better.
Basically, Apple don't have a good track record of creating an excellent developer experience with their app stores. On mobile they forced devs into it against their will. On desktop where backwards compatibility prevents it, devs have nearly universally rejected app stores ... even when an app is in it, it's common for websites to direct users to their own distribution points.
Thank you for being the voice of reason here. The fundamental issues are with Apple and macOS, not vendors trying to make sure everyone who downloads the app can install it.
Isn’t all of this because of the Historical webRTC issues in safari?
In short, no.
So, I was under the understanding that Safari was dragging their feet on the whole WebRTC thing, and if they had come out with it when Chrome did, that these types of apps would then be able to run in the browser (just like Jitsi does today, I presume).
I know that companies have a perverse incentive to sell your info to advertisers and such, so I'm not trying to wave that away.
Just wanting to understand if Safari DID have webRTC much earlier, would we be talking about Zoom today?
I know that companies have a perverse incentive to sell your info to advertisers and such, so I'm not trying to wave that away.
Just wanting to understand if Safari DID have webRTC much earlier, would we be talking about Zoom today?
Yeah and if webex suddenly got popular like zoom,it too will be massacared.
This stuff is common. You know how many populat windows software acts bad? Filezilla's installer for example would literally install a very nasty strain of adware (to their credit, they give you the option to opt-out)
This stuff is common. You know how many populat windows software acts bad? Filezilla's installer for example would literally install a very nasty strain of adware (to their credit, they give you the option to opt-out)
The answer lies in zoom making a no-fuss-one-click installer and another full-winded-installer.
For work we’re in the process of switching from one to the other and the join meeting links on invites are now half functional on both. I wonder if this is the culprit
Has anyone checked that it doesn’t have the same uninstalled bugs? Namely the remote code exec rce that dropped a few months back..
On top of that, WebEx quality is way worse than zoom
cisco is not from China.
Zoom is from China.
End of story.
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.
I would do the same.
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.
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.
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.
App store installs are easy.
The difficult problem is making sure non-technical users can install and run binaries from untrusted third parties in basically a single click.
Does that sound like a security nightmare? It is. But it's also the users' expectation of "just working".
The difficult problem is making sure non-technical users can install and run binaries from untrusted third parties in basically a single click.
Does that sound like a security nightmare? It is. But it's also the users' expectation of "just working".
Running `strings` on the installation plugin (CWSPkgPlugin.bundle) shows why - it's using a similar process to what Zoom does [1]
Previously discussed here: https://news.ycombinator.com/item?id=22736608
[1] https://www.imore.com/zooms-preinstallation-script-workaroun...