I couldn’t tell from the article if the author had actually tried Catalina. I have been running the beta since day one of the beta release and the only issue is that applications have to be signed or built locally.
Apple wants macOS to be a safe walled garden like iOS and Chromebooks. I am fine with this, but I also have a very nice Linux laptop to play with.
I expect organized crime and most governments to continue hacking activities so it makes sense having my Apple devices locked down as much as possible. I avoid arbitrary web browsing on my Linux laptop and just use it for coding.
Hello! I am the author, and no, I haven't tried Catalina because, as I state at the very end of my article:
"Both my main Macs are really working flawlessly at the moment, and Catalina is beta-quality software that’s likely to give me headaches I don’t need right now. Who knows, maybe down the road I could acquire a cheap used Mac that can run Catalina (something like a 2014 Mac mini) and use it as a test machine. As things are now, I absolutely do not want Catalina to mess with my current setups and data."
I'll add — I'm in a position (work-wise) where I can't afford to risk Catalina messing with my current setups and data.
Can you give me the TLDR version of MacOS Catalina’s downsides? Apart from mail layout change of course. I tried to read your blog but it was too difficult to find the points you were making too much rant with actual points hidden here and there.
Personally for me this has been the smoothest upgrade ever! Literally no apps are broken and no data lost.
I think OP got confused and gave an example of how allegedly browsers on Linux are more secure because there is no DRM (because DRM to an extent allows another party to control what your computer can and can not do, through an unvetted binary blob). But even then they are wrong, as DRM works on browsers running on Linux.
He's right in that Disney+ doesn't work on Linux however, as it uses Widevine L1, which isn't supported, and which I doubt will ever get supported. I personally expect Disney+ to allow L3 eventually, which is supported on Linux, as it's just software based.
Unless you're going out of your way to run your browser in a container or dedicated VM on Linux, there are substantial risks associated with browsing the web in terms of exposing all of your information in /home, which might include ssh and pgp private keys, basically everything your user can access.
But we have a number of solutions for running things in containers if you just use them. Early on firejail was popular, these days I just run nspawn containers for browser instances and bind mount in some stuff for a shared Downloads directory etc.
I can't speak to how that compares to OSX as I've never used it, but it is worth noting that the security story on Linux can range from bad to somewhat OK depending on your setup.
Edit:
In responses people seem to be completely ignoring that I already stated above in my original comment that I can't speak to how it compares to OSX. I don't know what OSX is doing for application sandboxing defaults.
I can however speak with some authority on the Linux situation. And today, if you're running firefox/chrome as your regular user as installed by apt/yum etc, without any additional sandboxing, and that user has access to secrets like ssh/gpg private keys, you're being unnecessarily reckless. And unfortunately that is basically the default way browsers are run today on most distributions
This is a major reason why the Flatpak/GNOME people have been working so hard on portals and namespaces are an integral component of the runtime. It's not just about application distribution. They're trying to close a major security hole in desktop linux as it's often used today. They want applications like the browser run in its own namespaces with just the minimum of host filesystem paths bind mounted in.
There's absolutely no reason for your browser process to have the ability to access all of your private keys, just because they happen to be under the home directory it happens to have access to, full stop.
> substantial risks associated with browsing the web in terms of exposing all of your information in /home, which might include ssh and pgp private keys, basically everything your user can access.
What are you talking about? You're saying that a random website is given unrestricted file access to everything the user can access. Can you back that up with a concrete example or a link explaining the issue or something?
We've had plenty of browser exploits for any given browser, sandboxing the entire program a la containers is the most effective mitigation outside of running it in a dedicated vm.
What does the possible existence of exploits have to do with macOS being more secure than Linux? macOS can also have exploits.
I don't understand where your claim that there's a specific risk of unrestrained file access to websites comes from. In my eyes, saying that it could be true because exploits could exist nullifies everything you said.
You could apply that argument to everything: There is a substantial risk in iPhones giving websites unrestrained access to making phone calls on your behalf because all it takes is an exploit.
Different OSes have different sandboxing capabilities.
Until relatively recently, Linux had effectively none, just chroot, and selinux which almost everyone disabled for a decade.
The point, which you seem to be missing, is that with generalized sandboxing tools like containers, you can isolate any application to limit the potential damage of application exploits.
It's a form of defense in depth. We must assume browsers have many bugs and are exploitable. Ok, from that perspective, what do we do to safely access untrusted input (the entire internet) with the browser on a computer we also do things like banking, private communications, and access privileged servers from? We run it in either a dedicated VM or more recently, we use sandboxing technologies like containers.
I don't understand why this is so difficult for you to grok.
Chrome was also found to be secretly downloading binary blobs for execution, we should not be trusting Chrome's sandboxing exclusively to protect us from the internet, we can't even trust Chrome itself. [0]
In-browser sandboxing is more for attempting to isolate tabs from accessing one another's state. It can't be relied upon exclusively for protecting the larger host from the browser itself.
One should really put the entire browser in a sandbox where it can only access data and functionality necessary for its operation. Nothing more.
How one achieves that, what tools is at their disposal, is greatly OS-dependent and that's the core of my point. On Linux systems, the out-of-box configuration for most distros is to just run the browser on the host with no sandboxing. It's not sufficient.
Flatpak is one of the active efforts to fix this. If you run firefox or chrome from a flatpak, it will be run in isolation, and accessing external host resources will be done in a controlled fashion via portals or explicitly enumerated mounts in the manifest.
As mentioned elsewhere, I used firejail in the past but now prefer systemd-nspawn containers, often ephemeral ones that are spun up and thrown away per browser session.
You keep trying to shift this conversation into sandboxing. Of course, any form of sandboxing is going to add defense in depth to anything. It isn't of any particular relevance to this conversation.
You said:
> Unless you're going out of your way to run your browser in a container or dedicated VM on Linux, there are substantial risks associated with browsing the web in terms of exposing all of your information in /home, which might include ssh and pgp private keys, basically everything your user can access.
You're saying that there's this particular substantial risk in this particular OS, in this particular scenario. When I ask for any details that can back it up, you reply "All it takes is a browser exploit".
I would hope it would be self-evident that that is no reason to think that the particular risk you mentioned is real, or at least any more real than it is for any other OS, for any other app, or in any other circumstance.
My only interest in the comment was determining if the particular risk is real, but now it seems it was just FUD.
It's not FUD, that person is telling the truth. Don't interpret it the wrong way though. Browser exploits are a popular 0-day on any platform and it is indeed likely the security situation on other platforms is just as bad.
I think the misunderstanding here is that you did not answer the actual question, which is, what makes Linux less secure in comparison to macOS? What you mentioned applies to all OSes, and does not answer the question.
Both Chrome and Firefox have support for sandboxing on Linux. For the security conscious, there's always the Xen/Linux Qubes distribution, which is considerably more secure than MacOS.
Yes, Qubes is a good option to providing a dedicated VM per browser instance.
Relying on the browser alone for sandboxing is problematic as the dominant browsers can't really be trusted. It's best to sandbox the entire program, in addition to their internal sandboxing techniques.
Except that that may not really tell you much. If you have a system that is working, and are worried that Catalina might make it no longer work as it did before, you don't learn a lot by installing on a new volume or virtual machine.
That's a risk inherent with any upgrade to any software. The answer is ultimately that you can't know without trying it on your system. The best thing you could do is to create a cloned backup of your drive or use time machine to restore it if it doesn't work out.
I'd hazard to say, that option is out of reach for most of the Apple user demographic. Instead most will be nagged by Apple to upgrade, upgrade and then there is no going back.
Countering a personal anecdote with another personal anecdote. Here's another: I've been using Catalina since release on multiple Macs and haven't had any problems. I'm also an extensive user of iCloud services, Photos and Drive are very important to me and if I had any issues with either I'd probably lose my mind.
One person is losing file site awful. One person finds out works isn't suprising, it just shows apple managed to release an OS which isn't buggy for every user.
"iCloud did <x> to my files" is not an anecdote. It's an assertion of software behavior. The fact that only one sample is being provided does not magically make it an anecdote. You can say the person reporting the bug is a liar, but that's not how quality assurance works in the real world.
Most likely the bug they encountered happens in a specific scenario, but regardless, "personal anecdote" or "it works for me" are not appropriate ways to respond to a bug report, let alone one about data loss.
I only have one Apple device (an iPhone), and even in that simple use case I have sync issues from time to time. It's mainly previously deleted things that appear back on the device (photos, reminders…).
Why would you try it? Some of us lose money when our machines go down. Apple is supposed to represent quality, but that hasn't happened in so long that if your machine is the machine you make money on, you wait to hear what other people are encountering.
Apple wants macOS to be a safe walled garden like iOS and Chromebooks. I am fine with this, but I also have a very nice Linux laptop to play with.
I expect organized crime and most governments to continue hacking activities so it makes sense having my Apple devices locked down as much as possible. I avoid arbitrary web browsing on my Linux laptop and just use it for coding.