Makes the story MUCH worse in my opinion. An unpatched RCE that they left open until someone else got 90% of the way there and went public with it.
Being my OS or hardware vendor does not entitle you to permanent RCE on the machine that now belongs to me.
Unless of course this is just a XProtect rules update or a Gatekeeper CRL update, then ignore what I said.
That makes this server at least doubly malware. And "vulnerability" understates the case: a negligent implementation that utterly disregarded any security concerns should be considered beyond the pale. That times 1000 for a major software vendor like Zoom.
The server itself was deliberately added to work around a Safari security feature, that was designed specifically to prevent what they wanted: allowing arbitrary web content to open an app without user consent. They literally added an always on, persistent server, to avoid a security dialog
FWIW, I don’t think there was a uninstaller? What I’ve seen people describe is that dragging the .App file to the trash wouldn’t remove the server, since it was installed in a different folder.
There was no uninstaller until the Zoom update this week added an uninstall option to the menu.
MacOS users expect an app that does not come bundled with an uninstaller to be "uninstalled" by dragging the .app bundle to the trash. This generally leaves behind metadata, but that is not a big deal as it is just data - not code.
Leaving behind code that continues to execute after the user has removed the application without an option to uninstall it is obviously something that never should have shipped in the first place from a customer trust perspective.
If I drag photoshop to my trash instead of using Adobe’s uninstaller, I’m pretty sure that leaves Creative Cloud junk running on my machine.
Now, zoom did mess up by not having a proper uninstaller shipped with their app, I think a lot of other Mac apps do fail at this too though.
There is a real problem many (often primarily windows) apps have this bizarre desire to “install” content randomly scattershot across the OS. There is no reason to do this on Mac OS. OS X happily supports multiple binaries and services per bundle.
If you write an app that needs an uninstaller on OS X, and you aren’t needing to install some kind of driver, your app is doing things it should not be doing, and does not even need to do.
Apple should probably implement an API that allows developers to tell the OS what other stuff should be removed if the app is dragged to the trash.
To prevent devs from removing other people's stuff, you could require that the subcomponents need to be cryptographically signed with the same key as the main app bundle.
edit: or, even simpler solution (potentially) - have a fairly basic API via which devs can install subprograms elsewhere on the system. When you use this API to install something, it adds the thing installed to an OS-level registry. When the user drags the app to the trash, the OS checks the registry and removes anything that was added by the application.
Then the system will automatically disable the login item if the app is removed.
Edit: It seems like Zoom was using a login item, but using the "shared file list" API instead of the newer (but still dating back to 10.6) SMLoginItemSetEnabled.
An alternative is to just make your daemon check for itself whether the main app has been removed, and delete itself if so.
There are apis to register for launch, there are launch service plists, etc which all correctly, and by default handle the user deleting your app bundle.
There are already “cryptographic mechanisms to detect modification of your app”, it’s the platform code signing mechanism, and Xcode will produced signed binaries by default.
Finally, your post comes across as saying that you believe leaving the server was unintentional due to lack of APIs (ignoring that removing an application is a sign that the user doesn’t want your app to run any code). Their “unintentionally” persistent server explicitly check for the app being removed, and if it had been, would redownload it and install it without user consent.
But again, this was deliberately subverted by the client copying the server out of the app package and into a hidden folder in the user's home directory. Again, this is an intentional choice mimicking malware: the only reason to move the server binary is to break the standard app removal process.
But I maintain that the smoking gun for this being intentional is that the server will download and reinstall the client software, which only makes sense if you expect it to run when the user has uninstalled/removed your software.
So yes, malware.
A piece of software that lets any website activate your camera without your permission is a security vulnerability.
Then you should call Chrome a malware because there were vulnerabilities with remote code execution (and there will be similar vulnerabilities), so every website could install anything. But that is absurd.
> The result is that unless you like for random websites to be able to activate your camera without your permission, it did harm users.
First of all, you need a hard data that this vulnerability was exploited in the wild. Otherwise it did not harm users, it only opened a way for malicious websites to harm users. And, again, every vulnerability could be counted as a malware by that definition which makes malware term meaningless.
> Do you really think it was a “bug” that it reinstalled itself?
It is intended behaviour. And I don't see anything drastically bad with it. If you're opening their website with corresponding link, you want to use that service. In order to use that service, you have to run additional software and they are making it easier for you to run it. Only a few years ago every browser supported Java Applets and with Java Applets every website could run arbitrary code on your machine. And that feature was actually used a lot. Does it make all services which used that feature to overcome browser weaknesses malware? I don't think so.
They probably should have communicated better about that aspect and provide proper uninstaller software for security-concerned users. And not making those vulnerabilities in the first place, of course. But world is not perfect.
So would it also be okay for a credit bureau to post all of your information to a website? Would that be okay until it was “exploited in the wild”?
Are you really saying it’s okay to run knowingly insecure software until there are reports of it being exploited?
Only a few years ago every browser supported Java Applets and with Java Applets every website could run arbitrary code on your machine.
Java applets ran in a sandbox.
I'm not saying that it's okay. I'm just saying that it's an overreaction to call their software malware.
> Are you really saying it’s okay to run knowingly insecure software until there are reports of it being exploited?
Yes, it's okay. When Windows security team receives some vulerability report, they do not shut down all Windows systems in the world until the bug is fixed. Those systems continue to work insecurely until they got update.
> Java applets ran in a sandbox.
Not quite. Malware is short for "malicious software" and malice has a specific legal definition: the intent to harm. By your standard, removing a Mac system daemon only to have it re-installed by a software update would classify the entire OS as "malware" - which is an unfair, emotionally-driven characterization.
Perhaps it’s a staged rollout, but at least on my iMac there’s no sign of updated signatures.
They also ship silently via system_installd, you’re not going to see anything in the software update GUI
Seriously though, they should have owned the mistake, apologised and reversed their decision rather than handling it with a PR spin. It is a great product but somehow it has left me with little trust for zoom. It's probably still not too late.
Does anyone know if bluejeans et all are also removing this? Or does it require public shaming, like the zoom case?
Apple has its share of evil. Another example is preventing people from repairing their own Apple devices.
No. What gave you this idea? iMessage is end-to-end encrypted. The keys are managed by the devices themselves. There is no facility to backdoor or intercept the messages.
Apple acts as a registration server, notifying your devices when a new device signed in as you joins the pool but the devices themselves tell you when this has happened. That’s all client-side. If the server didn’t tell the client about a new peer it would never encrypt a copy of the message for that peer and that peer wouldn’t get the messages.
That is only a half-truth. Apple controls the key infrastructure; they may replace your keys with arbitrary ones at the demand, coercion or compromise by any number of bad actors. The software is closed source, making it impossible to verify any actual claims made otherwise. If they truly valued privacy, why not open source iMessage, allow users to verify iMessage keys, hire an independent third party to audit their infrastructure, or all of the above?
Moreover, Apple has moved iCloud infrastructure to Chinese data centers to enable spying on millions of innocent people. They have removed apps from their store which circumvent Chinese censorship. These are truly shameful acts which has appropriately drawn criticism from human rights watch organizations.
I would say that what Zoom did was have their app intentionally install malware that bypassed this normal uninstall.
I do think that it would be great to have a more thoroughly sandboxed idea of what an “app” is on the desktop, though.
Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled. The downside to these is they don't track files created at runtime so a lot of the config or cache files created can be left over if the package itself doesn't remove them.
> Even the regular Linux package managers like apt, dnf, pacman track which files were installed by which packages, so they can be removed when the package is uninstalled.
Technically speaking, Zoom could have abused dpkg post-install scripts, or pulled similar tricks, to install their malware server and leave it behind after the package was removed. Linux distributions aren't invincible to these shenanigans.
This is correct, but such a package should not make it into the distribution's package repositories.
How would this work with apps that create things that a user would expect to persist, like downloads (kept after uninstalling a browser) or office documents (kept after uninstalling the office suite), or media production apps, IDEs, etc.?
It could have some rule like "let it be if it's in the user home directory" or "only remove stuff in these system directories" but it seems kind of fragile, like what if you use a text editor to create a system config file and then uninstall the text editor?
I can't see how it would. Making the uninstall remove all the files created at runtime is the wrong solution to a real problem, which is better solved by forcing all packages to be self-contained and making their installation an idempotent operation. If we're able to do this, there's not much to clean up afterwards, and we ensure there's no privileged malware left (such as Zoom's one) as both the package install scripts and runtime would be able to run unprivileged.
I use NixOS, an OS built on Nix, a functional package manager that does this, and being able to set my system to a known state without going through the steps of formatting and reinstalling is really nice.
Does the ZoomOpener app have malicious intentions towards you, your computing resources, or your data? Not just “could it be unintentionally exploited” - note the unintentionality! - but specifically “this was intended to harm”.
If not, then you need to reconsider your use of the word “malware” - a word shortened from “malicious software” - and find a better way to describe software design patterns that aren’t compatible with “drag it to the trash” but also aren’t intended to harm.
Adobe Creative Cloud, any $$$$ audio software DRM, and HP printer drivers all use similar patterns of “can’t just drag it to the trash”, and are all similarly annoying to remove - but they are not malware, any more than this ZoomOpener is.
And Windows does? Uninstallers are completely at the behest of application developers. No consumer OS but iOS actually provides any sort of true app level sandboxing.
Control Panel “add and remove programs” usually works?
There’s no equivalent on Mac. Yes, dragging the app to the trash is a thing but that leaves behind content in ~/Library/caches, ~/Library/Application Support, and ~/Library/Preferences . It’s been somewhat of an issue with Mac ever since they first put a hard drive on the original ones back in the 80s...
Edit: I literally cleared several GB of junk out of my application support folder left behind by just one app today, so it’s fresh on my mind. OmniDiskSweeper is great for finding this stuff.
All that does is launch the app’s uninstall process. The app is free to leave whatever crap it wants to on your system.
And why is it filled with stuff from Apple programs?
Citation needed. That was the case in the 90s, these days most apps (device drivers aside) uninstall fairly cleanly with only settings/configurations stored in the registry still resident afterwards. Startup programs remaining after an uninstall is straight-up a bug.
Instead an installer is driven by a number of "database" tables that specify the installer actions in a declarative way.
There are several benefits to this approach. The declarative actions are reversible and the uninstall actions can thus be inferred automatically. This removes the burden on install authors to create a script to reverse the install operations.
This includes registering services/daemons (will unregister on uninstall), registering protocol handlers, filetype/program associations, desktop shortcuts etc.
The declarative approach also allows the installer to roll back in case of an error during installation. This even includes "undeleting" files that were deleted. (https://docs.microsoft.com/en-us/windows/win32/msi/rollback-...)
The author of the install script can (non-Store installers) escape and execute a specific program during the install process. This is rarely needed, though. So the default is that the uninstaller will uninstall by completely reversing the install actions.
Also, Add/Remove only works if the program adds itself there. And remove only works if the program added an uninstaller. Also, even then, it still leaves crap behind.
iTrash  is also worth mentioning. It uses the Levenshtein distance algorithm  to find all of the junk related to an app.
What do you think about this one?
Zoom is even available in Flathub, and that's how I use it.
Android does, too.
I mean, maybe you need a "user data" bundle of sorts tied to the specific application. If you delete the app, it deletes all the user data bundles as well.
The default installer and bundle runners should be controlling the process. "XYZ App is attempting to write data files outside of its bundle location. These may not be cleaned up if you delete the application. Do you want to continue?"
The unix permissions system and the Mac bundle format should completely solve this problem. I honestly just don't get why this still happens. Doesn't iOS at least get this right?
There is already a concept of a "user data" directory for the app, which is determined just like on iOS. There are also other directories for things like caches that the system can clear if it's low on disk space.
Of course they could sandbox Mac apps just like on iOS, and Mac App Store apps essentially already work that way.
I can assure you, though, that any barrier they put in the way of letting non-App Store apps run however they always have will be met by strong resistance. It's easy to point to this occurrence with Zoom and call it unreasonable, but prompts like what you're describing will undoubtedly disrupt what other people see as totally valid use cases and ruining of the UX.
 By "things", I mean things like a separate web server process. Apps do store files in app-specific folders like "Application Support" by convention, but not for separate processes.
But what I don't get, why even have an "Application Support" directory at all. There is absolutely nothing of value added to me (as a user) to have files stored there. It's just one more place I have to look to clean up after an application is deleted. So dumb and adds zero value.
I'll put my files into Documents (or whatever). And you (as an application developer) put your files in your app bundle directory. That should be the contract for most (all?) user space applications.
I agree my prompt idea is generally poor and wouldn't work, it was mostly just for discussion purposes. But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.
The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support").
That would include mostly anything the app persists to disk that the user didn't explicitly choose, like an sqlite database or something.
> But the mechanics of a fix for this are in place, rogue daemons that can't be deleted are just unacceptable.
I see where you're coming from, but I think this is really the only balance Apple can strike here. That balance is essentially that non-App Store apps/installers are not sandboxed and can mostly do whatever they want, but Apple can step in with X-Protect (like they did here) and remove anything egregious.
They've also moved forward recently with the concept of notarizing, which will still allow apps/installers to do whatever they want, but they'll at least need to be validly signed by a verifiable private key that Apple can then revoke if you (as the developer who signed things with it) do anything egregious.
Again--it seems unreasonable in this case, but there are undoubtedly numerous very popular unsandboxed Mac apps that do sketchier things for more valid use cases. Any prompts or restrictions are going to be very disruptive and prompt a new wave of blog and HN posts about Apple trying to kill app distribution outside the App Stores.
> The bundle isn't normally writeable by the app itself. It's generally good security practice to not have your app capable of rewriting what itself can do, and iOS is the same way. You can't write into your app bundle, so anything at all that you want to persist needs to go somewhere else (typically in "Application Support").
I don't buy this. If you are writing "anything at all" into Application Support, this is no different than writing to the bundle. An executable binary written into Application Support is just as effectively the same thing as an executable binary written into the bundle itself. I don't see a difference between a program rewriting its own code vs. writing an executable into another location.
There's no added security and no added user value to writing into Application Support vs. the App Bundle itself.
Not arguing with you, I appreciate you explaining the current state and conventions. Thanks for the discussion.
And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.
By design choice user data of any App should be only be readable and modifiable by the active user. If user data is stored somewhere under home folder, this mechanism comes for free for the App developer and the OS handle it. If you want that same level of privacy in the App Bundle developers would have to handle it themselves (and well).
But then what happen when you uninstall ? Either you are blocked because you can’t remove data from another user or you somehow require escalation to admin privileges to remove data of all users at once. Which might or might not make other users happy if they were unaware of the uninstall...
With current data model choice (pretty much shared across all UNIX world and even Windows). If user A delete the App but user B still needed it you just have to reinstall to keep user B unharmed.
Your proposal is not bad to optimize for disk space gain at removal, it just happen that (quite rightfully) OS vendors chooses to rather optimize for data persistence and security.
This doesn't work well for a few reasons:
- The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app.
- Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image.
- If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk.
- It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature.
- If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two.
- If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.)
> And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well.
- What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle.
- What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data.
- Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters.
Applications should be treated as hostile, just like a user is treated in a multi-user system.
I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out.
I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem.
In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download.
It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.
However, the OS should perhaps insist on a particular location within "Application Support/" that each app can write to, and when the application bundle is deleted, provide a way to delete those support files as well, either for that user alone or for all users within permission (can be a system-wide configuration).
Your second paragraph though is probably closer to a realistic solution. That is, the OS provisions an Application Support directory and restricts the application to using it exclusively. Any application uninstalls can (via admin prompting or configuration settings) then also delete the support directories as well.
As an application developer, I want to be able to drop a new bundle over the old version and NOT LOSE ANY USER DATA. The only way to do that is separate them completely.
- You want to uninstall/re-install an app without removing the application's data
- The application's data can become large (think raw audio or video libraries) and users request to store it in a separate disk
- Users want to personally organize the data they make with your app (by project, client, personal/work, etc.), or use it with other apps
- Your "installer" is just a zip of the .app bundle and there is no obvious opportunity to assume admin privileges make the bundle writeable
Most of these could be solved by having a separate "sandbox" a la iOS or MAS that can be moved or, at the user's option, remain on disk when uninstalling; as far as I know neither system offers these capabilities.
For example, Steam games stored in Application Support. Why?? If I install a game from Steam, it should be installed somewhere in the Steam app bundle. When I delete the Steam app, I delete everything related. So dumb.
They clearly could have made other choices and they have their own logic, but that clearly not on Apple role to oversight how their concurrents operate.
Antitrust, geeks and media network would instantly gather pitchforks to run on Apple if they even dare to hypothetically mention it.
If you uninstall a .deb or .rpm or AppImage, the files you wrote into XDG_CONFIG_HOME (defaults to ~/.config) won't magically get cleaned up.
I'd love to be wrong here, BTW! I've had several PhotoStructure users try to reset their configuration by uninstall/reinstall, but that just removes the files in the installer, it doesn't do anything to files in user directories (and I'd be really surprised if that was ever a thing). Can you imagine the havoc from `apt remove vscode` and having it remove user's keybindings, extensions, and anything else?
Isn't this what apt purge appname does ? or is something missing
Form the apt-get docs:
purge - purge is identical to remove except that packages are removed and purged (any configuration files are deleted too).
If you do that, the entire system stops working. Everyone will just click "ok" and then still gets mad when uninstalling doesn't fully clean things up.
Maybe the app bundle runner should be logging files written outside of the bundle folder? Then the uninstall process will wipe those out?
Not even Apple follows that ideology though, I can't be the only one who has had to delete the gigs of Garageband data from ~/Library/Application Support on an under-specced company laptop 128GB SSD
If we are talking about OS updates, OSX has the same thing.
You are not required to use Windows Installer. And even if you do, you are not guaranteed that everything will be removed, be it due to malice or incompetence.
Not even Linux can guarantee that. Something like the Nix package manager would be closer to what's required. Plus a sandbox.
> This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enables users to avoid this extra click before joining every meeting.
Edit: Once you consider social sites with user-submitted content, like reddit, it might be best if you’re prompted every time.
So I think you could argue Apple might want to let you override that, I don't know what the language is and whether there's a "click here to skip this next time" box on the dialogue. It's possible they got the annoyance versus security tradeoff wrong.
But imho they didn't break the correct behavior any more than Microsoft "broke the correct behavior" of privilege escalation by adding a dialogue box with UAC in Windows 7 .
well, it did a shitton didn't it ? to this day, most people I know disable UAC because of how annyoing it is.
I've been out of the MacOS app dev scene for too long, it seems.
The developers in this case didn't bother trying to use it.
Anyone know of other sneaky apps to avoid?
To do that you need IPC, and a JSON endpoint is the most popular form of RPC. If the server listens on localhost, I don’t see any issue with it - any issue you would have with IPC, you would have with this style of of RPC.
Now they could have provided a library to communicate directly with the keyboard - but I think the drawback was games developers didn’t want to integrate it into their games.
This is the real problem behind all of these cases of "why the heck is tool/driver/app/whatever X running a web server locally?" - the market is full of developers only knowing HTTP, and when someone just has a hammer, every problem looks like a nail.
There is a real shortage of devs who know about all the other IPC techniques supported by modern OSes (of which practically all of them are much faster, lower latency, less overhead-y, more secure and come with less unintended side effects than a local web server).
Not as serious as leaving an httpd around and then letting sites to hot mic you with it -- obviously -- but on par in terms of a few select adjectives.
Wonder if the LitteSnitch list of procs had the Zoom Daemon.
For cripes sake...
The sandbox only applies to software devs that want to use it or those that wish to sell through the Mac App Store. I don't think Zoom is in the MAS at all (I don't see it in a quick search anyway), and a standalone installer is free to do whatever it wants and can convince users to go along with (up to and including, in principle, bypassing SIP though since that significantly raises the effort bar I've only ever seen niche stuff request it). And it's completely legitimate to want to run a server on your system too, there is no hole. Zoom simply acted as malware, taking actions without user permission.
Future versions of macOS will require signed software (notarized as per Apple terminology), even outside of the store.
What is new in security at WWDC.
I haven't looked enough to understand what is gained by notary. Does Apple want to search your binary for maliciousness or rulebreaking (potentially even at a later date) so that it might revoke the notarization/signature?
"Advances in macOS Security"
"All About Notarization"
Some of this stuff seems a tad disingenuous. Like preventing debugging. The debugger APIs on Mac already pop up a password prompt, limiting the usability in malware (and actual use, like trying to debug over ssh). Meanwhile, a culture of producing separate binaries for debug and for end users (debug builds lacking optimization, allowing additional permissions) is in my experience a great way to fail to reproduce legit customer-facing bugs during development and have greater difficulty diagnosing them when they occur on a real live user machine.
A path similar to how Windows 10 is now converging the Win32 and UWP sanbox models, or how ChromeOS sandboxes GNU/Linux processes.
I do not see where this is mentioned.
Many open source projects will not participate in this.
If this kills brew you will also loose a lot of devs.
Neither do game consoles or the large population using Windows based systems.
I never cared for brew on the occasional moments I get to use Apple computers, XCode and default tooling is more than enough.
Which is like what the large majority of developers targeting Apple devices actually care about.
I personally don't use Homebrew, et al. but, I have a Linux VM which handles that stuff pretty well.
I didn't develop a Mac specific "application" though.
On my Mac circle it is all about store apps and Web apps (Java/.NET Core based).
Then again, I only hang around with Mac devs that target iDevices and macOS, using Objective-C, Swift, C++ and Web.
There is still the same control-click to open non signed software and there is still no aggressive permission model outside of the App Store.
Firefox was broken on Catalina for a while, even though the main app was notarized. Some internal binary wasn't notarized, and no amount of control clicking would get Firefox to work until Mozilla notarized everything in the build.
sudo spctl --master-disable
I have a Raspberry Pi for hacking, I'm happy to root the hobby computers, not the work ones.
It seems like this conflates the notion of having root privileges with turning off security. There is no meaningful connection between the two save in situations where there is no meaningful way to control said security layers save destroying them.
For example refusing to boot a bootloader that isn't signed doesn't require your oem to hold the only possible key that can be used to sign said bootloader.
But Flatpak! Flatpak applications can be sandboxed and you can install/remove applications as one unit.
If so, it doesn’t seem much better.
Something an app store due to volume and default allow pending mostly automated checks has a problem with.
the problem in this case is that the developers just couldn't be assed even trying.
This is false. Kernel extensions can be part of the application bundle and will be unloaded and removed when the bundle is removed.
Installing KEXTs in an application bundle allows an application to register those KEXTs without the need to install them permanently elsewhere within the system hierarchy. This may be more convenient and allows the KEXT to be associated with a specific, running application. When it starts, the application can register the KEXT and, if desired, unregister it on exit.
For example, a network packet sniffer application might employ a Network Kernel Extension (NKE). A tape backup application would require that a tape driver be loaded during the duration of the backup process. When the application exits, the kernel extension is no longer needed and can be unloaded.
You can also launch agents that are part of your application bundle:
It is true that you cannot remove application data, but that is a feature (maybe users want to retain the data) and also does not happen in e.g. Linux package managers.
Apple also makes a fantastic computing platform with very good mandatory isolation, namely, iOS. If you're interested in isolation in preference to compatibility with traditional desktop software, an unjailbroken iPad Pro with Smart Keyboard is a pretty good option.
Remember old school Mac was full of hacks upon hacks upon hacks, many by third parties, and there was cool stuff in there too. The App Store mentality has caused everyone to overreact and think that every third party app on the planet will turn into the worst conception of Win98 era malware overnight if unconstrained, when this is just one outcome among many possible.
So that said, I checked, and it removes everything zoom installs that isn't in a user directory, plus (there is an extra script that does this):
Note it removes logs from .zoom, but not the directory itself. Which is good, since there might be user data in there (chat logs, and recordings).
Unlike Macs, there is no hidden webserver.
There is also (yes, it's commented out):
#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
Kudos to Apple for nuking this malware.
Strong work Apple.
They're blocked in my little snitch anyway so no problem.
From there you can manage the updates manually from the command line with the `softwareupdate` command. e.g. `softwareupdate --list --include-config-data` will show available updates, `softwareupdate -ia --include-config-data` will install them, etc.
It's no different than a virus scanner auto-updating its signatures.
I figured.. this has probably evolved already to an acceptable situation.
So the calendar invite came in, I started up zoom to see what it would do. There's an update available, where zoom says they're abandoning the local web server.
Upgraded, should be good for tomorrow.
Came here, noticed the "softwareupdate -i MRTConfigData_10_14-1.45 --include-config-data" command and ran it. Checked last update -- back in June, to 1.42 ...
Updated that, ready to go.
Business continues, maybe I'll delete zoom another day, but not just yet.
Another application I've been running for years won't start-up anymore and is logging:
> Thu 11 Jul 2019 23:12:59 AEST Waiting for web server to come up
It may be coincidental, but would be good to know what Apple changed.
Many users are unable to enable Video feature even after applying recent patch released by Zoom. Also zoom has become security joke/conversation topic while starting a con calls!
How many such apps am I running that I don't know about? And how many of them are exposing my system to malicious web sites, or to curious people in my office on the same subnet? I wish I knew.
I think I'd be happy with a popup once-per-tab asking me for permission for a web page to talk to a local web server... Might even be okay if it's scary (Are you a developer?)
Edit: Apparently there is:
I currently have a separate limited user account just for meetings, and that’s where I install various meeting apps. So in my case is there any way to know if Zoom or WebEx would install stuff on all accounts?
If we can’t trust an app that is the cornerstone of a 25 billion dollar business (Zoom’s market cap) not to install malware, then I don’t know.
I want the trust through the App Store.
PS. I love Zoom, and find it to be the best conference solution out there.
Zoom’s initial response to this incident was shameful. They basically said “that’s how are app works. F U”
I am moving away from Zoom.
Any suggestions? Preferably open source
Afk rn so i might be misremembering the name of the setting.