4 ms·

(That tweet has been deleted by the Apple developer). Before macOS Big Sur / Catalina, many of these application firewalls - Lulu, Little Snitch, HandsOff, Tri

(That tweet has been deleted by the Apple developer). Before macOS Big Sur / Catalina, many of these application firewalls - Lulu, Little Snitch, HandsOff, TripMode, RadioSilence etc. - all used their own kernel extensions to effectively monitor and block any processes from connecting to the internet. Firewalls are system security softwares. And naturally Apple would prefer to oversee and have this in-built in their OS. Apple also wants to discourage kernel extensions on macOS (they have some good reasons - a poorly designed kernel extension can make the OS unstable; but mostly its about feature control with Apple). So they informed all such firewall app developers that their individual kernel extensions will no longer be allowed, and Apple had instead created an OS API specifically for their use case. (They described the features it would have and invited them to give their feedback). And so all application firewalls were forced to update their apps and use this OS API. But this API had an undisclosed, in-built list of Apple approved applications that no firewall was allowed to block. Someone created that list. Someone added that list in the system, and coded the API to specifically give them special privileges to bypass any application firewalls. Bugs are accidental. Backdoors like these are intentional. (You can however take exception to the usage of "Backdoor" here - perhaps from Apple's perspective it was a good design decision as many of these services go wacko, and sometimes even freeze your system, when they aren't allowed to do what they are coded to, like do some operation over the internet. I've often seen CPU spikes and slowdowns when you block some of these services.)

raverbashing 6y ago
I agree, this is 90% likely malicious. The non-malicious usage I can imagine is that for debugging the firewall you don't want to lock your other services out of it in case something goes wrong (or as you said, for reliability issues)
- webmobdev 6y ago
  My fear is that Apple will now make the design decision to make these services more unreliable if blocked. Like I experienced, others too have noticed similar behaviour: > It’s worth noting that Big Sur and its predecessors are built to assume that they can talk to Apple at any time, but when we don’t allow it, a few unwanted side effects pop up. For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online. - https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullvad-disallows-apple-apps-bypass-firewall/ https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullva... (Ofcourse, as a developer, I can sympathize with the Apple developers - when you design a product to use the internet, you don't really think hard about all kinds of use cases where internet access is deliberately denied).
  - _underfl0w_ 6y ago
    > when you design a product to use the internet, you don't really think hard about all kinds of use cases where internet access is deliberately denied Why wouldn't you, though? That seems like a pretty big oversight. Lazy at best, negligent at worst. Not everyone in the world has constant internet access, and it seems ridiculous to design an _operating system_ with that assumption. I like to take an eBook reader to the park, for example. Prior to owning that device, I took a laptop when learning a new programming language. If that laptop had been running BigSur, I'd see all these same issues based on Apple's un-thought-out "design decisions".
    - dkonofalski 6y ago
      It's not like these things fail to work without internet access. Obviously, the vast majority of people using the OS are going to have internet access so assuming actions based on internet access and then failing if you can't connect is accounted for, regardless of the reason (weak connection, no connection, etc). I don't see how anyone can call this behavior an oversight when it works exactly as intended.

raverbashing 6y ago

I agree, this is 90% likely malicious. The non-malicious usage I can imagine is that for debugging the firewall you don't want to lock your other services out of it in case something goes wrong (or as you said, for reliability issues)

webmobdev 6y ago
My fear is that Apple will now make the design decision to make these services more unreliable if blocked. Like I experienced, others too have noticed similar behaviour: > It’s worth noting that Big Sur and its predecessors are built to assume that they can talk to Apple at any time, but when we don’t allow it, a few unwanted side effects pop up. For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online. - https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullvad-disallows-apple-apps-bypass-firewall/ https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullva... (Ofcourse, as a developer, I can sympathize with the Apple developers - when you design a product to use the internet, you don't really think hard about all kinds of use cases where internet access is deliberately denied).
- _underfl0w_ 6y ago
  > when you design a product to use the internet, you don't really think hard about all kinds of use cases where internet access is deliberately denied Why wouldn't you, though? That seems like a pretty big oversight. Lazy at best, negligent at worst. Not everyone in the world has constant internet access, and it seems ridiculous to design an _operating system_ with that assumption. I like to take an eBook reader to the park, for example. Prior to owning that device, I took a laptop when learning a new programming language. If that laptop had been running BigSur, I'd see all these same issues based on Apple's un-thought-out "design decisions".
  - dkonofalski 6y ago
    It's not like these things fail to work without internet access. Obviously, the vast majority of people using the OS are going to have internet access so assuming actions based on internet access and then failing if you can't connect is accounted for, regardless of the reason (weak connection, no connection, etc). I don't see how anyone can call this behavior an oversight when it works exactly as intended.