The Zoom installer let a researcher hack his way to root access on macOS
theverge.com
theverge.com
And ownership. (The sentence before that suggests "root directory" here means "directory owned by root".) The permissions on the directory apply only to the file's directory entry, not the file itself.
This isn't a "subtlety", it's how it works, and no-one who doesn't understand this should be writing macOS installers.
The correct approach is to open the file for read and copy its bytes into your private area. Only then check the cryptographic signature. Just renaming into your private directory isn't enough, even if that directory has no read or execute access to other users, because the attacker could have opened the file for write access before you did the rename.
Sounds like its something that probably happens a lot and will continue to happen a lot?
Let's put all subtleties about Unix directories to the side. Zoom wanted to change the permissions of a file so that only root could access it. The obviously correct way to do that is to simply change the permissions of the file.
Even if their solution of putting the file in a root dir worked the way they expected, it would be a circuitous and hacky solution.
> sounds like a lot of reliance on people knowing and wanting to do the right thing?
At a certain point, people need to have basic knowledge. There's a lock on your front door. It does not lock when you turn your lights off. The lock maker is not responsible if you expected it to.
Obvious, but incorrect. As pointed out elsewhere, the permission check is done when a process opens a file, not when it performs read/write operations. So, an attacker could get a legitimate file, open in for writes, trigger the zoom update on it, zoom would then change the permissions to prevent writes, and then the attacker could modify the file using its already-open file handle.
Objective C does retain perms by default using some common move techniques.
https://superuser.com/questions/101676/is-there-some-differe...
It is not until the last comment of the accepted answer that you get to the difference in permissions. (along with the answers that are not accepted as best)
If you're using a library or tool to do this for you, you should know what it's doing.
https://unix.stackexchange.com/questions/684122/what-permiss...
Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works.
> And you could easily have file access permissions depend on the directory if you wanted to.
No, because you can have multiple links in multiple directories all pointing to the same file.
I don't really see the logic that way. Even if it was "inside", this permission failure would still happen. And directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized.
> No, because you can have multiple links in multiple directories all pointing to the same file.
Well I put the word "access" there to try to be clearer. If you as system designer wanted to, you could have the path you take to a file affect permissions, even with the 'directory' model and multiple hard links. Heck, you could have permissions be on links instead of on files. YOLO.
Could you explain how this would work?
Ehr, no. Again, there are no files in the conventional sense in UNIX file systems. There are collections of disk blocks pointed to by an i-node and one or more directory entries pointing to an i-node. It is possible to have an i-node with 0 directory entries linking to it as well as multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node; both are treated as file system errors by fsck and will be fixed up at the next fsck run. Yet, both scenarios can be easily reproduced (without corrupting the file system!) in a file system debugger and live on for a while.
> […] a descendant of a directory that blocks traversal. No subdirectories of those […]
Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not.
A directory might be «protected» by, say, 700 permissions obscuring a particular directory entry, but if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access, say 755, access to data blocks referenced to by an i-node has already leaked out.
That's what a hard link is. What we call hard links in Unix/Linux is when you have multiple distinct directory entries referencing the same inode.
And file system corruption is definitely a loophole.
> Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not.
All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory.
> if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access
That's why I said every hard link to the file!
Zero directory entries pointing to an i-node is not a file system corruption as it neither corrupts the file system nor breaks the file system semantics; it is possible to have a garbage collector running in the background to mop up orphaned i-nodes with the file system remaining fully operational at the same time.
Distinct i-nodes pointing to the same block allocation, on the other hand, are a security loop hole and create consistency problems. Whether they cause the file system corruption or not is a matter of an academic debate, though.
> All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory.
It is possible to design and write a file system implementation that will retain the UNIX file systems semantics of i-nodes and directory entries whilst remaining completely flat (i.e. no directory hierarchies, just «.»). Such a file sysem would be impractical for most use cases today but is easily possible, and such file systems had been a commonplace before the UNIX file system arrival.
Earlier on, you had mentioned: «If there's any loopholes in that, they could be closed». The example below (which is perfectly legit and does not contain semantic loopholes), which of directories does «file.txt» belong in or descends from/ascends into: 1) «a/b/c», 2) «d/e/f/g», 3) «.», 4) all of them? Which of the three directories is more specific and why, and what about future hard links?
$ mkdir -p a/b/c
$ mkdir -p d/e/f/g
$ echo 'I am a file' >file.txt
$ chown 0:0 file.txt
$ chmod 666 file.txt
$ ln file.txt a/b/c
$ ln file.txt d/e/f/g
$ sudo chown 0:0 a
$ sudo chmod 700 a
$ ls -l a
ls: cannot open directory 'a': Permission denied
$ ls -l d/e/f/g/file.txt
-rw-rw-rw- 3 root wheel 12 Aug 14 23:59 d/e/f/g/file.txt
$ ls -l ./file.txt
-rw-rw-rw- 3 root wheel 12 Aug 14 23:59 ./file.txt
$ echo 'Anyone can access me' >./file.txt
$ cat ./file.txt
Anyone can access meYeah, it would also be possible to design a system that doesn't enforce permissions.
The challenge here is whether you can make a reasonable design that's secure. Not whether any design would be secure; that's self-obviously false. Anyone doing the designing can choose not to use a special bespoke filesystem.
But I don't see how your described filesystem would cause problems. The directory entries are still descendants of the directories they are in. Apply the rest of the logic and those files are secure. It's easier, really, when you don't have to worry about subdirectories. If subdirectories don't exist, they can't be open.
> Earlier on, you had mentioned: «If there's any loopholes in that, they could be closed». The example below (which is perfectly legit and does not contain semantic loopholes), which of directories does «file.txt» belong in or descends from/ascends into: 1) «a/b/c», 2) «d/e/f/g», 3) «.», 4) all of them? Which of the three directories is more specific and why, and what about future hard links?
The file is not in a specific directory. Links to the file are in `pwd`, a/b/c, and d/e/f/g. "Being in" is the same as "descending from".
If you secure `pwd` (and nothing is already open), then all three hard links will be secured.
Or if you remove the hard link in `pwd`, and secure g (and nothing is already open), then the file will be secured.
"./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"?
If future hard links are made, then they follow the same rules. If any hard link is not secured, then the file is not secured. And a user without access to the file cannot make a new hard link to the file.
It is even easier than that: one only has to simply detach the disk and reattach it to another UNIX box to gain access to any file as the file system itself is defenceless and offers no protection from the physical access to its on-disk layout. File system encryption is the only solution that makes physical impractical or at least convoluted.
And, since UNIX file systems delegate permissons checks to the kernel via the VFS, it is also possible for a person with nefarious intentions to modify the file system code to make it always return 777 for any i-node being accessed through it, find a local zero day exploit, load the rogue file system kernel module and remount file system(s) to bypass the permission enforcement in the kernel.
The reverse is also true: if the kernel and the file system support access control lists, standard UNIX file permissions become largely meaningless, and it becomes possible to grant or revoke access to/from a file owned by root with 600 permissions to an arbitrary user/group only. Using the same example from above:
$ cat ./file.txt
Anyone can access me
$ sudo /bin/chmod +a "group:staff deny write" ./file.txt
$ /bin/ls -le ./file.txt
-rw-rw-rw-+ 3 root wheel 21 14 Aug 23:59 ./file.txt
0: group:staff deny write
$ echo 'No-one from the staff group can access me any longer' >./file.txt
zsh: permission denied: ./file.txt
$ id
uid=NNNNNN(morally.bold.mollusk) gid=MMMMMM(staff) groups=MMMMMM(staff),[… redacted …]
$ ls -la ./file.txt
-rw-rw-rw-+ 3 root wheel 21 Aug 15 17:28 ./file.txt
Indeed, rarely can security be bolted on with any measurable success, and a system can be secure only if it is secure by design. But security is also a game of the constant juggling of trade-offs that may or may not be acceptable in a particular use case. Highly secure designs are [nearly always] hostile to users and are a tremendous nuisance in the daily use. The UNIX answer to security is delegation of responsibilities: «I, UNIX, will do a reasonable job on keeping the system secure, but the onus is on you, user, to excercise the due diligence, and – oh, by the way – here is a shotgun to shoot yourself in the foot (and injure bystanders as a bonus) if you, the user, are negligent about keeping your data secure».
> "./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"?
The point I was trying to make was that specificness is a purely logical concept. In the aforementioned example, there are 3x directory entries at 3x arbitrary locations and any of them can be used to access the data referenced to via an i-node. Once a file is opened using either of those three directory entries, it is not possible to trace the open file descriptor back to a specific directory entry. Therefore, none of the three directory entries is more specific than the others – they are all equal.
I see.
Then I would agree that every path is equally specific.
But I never wanted to trace a file descriptor back to a specific directory entry. The question that matters is whether all the directory entries for a file are in secure locations. That treats them all equally.
Also, part of the scenario I laid out is that the file is not open to begin with. (If you were to try to check if the file is open, that's outside the scenario, but also shouldn't care what directory entry was used.)
There is a second possible misconception that I did touch on in my last paragraph, but didn't spell out. On Unix, the permissions check is done when you open the file, not when you perform the read or write. This means that a user who cannot currently open the file (because directory permissions mean they have no way to get to the inode) can nonetheless alter it now if they opened it when they could. So you could rename the file from the attacker's directory into your installer's private directory, verify its cryptographic signature, but then the attacker injects their malware into the file before you start copying, and you install the malware.
Because the two common types of locks on Unix (BSD and POSIX record) are advisory, you can't just lock that file against writers before you check the signature. This is in contrast to Windows, where you can't even rename or delete the file if someone else has it open.
Or force a reboot, I guess?
Besides, for what zoom does, why do they need an app? Browser has all the capabilities they need.
On the other hand, Zoom web client is an afterthought, to put it nicely.
Just a little snippet from the Teams installer page: "Windows Firewall configuration will be altered even when the prompt is dismissed by selecting “Cancel”. Two inbound rules for teams.exe will be created with Allow action for both TCP and UDP protocols."
Discovered this during pandemic WFH. Since then, this is THE collaborative drawing tool for any design discussions, interviews etc.
https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...
There is also a proper macOS API for this, which they are skirting using by using this hack.
Does zoom have such a thing as an unsolicited incoming meeting/join request? You don't have to answer, idk and don't care, just guessing at possible theoretical legit uses just to be complete.
I just know there's all kinds of use cases I have no use for, or actively hate, that most other people seem to love, not even just businesses inflicting things on employees but normal people using voluntarily.
Just because you're root does not mean you get any entitlement you want, or arbitrary access to the whole filesystem, arbitrary memory access (a la /dev/(k)mem), or can replace the kernel just like that.
(That's also probably why you don't hear of iPhones being "rooted", but rather "jailbroken". Just being root on an iPhone wouldn't do that much.)
Make no mistake, this is still a privilege escalation attack and needs to be fixed.
Top tip for people that use 1Password: I’ve discovered recently that you can run it as an ssh agent. That way your keys never leave the 1password app.
I was under the impression that 1password uses secure enclave on the Mac and that it only decrypts the key as it's needed. I guess depending on the implementation the decrypted key could be in memory for a moment - or maybe longer.
You don’t need to type it, you can store it in a password manager and copy/paste, which is pretty fast. I do it all the time, it’s not a big deal.
If attacker code can run under your user, you're kinda screwed.
https://help.apple.com/pdf/security/en_US/apple-platform-sec...
This means that if the user as given Zoom access to the mic and camera (a more than likely scenario), our injected library can equally access those devices.”
It does some unusual stuff that it probably doesn't actually need to be doing.
They have taken the market by storm, because most people care about the former, not the latter
The only annoyance is having to manually extract it out of the downloaded archive when I want to update it. But IIRC, this takes two commands, not including the commands to swap the new app bundle with the old.
The downloaded archive is compressed with xar, and I believe that one should be extracted into an empty directory because otherwise it will spray files everywhere. Then the app bundle is in a gzipped cpio file...I think it's at Contents/Payload.
Per-app self-updaters are such a disgrace, it really makes me wish I could cheer this on. It's a shame that their elimination, for Mac users, might mean that the app store becomes the only or primary mechanism for automatic app updates on macOS.
What would they stand to gain from this? They already have root on the machine, so they could just send an "update" to that code to do whatever they need.
Udocker and singularity (the containerization toolset) also help a ton too. Docker's root requirements make it unsuitable for lots and lots of situations where it would otherwise be useful.
Zoom for government is authorised for FedRAMP moderate, and has authorisations from the DoD and the Air Force. Does that mean anything?
It means they ticked a lot of boxes.
Certifications only overlap a little bit with actual security. Most of SOC2 for example is just bureaucracy and a cash grab by enterprise SSO providers.
[0]: https://fly.io/blog/soc2-the-screenshots-will-continue-until...
But yeah it can tell it's in a VM because that's when it decides to crap its pants. By this point it's impossible to tell if bugs are intentional when they benefit the startup, there's a whole game in bugs, like no don't fix it it causes the user to lose his shit and give up and pay for this upgrade in the hopes that it all gets better.
There was one bug, yeah a bank bug I saw in Chile. So what this bug did is it fucked up printing the receipts after the user had paid and the bank machine said the transaction was approved. Employees would then insist the user hadn't paid because a receipt hadn't gone through. So the customer had to pay again--and the second time it always worked--double billing. Fucking stealing. Theft. MacDonald's at the SCL airport brazenly stole from me in exactly that way. And did that bug get fixed promptly? Ha...na let it be a little longer, it's not a high priority. It's...not urgent. Fix it next quarter, it's too difficult.
You can't assume good faith in software as it's delivered.
By default if you click a Zoom meeting link to join, it takes you to the Zoom page and starts a download of the installer (.pkg for Mac). The "Join from Browser" option is hidden and if I remember right, you have to click "Join" again, and then it will show a small HTML link about Join from Browser.
The Browser experience is subpar and buggy. A lot of features lag in the UI, it's very slow to connect to audio, and there are a few options I recall that reload the entire page without warning, meaning you leave the meeting and have to reconnect, often to find a double of yourself.
I also noticed issues with USB Audio devices where after awhile, a static-ey robot noise would appear from you. No other voice apps I used experienced this, only Zoom and only with USB devices and from the browser version. Maybe it's something with Firefox + USB audio, but never was interested to investigate more.
Zoom is really not good software and it's an exercise in frustration when we have to use it at work, and the pricing model seems a bit ridiculous, even for basic users.
On the other hand, I’ve not had any audio or video problems once in the call, so ymmv.
Having used pretty much all video conferencing software, it's by far the best in terms of features, UX, call quality, feature distribution across platforms (do you know that some like BlueJeans don't allow you to have a separate audio input/output device if the device chosen for one supports both? (I have headphones and a separate mic, i can't have the headphones for output only). With Zoom as long as everyone is on the app and not the browser version, all features work. Teams on Linux or mac is always lagging months behind.
In any case, I seem to need to talk to various companies using a disturbingly wide range of applications on a regular basis. Google Meets, Zoom, MS Teams, Cisco WebEx, Skype are all things I've used professionally in the recently. I've also used Slack, Discord, as well as Whatsapp, Facebook Messenger.
The thing is, they all kind of work and roughly with similar audio/video quality and all with the same kind of performance, usability, and other issues. Some of these are more suitable for 1 on 1 meetings and some of these things seem to be geared towards corporate setups.
I have a slight preference for using Google Meets; mainly because I can just launch that straight into the browser (Firefox) without any fuss and it just seems to work and is actually designed to work that way. There is no app even. You just click the thing in the calendar and it opens. Best of all, it plays nice with Firefox containers. So I can join corporate meetings with one account and private meetings with another. The most annoying thing is when you have 1 minute to join a meeting and you discover you need to first install some enterprise crap ware to join and then deal with permissions for it needing access to the screen, audio, etc. I just got a new laptop so, I got to do this a few times already in the last week.
When the pandemic hit and everyone started working remotely, Zoom was already primed to be the winner.
Zoom hit enormous growth in 2020. Before that, they were just yet another obscure video call tool thingy. I've used several of the long forgotten ones that existed before covid. Investors seemed to like investing in me-too applications. Zoom was one of them and was able to spend enough on marketing right when it was optimal to do so. They hit a perfect bubble of investment cash and a sudden, unexpected need for video call tools.
People imagine all sorts of technical advantages that it simply never had. It's just a web app around some generic off the shelf video communication technology that they definitely did not invent. That's why there were so many of these tools already long before Zoom existed. I know of several such companies that came and went in the Berlin area and talked to their teams. All you needed was some generic full stack coding skills and a couple of weeks to prototype together the off the shelf stuff. Some of the UIs I saw were actually pretty cool. Unlike Zoom, which I always thought was pretty generic and bland as a UX.
Zoom has less friction, the installer just works on all platforms, and there are less noticeable bugs.
Most use them to update the application seamlessly without a pop up asking for permission from the users afaik.
But yes it does mean you get hilarious stuff you wouldn't expect like privilege escalation to root in teams, zoom, etc.
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.
https://developer.apple.com/documentation/bundleresources/in...
That said, it could just ask for your password at the time.
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.
- 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.
I did one other thing when I discovered their app auto installing a launchd auto-update service:
rm -rf ~/.zoomus
sudo touch ~/.zoomus
[1]: https://gist.github.com/caldwell/c212119fffd92a1d706c0a9b00f...
The UX for packages also sucks. With DMGs you just mount and then drag to the Applications folder… even the most basic macOS users have done this.
It still has way, way more privileges than a webapp. And arguably, if you have all your valuable information in a single user account, it has the crown jewels already, no admin needed.
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.
‘Been fairly good’
Those can’t both be true
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.
edit: meant this in response to some comments below about Zoom requiring admin access to install on macOS
It isn't root all the time, and is only root when provided with the proper password.
Because the UX of other offerings is so poor and zoom for most part just works.
I say this as someone who is aware of the security issues, but still prefer zoom over anything else.
the few times I used zoom there always was problems with audio, camera or people struggled to join
Or were you you referring to Duo, which is also called Google Meet now. Or Hangouts, the other Google video chat app which also exists for some reason? Or Google Hangouts Meet, which also existed? Or Google Allo?
It's better than Google Meet because Zoom won't shut itself down in 6 months, replace Zoom with a different app with a different name, change the name, change the name again, then shut that down and repeat the cycle 6 months later.
You go to meet.google.com and it works without too much hassle.
This is a technical feat that somehiw still escapes most of the other videoconferencing platforms (except maybe Zoom, but then they try to hide it as much as possible).
Predefined hosts is a place that is lacking. In general Meet started as a "everyone is mostly trusted" tool which is way better for office meetings so their host controls are behind (but slowly being added). Zoom is by default "only the host is trusted" which is very annoying in my day-to-day use. (For example you can't have a weekly meeting because the "organizer" is on vacation and can't start it. You can't screenshare because the host needs to approve, you can't join before the host... Most of these can be changed by default in your settings but I'd course most people in my company haven't done this so we run into problems at least weekly and need to scramble to send around a new link and hope that we manage to get everyone into the same call.
But that being said I think Zoom is still the better option for "untrusted" setups like seminars, presentations or other complex or large events. Meet is far better UX for meetings.
What do you have against Meet? It's a better solution than Zoom. It doesn't have built in whiteboarding, granted, but for that you can use an online whiteboarding tool.
You are very, very wrong:
1) Old people get very confused even when the interface changes.
2) The changes are irritating even if you know Google products
3) Change for the sake of change (someone at Google wants to get promoted) is just a waste of time, especially as the products are half baked. Maybe you are very young and your time is worthless, but most people want products that just work, with a non confusing interface. Change for the sake of change is something that busy-bodies do to prove that they are useful
4) Google has killed its own products multiple times, so at some point the stuff just stops working. Why bother using a product that will not work?
Seriously, it has been few years that everyone knows that Google does its business wrong: those on top should be removed, since it is a lot of money lost. In both of marketshare lost and lots of programmers reinventing the wheel multiple times to offer a half baked product.
Every few days I see people who cannot use Microsoft TEAMS (which has a poor interface) and I can easily see that if they used Google products, those constant unnecessary changes would make their lives miserable and make them less productive. Maybe reason why Google products are a joke in corporate environment.
I dont really use Zoom, used it mostly to see how it works - and from technology perspective it can be full of holes, but from UI perspective it is much better than the competition. Also probably wont be shut down in 3 months like Google Meet Duo Allo v5.
That's a very ageist and ignorant comment. There are plenty of Tik Tok videos of young people getting confused over very simple things as well.
Sometimes age can be related but being "old" isn't a sentence to being confused by UI/UX changes.
Doesn’t require a Google account to login.
Zoom also requires an account to log in.
And one of the recent Google meet offerings (not sure exactly which one but it was about a year ago) required an account before I could connect to the call. Perhaps it’s different now.
I’ve found that the screenshare quality in Zoom is rather strikingly better than in Meet, to the point that sharing a large screen with an editor full of text is frequently unreadable on Meet but perfectly crisp in Zoom.
Also, Zoom does some sort of background noise cancellation that is really impressive. I don’t know if other apps don’t do it, or do it worse, but it’s noticeable on calls (I use both Zoom and Meet daily). I was curious so I tested it from a coworking space recently: recording my headset mic in the open room I could hear voices, an espresso machine and some distant music pretty clearly. Joining a Zoom and doing the same and my background audio was genuinely silent.
I don't recall meet being this bad a few years ago (I used to be at a company that used it for all internal meetings) so I don't know whether some infrastructure changes have occurred to make it so.
Half the options that should be on a meeting-basis are buried deep into the user settings, only accessible from the web interface, and they have confusing names and meanings. I've used lots of softwares, Zoom might be one of the worst when it comes to UX.
We switched to zoom though because the performance was just better than anything (we tried a boat load of tools - but most of them were just shiny saas offerings on top of Chrome). Now I’m on an M1 it doesn’t matter as much, but zoom was the only thing that didn’t totally kill our machines before that.
Zoom UI is horrendous. But it’s also not quite as bad as teams, and everyone has learned to cope with it. So it’s the best of an absolute shitpile. Teams will remain a complete joke to me as long as I am forced to play the “try to map initials to names” game in order to figure out who is talking. I don’t know my coworkers by their initials, Microsoft. I don’t know why you can’t just show me actual names.
Meeting UI people: here is a list of questions that I find myself constantly asking myself: who is talking? Who just finished talking? Who is in this meeting? Who just joined? Who just left? If you waste an entire screen on nearly information-free user tiles and make me open a separate window to answer these types of questions (or they are impossible to answer), I hate you.
I’d say the expectation is that everyone sets their actual photo as their profile picture, that would probably solve your problem.
I'm almost willing to pay good money to someone who can explain how MS' user management works wrt belonging to multiple accounts/orgs/acive directories.
And regarding profile pictures, I’d say 10% of the people I interact with on zoom have them, and 0% of the people I interact with on teams. These platforms should get over themselves and realize people aren’t spending time customizing their profiles, because it’s just not important. You’re just a tool, zoom/teams. Try not to go wild with your fantasy of becoming a “virtual town square” that is integral to all aspects of life or whatever you are telling yourself internally. First goal is making meetings less of a pain in the ass.
For me, it’s Teams. It’s worse in almost every way.
I thought you were referring to the banking app for a second and was insanely confused.
Search results that don't allow you to go to the specific part of long conversations. Wiki that doesn't even qualify as wiki. Integrated calendar that automatically tries to make you join meetings you have not yet responded to (with no way to configure not to happen). Inconsistent ability to quote reply to peoples messages. Hap-hazard method of starting meeting recordings (anyone can do it and with the latest update they become the owner instead of the meeting organiser). External guests can't access meeting recordings. Inserts non visible spaces into code you paste in and does not strip it properly when copying and pasting out. Emoji selection popup fails to load if you join a meeting with busy chat as loading new messages takes priority. Inconsistent loading of tabs when you join a meeting, so some people cant do Q/A or look at files (but can be loaded in a separate window even whilst the meeting is running. Bigger issues like high CPU usage (massively compared to Zoom) with lots of attendees and far more limited visible attendee screens (compared to Zoom).
At the moment obvious defects seem to be added faster than they are removed.
You know where the priorities are.
I'm exaggerating a bit, but for me Teams is a real turn-off.
As someone who is interviewing at the moment. I won't completely dismiss the company for using Teams (and expecting the interviewee to 'cope' with the crap experience) but it immediately puts that company in the "hmm, I'll do this interview for the practice and maybe they'll surprise me" camp ...
We use Teams at work, and I think it's an absolute pile of crap. But whenever I have to attend meetings using other systems, the experience is pretty much never great either.
Zoom has a weird windowing system, stealing focus all the time, and shows notifications as actual windows (as opposed to using the notification system).
Google meet sometimes squeezes my webcam image for some reason. It also transforms my PC in a jet airplane.
Chime sometimes works, sometimes doesn't. Usually, it won't detect my microphone. If I refresh the page enough times, it will end up working.
Webex mostly works, but it's sooo laggy. It also needs me to have the window focused if I connect too early to a meeting and am the first one there. If it's unfocused, it will not connect to the audio, so I'm left waiting around wondering why people are always late. And it insists on showing a bunch of useless crap around the main image. I know who's in the meeting, so if they're sharing their screen, I want to see that instead of their names taking up half the screen.
Of all the various meeting tools, Zoom is the best, but that's damning with faint praise.
Slack used to be good - especially for just a background chat, but then they hid the "start a call" option away and pushed "huddles", which are far worse.
There's a solid rule of thumb that most software that is good becomes worse. Product managers have to push new features in to justify their job, if the software was 75% good before, there's a 3:1 chance that the change will make it objectively worse, and even higher chance that it will break your workflow and cause you to take cognitive load away from important things to learn how to deal with it in a new way.
"No, we're not changing that. Your changes don't meaningfully improve the product enough to offset the disruption."
Unfortunately I've noticed that "product owners" have become significantly less engaged with steering the product direction. I guess people either don't find it interesting, or they keep getting threatened by higher up and don't feel like they have enough power or own the product.
Oh man, that calendar is such a shitshow, and it's also not only on Teams, but also on Outlook.
It's able to detect some other conferencing software and add a "join" button, for example Webex.
But, for some reason, it systematically fails to recognize Teams links sent from a company we work with a lot. If I click the "join meeting" link inside the invitation, Teams will open and join said meeting, but it never shows the "join" button on the event in the calendar view.
This is so frustrating. How could anyone work on this feature and not realise how useless it is to see the message in question but not any of the surrounding discussion for context.
The calls aren't too bad at all.
Second, it drops you out of meetings sometimes while you are screen sharing, and gives you no way to know. It's sporadic on my machine whether the green highlight/frame shows up on screen sharing to indicate that the content is still being shared.
Do you really have a strong opinion about which one is the least bad choice?
> Do you really have a strong opinion about which one is the least bad choice?
I suspect that, if you're in the US or China already (which, just to say it explicitly, I recognize does not apply to everyone on HN), then you perceive a meaningful difference in whether any improper use of data will expose that data to the US, or to the Chinese, government. Even if your personal threat assessment finds no difference in those risks, then you probably at least have a strong opinion whether it's better to have your data improperly exposed to a government of whatever country, or to a private corporation.
Yes, the one without a desktop install is clearly the best solution.
Teams, Google Meet, etc all seem to fall apart on large calls with participants who have questionable hardware and/or wifi. Zoom works with those same people.
This is based on my experience early in the pandemic, so it's possible the landscape has changed since then. We tried a bunch of different options at my company, because we explicitly didn't want to use Zoom, but Zoom worked like nothing else did.
"Upon arriving in the US, Yuan joined WebEx, a web conferencing startup, where he was one of the first 20 hires. The company was acquired by Cisco Systems in 2007, at which time he became vice president of engineering. In 2011, Yuan pitched a new smartphone-friendly video conferencing system to Cisco management. When the idea was rejected, Yuan left Cisco to establish his own company, Zoom Video Communications."
Agreed, Zoom does shitty things. But everything else is worse.
I also had performance issues on zoom, but I'm willing to ignore that since most other people don't seem to mention those issue so that's probably on me.
Neither are reasons not to use it as a default first option.
Also matrix has voice and video now and there's big blue button.
While we are at it why can’t I control what audio interfaces are available to a specific program on a program by program basis? No, I will never want to use Steam Streaming Audio or my Oculus quest mic on a webex/zoom. Ever.
In addition, even if I select "System default microphone", that doesn't always work correctly. As far as I can tell, that option doesn't mean to attach to the default source. Instead, it means to attach to the same source that is currently bound to the default source. If I change the default source later, Zoom doesn't get moved along with it.
It's insanely annoying. Zoom has caused more crashes ob my machine than any other piece of software.
The main "advantage" that I can see to prefer Zoom is that Zoom ("Zhumu") is considered by the authorities in China as safe, so it's not blocked there (which is convenient if you speak to people in China).
Not surprisingly given it’s gamer heritage, Discord is slick and fast for many-party voice and the present/screen-share is better than I expected, but video chat needs work and there are other nags.
I have somewhat high hopes for Telegram because it usually does things well or not at all, but I also wouldn’t want to try getting 20 people in a videoconference.
I never liked in-person meetings with tons of people in the room, and one presenter, many listener video/screen broadcast is very achievable today without Zoom. Maybe it’s a hard UX problem because it’s a fundamentally flawed collaboration model, who knows.
I’ve had better experiences as an attendee on other software. (I think one was Gotomeeting). Works flawlessly in the browser. No dark patterns like the way Zoom tries to trick you into downloading their malware.
And the interface was superior, in my opinion. No idea how good / bad the presenter UX is, though.
I also use https://addons.mozilla.org/en-CA/firefox/addon/zoom-redirect... to fix up the URL automatically.
They made that very hard by pushing their desktop app. They also broke audio on Linux very often. Another long running bug is that after you've muted yourself in the meeting for long enough they start to think you did not give them microphone access and refuse to let you unmute yourself.
Link: https://apps.apple.com/app/presentify/id1507246666
Disclosure: I made this app.
Why? Just uninstall Zoom.
I ended up having to go to a computer to connect with using a browser.
The last thing the world needs is yet another 99 section 10 chapter law by clueless lawmakers.
I don't understand how you can legislate against this without also banning a bunch of legitimate use cases.
No affiliation.
But really, much of Teams was built upon Skype, and that is the dominant market player by a long shot.
Do you have any source on that?
https://twitter.com/Carnage4Life/status/1558054445237149697?...
The graph doesn't include Zoom or Google Meet, so is not a perfect representation.
They left Linux users in limbo, while Zoom worked for everyone.
They couldn't handle more than a couple of people in a call.
They also had Lync which was rebranded as Skype, so you also had other bad software masquerading as Skype which wouldn't have helped their image.
You couldn't share a meeting URL and have the call in a browser for the longest time.
They only started to try again after Zoom picked up being the default word for video calls.
That's when I switched away.
Sometimes you end up with something quite decent, sometimes there's no one with enough power in the company who can rebuild it properly and it's just trying to make a stone out of sh.t.
If you are trying to do it properly from the start you are in a lost position. You need way more time, more money and better people to end up with something that looks the same for an average user (in most cases, for a few products it may pay off). You iterate more slowly, and you can be copied before you acquired enough user base.
I hate it. Marketing wins over merit everywhere currently.
Bad software that solves my problem now is almost always going to beat great software that might eventually solve my problem.
Just as in coding, when you have a problem and you're stuck, you look for a solution. But it's very hard to learn that there's some better solution to a problem that you've already solved.
There are many video chat sites, all free for small groups and without the need to trust some random company that wants to execute code on your machine.
If when you join a call (without zoom installed) you click the download button, then let the zoom installer start downloading, then press the “I had problems installing” (or some phrasing to that effect) button, finally the join through the browser button appears.
Yes, you have to download the zoom installer executable every time you want to join a call.
Also to make the join via web easier you can try something like https://addons.mozilla.org/en-CA/firefox/addon/zoom-redirect...
For a long time you couldn't use your microphone in Firefox.
We use Google Meet for everything but those meetings, because Google is still lacking on that aspect. At least they added breakout rooms and polls, but there's still work to do, like preconfiguring polls before the actual meeting takes place, etc.
MS teams I think worked once.
Skype is ok.
Zoom works every time.
Want people to use something else? Make a thing that works.
Edit: if you have also had problems with everything besides Zoom have you also ever held a security clearance with the US government?
Didn't work (Linux, Wayland even). We switched to discord for the interview.
Uninstalled zoom, never installed it again.
All my clients use alternatives and I am sooo glad.
I should clarify: my clients range from multi billion dollar companies to small to medium sized ones.
The big ones use teams or such, the smaller ones are more flexible
Wherever we can, we use jitsi
Hangouts Google Meet Skype Zoom Teams
Also, Wayland had issues years ago, that may have been related to the issue you experienced.
We even tried X11, just to make sure... No idea why I mentioned wayland, I blame it on the temperature, sorry!
If anyone asks me when I’m on my phone, I tell them I don’t trust Zoom.
I know Windows has its issues, security and otherwise, but they actually did have some insightful prescience on this class of problems.
An admin user in MacOS is always in sudoers though.
The only video conferencing software I have installed is Chime [1].
[1] yeah I know. How do you say where you work without saying where you work.
Zoom has some of the most archaic security practices I have seen in 2022. It really practices security like it's 10-15 years behind a modern company. Almost all top-down initiatives to improve security have meant useless red tape practices such as hiding information from its own internal developers.
source: I work at Zoom.
That doesn't sound like outdated security practices, it sounds like unconscionable bullshit.
And yet we keep wearing those handcuffs, maybe out of laziness or a habit.
The management of proprietary software is a frickin' minefield. The idea that publishers should be trusted to manage their own installations like this is madness.
(Zoom should just be an App Store app, not a crappy installer.)
You need to use something like portals like Flatlak does. But the Flatpak sandboxing model is clearly inspired by macOS and hated by a significant portion of the Linux community.
And Linux users can typically expose themselves to the same shit as Mac users with Zoom here: when they grab proprietary DEBs for Discord or Google Chrome or whatever, those can run scripts that mess with the whole filesystem or call out to the internet at install time. It's only by convention that those behaviors are forbidden in the normal repos on most distros.
I don't love that the only repository-like option that's part of the normal system is the App Store, or that it doesn't come with an official CLI. I can see how some small proprietary software authors trying to make a living might resent being funneled toward a platform where Apple takes their cut, and I empathize. But for end users, I still think centralizing app updates into one system and taking the implementation details out of the hands of app developers/publishers is the only thing that makes sense, even if that always means going with the App Store.
Just allow them to do anything, but isolate the environments such that it doesn't matter if one is compromised, because there is nothing to compromise other than the application itself.
Strongly recommended if you're willing to live without GPU support.
I'd rather have my mom use auto-updating chrome than having to remind and reteach her how to update chrome manually once a week.
Zoom and Mac are perfect for eachother.
Every time I have to relaunch FF after updates, the Zoom webpage forces me to download their installer (which I delete without using), and working their way through the dark pattern UI BS to get to the 'launch in browser' link to appear.
https://addons.mozilla.org/en-US/firefox/addon/zoom-redirect...
Check the screenshot. You just need to edit the "/j/" part of the path to "/wc/join/".
Let's face it, I'm about to join a Zoom call. How much faster do you really think I'm trying to get to it? This is actually one of those dark patterns I don't mind.
its open source so if ya dont trust this installer either, grab it from GitHub, its only a few lines of code :) hopefully others find it useful:
https://chrome.google.com/webstore/detail/zoom-web-launcher/...
This is beyond absurd.
In his essays, Paul Graham talks about this. If you are a company with no software brains at the top, the only way of getting ahold of competent programmers is luck. And business founders generally ruin their own luck.
The FBI have previously issued warnings[1] about Zoom “accidentally” routing calls through China and for “accidentally” allowing CCP officials to monitor and end calls made outside of China they don’t like[2].
This is just the latest “accident” we’ve found out about. You’d be a fool to think there won’t be more.
1. https://www.fbi.gov/contact-us/field-offices/boston/news/pre...
2. https://www.washingtonpost.com/technology/2020/12/18/zoom-he...
Even the best programmers constantly make these mistakes in large code bases.
Contrary opinion: I'd rather have a world in which everyone is always root on their machine and trusts all their software --- regardless of how mistaken that trust can be --- than the current trend of using "privilege separation" to take away freedom and control, create walled gardens, and silo applications from interoperating with each other. I have had little care for privilege escalation "attacks" ever since I realised that in practice they are so common, and also quite harmless (or sometimes even freedom-enabling), that it's often a way to feed the security-paranoia news machine and further drive users into the increasingly restrictive regimes of non-general-purpose computing.
That said, I didn't install Zoom, but rather use a standard SIP client to join. As others have mentioned, using a browser is also possible when SIP is not an option.