For the technically-minded Linux is an option, but for everyone else Windows at least allows you to firewall off any domain you choose. Sure, you'll probably break Windows Update in some way, but the Windows kernel doesn't try to bypass your settings (yet).
I can't tell if you being extremely sarcastic or lack experience running both of these OS's...
They got used to the system quickly and used it for 4 years, until the OS went out of LTS and I told them not to use it anymore… but still, they have no idea what a terminal is, no tech savvy, but still used it for their basic use-case for 4 straight years without issue! I didn’t even have to help them after the initial install. Couldn’t have been easier.
If you're medium tech savvy then you run the risk of knowing how to break something but not fix it.
My Windows 10 install may be full of spyware I need to block, but the software works pretty flawlessly in comparison.
With the terrible state of Nvidia's drivers, my Linux install has kernel panicked more often than my Windows box has BSOD'd.
Reliability-wise, desktop Linux is boringly stable these days as long as you don't insist on the bleeding edge by using Arch or Debian unstable.
The MS Office situation has gotten much better with the rise of online office suite web apps, including Office 365, as well as professional desktop software like SoftMaker's closed-sourced and misnomered FreeOffice[1] that has great compatibility with files written in MS Office's formats.
Lack of Photoshop is a problem, but if you're doing animation, special effects or video editing work, Linux has you covered because companies release Linux versions of their workstation software like DaVinci Resolve, Houdini, Autodesk Flame, Blender, Lightworks etc.
A computer does what its owner whats it to do. And when Apple or another company is directing its actions, tells me that what I have is a rental.
Either relinquish control, or put it on the market with the real name. It's not a sale.
What happens when multiple features in conflict are both turned on is a classic UI problem. Quietly doing a compromise between them is the exact kind of opinionated default that I am talking about.
You don't know that for sure, unless you know exactly how the Apple side of PR works, there could well be circumstances where that would cause problems. At the scale Apple operates at they must come across all sorts of weird an unusual configuration combinations.
There are 0 reasons for enabling private relay and also configuring a VPN, yet that's what the user did. In any case this is documented and Apple provides instructions how to block it.
The issue here is thinking that the VPN subsystem and firewall subsystem and how they work are the product from Apple's point of view. They're not, they're just implementation details. For Apple the intended high level user experience is the product, in this case the UX of the private relay service. If they need to bypass some subsystem to achieve a better more consistent high level user experience then that's what they will do.
As an aside, I’d also like to subscribe to “No as a service”.
What is apple meant to do? Just not provide the service at all?
Because private relay is vastly superior to a VPN for web content, which is what matters to most users?
PF is not the thing that does actual networking, on any OS.
As far as I understand networking and firewalls like PF, you essentially have the lowest level, where the kernel/driver puts bytes onto the channel.
Then you have the various userspace networking interfaces for various transport mechanisms, TCP, UDP, QUIC, etc
Each one of those is doing
<transport protocol specific thing>
<send the bytes>
The <send the bytes> part is below where your firewall stuff is going to happen, so I'm going to guess (I have never written kernel level networking because that stuff seems like relentless misery) that it means that every transport implementation has to independently have some code that looks like packet_data = <build the packet>
if (auto firewall = current_firewall()) {
if (firewall->should_block(packet_data))
return E_BLOCKED; // or whatever
}
kernel_send_the_bytes_yo(packet_data);
Or something like that, all super super pseudo code of course.Anyway, if that general concept is vaguely accurate then that means every time someone brings up a new transport protocol that another opportunity for this to get missed. Not saying its good that such a thing is possible, or that not catching it is ideal, just saying it seems like a plausible path to this kind of bug happening - Hell, I'm not even sure it would be the first case of an OS missing PF, I have some vague recollection from the distant past?
If you've enabled Private Relay then it's doing exactly that.
My colleagues have implemented and validated firewalls on MacOS without issue.
With Mac, you can usually handle the user-space scenario. Not so much the kernel-space one.
That's what's great about Linux. You don't have to submit to somebody else's will if you don't want to. It takes more effort, but good things always come at some cost.
Apple is arguably engineering computers and OS UX "correctly," e.g. better for most people.
The problem being reported hear is a VPN provider (or their firewall rules?) aren’t interacting well with what is fundamentally another firewall/vpn.
I’m not sure what the usual expected behavior is when you have multiple conflicting vpn+firewall products?
Also as far as I can make out private relay isn’t a vpn? It protects http[s], and for https I don’t know if it operates outside of safari?
I appreciate the fancy language conspiracy nonsense, but please look at actual facts:
* this is not free - it is part of the paid iCloud services afaik
* it is opt in - you have to decide you want to use this, they’re not just hoovering everything, which gets to
* even if they were hoovering everything, unlike a vpn, private relay is actually private
If you are trying to conceal yourself, VPNs services are routinely found to be logging what they say they aren’t, and fundamentally all traffic through a VPN can be logged by them. Private relay is strictly better privacy guarantees for connections that go through it rather than the VPN.
This provider points out a reasonable issue: they have added rules to simply block some connections entirely, and it seems like PR should respect that - but as I said above, I don’t know what the usual expected behaviour for operating multiple VPNs and firewalls concurrently is?
finally apple documents explicitly how you can disable iCPR completely, regardless of user setting.
Not respecting the system firewall does seem like a flaw, but Apple has had a history of bypassing attempts at filtering network traffic. Firewalls have been blocked from working and Apple services have been made unblockable in later APIs. I'm not surprised in the slightest that Apple also bypasses your VPN to call home.
I don't know if this is a problem, though. If you buy Apple, you let Apple make the decisions for you, that's how the entire ecosystem is designed. You must trust Apple unconditionally and accept traffic sent home to adhere to their privacy settings, or you should not run macOS at all. Try to run Windows or Linux on it if you've bought your computer for the hardware quality, though the M1 makes that nearly impossible without sacrificing user experience.