What kind of argument is this? It’s a single app... how can you judge an operating system off of something that a) probably hasn’t been updated to support changes or b) kinda buggy because it happens to be a fairly invasive program.
Without saying anything about OSX in particular, any operating system that requires network access to log in is a user-hostile piece of shit, and the linked bug#284 pretty well implies that that is in fact the case. It's entirely possible that the problem is due to incompatibities with new OS code or bugs in the firewall program (edit: ie, your case a and case b), but evidence in the bug report pretty clearly suggests that the firewall is correctly blocking all non-whitelisted network requests, and the failure to log in is due to the OS maliciously trying to phone home against the user's wishes.
You're making a mistake jumping to the assumption of malice rather than thinking about all of the other possibilities. This class of bugs is pretty common: people sometimes test software without a network connection at all but its far less common to test with one which drops packets but does not return errors. I've had to fix variations of this problem on Windows, Linux, and things like VMware's HA module.
My guess would be that it's something like checking for things like application revocation or other updates or, if you have iCloud enabled, something like attempting to synchronize your settings or data.
No, I'm concluding either malice or incompetence-to-the point-of-being-indistinguishable-from-malice, based on the premise that login (to the local computer, when the end user has not explicitly configured it to) involves any network interaction at all. It might not be true that OSX login involves network IO (as I more or less admitted above, I haven't checked), but that was not a assumption I jumped to.
That hasn’t been true in my experience using software from Microsoft, Google, Apple, Signal, etc. It seems like most projects only get serious about that after user outcry unless they’re staffed by very experienced engineers.
Threre are no indications that Apple is willing to compromise and allow application firewalls to block Apple softwares that Apple believes should be able to access the internet, even if the user doesn't want it too.
It's a gross invasion of privacy, and a security risk.
(By the way, even in Lulu, some Apple system software - apsd, automount, helpd, mDNSResponder, mount_nfs, mount_url, ocspd, sntp, trustd - are whitelisted and cannot be blocked by the user even if they want to, and that's bit disappointing).
Oh neat, they're still maintaining Little Snitch 4 for Big Sur for people who want a kext and don't mind approving it.
They say "that option could go away at any time", but that would require Apple to make SIP mandatory, and I still don't see that happening. There may come a time, however, where you need to actually disable part of SIP.
It’s one of their weirder decisions. You can’t claim to be privacy king while simultaneously doing something like this. Maybe this is caused by Apple departments being siloed. The privacy champions are in a different silo?
I have the impression that Apple's privacy marketing was just an opportunity grab because they noticed they were doing slightly better than competitors. The recent reveal of MacOS calling home and lack of any significant reaction is a strong indicator this was all just lip service.
Spot-on - it is just a lip-service, and initiated after Jolla launched its Sailfish OS phone. Jolla was started by a bunch of ex-Nokia engineers who were working on the next-gen mobile OS, before Microsoft scuttled it. The Jolla phone outsold the iPhones in some countries in Europe when it was launched ( https://www.gsmarena.com/jolla_outsells_iphone_5c_and_iphone... ).
Unfortunately, they couldn't maintain their momentum and had to get out of the business of making phones. (They still make their mobile OS, and you can buy a license for it and install it on some Sony phones).
At that time, Apple even had an ad-network for apps, and had got embroiled in the PRISM scandal (Apple, and other American corporate were selling their users data to US government agencies - https://www.theguardian.com/world/2013/jun/06/us-tech-giants... ).
But from the get-go, it was never about user privacy - their goal was to ensure that the users data remained siloed within their eco-system, and their competitors couldn't get access to it. They also used the "privacy" angel as an excuse to further close down their devices, and make it incompatible with anything not approved by them.
(Note that it was due to their ad-network and because Apple wants access to users data that iPhones / iPad don't give you the ability to control what app can or cannot connect to the internet. This is still the case, except if you are on cellular data; if you are on Wifi though, an app cannot be blocked. While all the new labeling "transparency" feature and telling the user what data an app will gather from you is good, the feature that would really benefit every one better is the ability to block apps from connecting to the internet itself in the first place!).
They typically are in big companies. "If you're able to do your job, [Security/SecOps/IT] isn't doing theirs" and all that.
It's a natural outgrowth of a corporate "efficiency" mandate that puts functional groups together vs. cross-functional groups. That pendulum is ever swinging.
> It’s one of their weirder decisions. You can’t claim to be privacy king while simultaneously doing something like this. Maybe this is caused by Apple departments being siloed. The privacy champions are in a different silo?
They never claimed to be the 'privacy king'. They just suggested it, and people took the bait.
Apple is a company, and as such are only allowed to care about their bottom line. If privacy aligns with their bottom line, they'll use it for easy advertisement and goodwill, but if it doesn't then they'll forego privacy just as easily.
> Apple is a company, and as such are only allowed to care about their bottom line.
That's a myth. It is neither descriptively the case, nor normatively an obligation, that a company maximise profits to the detriment of everything else. There is no such law, legal or economic. (There is shareholder value theory in economics which suggests that shareholder value maximisation is the optimal solution to the principal-agent problem, but that rests on very restrictive and utterly unrealistic conditions. Furthermore, shareholder value optimisation is not the same as short-term profit maximisation, either.)
Of course they are talking about the fiduciary duty of directors to act in the best interest of the company (which is not a myth).
And who says that profit maximization necessarily has to be "short-term"? Clearly, marketing themselves on strong privacy guarantees is a long-term strategy.
Could you enlighten me what the gross invasion of privacy and the security risk is for the majority of users that do not hack their machine in a way that prevents those connections?
I'm aware of Gatekeeper checking developer certificates upon opening apps over an unencrypted connection (so far; Apple is fixing that), but not sure where the gross privacy invasion or security risk is (in particular compared to existing alternatives, not some platonic ideal).
Here, FWIW, is what Apple says about Gatekeeper and Notarization. I'd be eager to hear any evidence that this is incorrect.
> Gatekeeper performs online checks to verify if an app contains known malware and whether the developer’s signing certificate is revoked. We have never combined data from these checks with information about Apple users or their devices. We do not use data from these checks to learn what individual users are launching or running on their devices.
> Notarization checks if the app contains known malware using an encrypted connection that is resilient to server failures.
> These security checks have never included the user’s Apple ID or the identity of their device. To further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs.
> In addition, over the the next year we will introduce several changes to our security checks:
* A new encrypted protocol for Developer ID certificate revocation checks
* Strong protections against server failure
* A new preference for users to opt out of these security protections
> Could you enlighten me what the gross invasion of privacy and the security risk is for the majority of users
The same reasons that people use application firewalls on their system - Access to our personal data by Apple - intentionally or "accidently". Malware may be able to hijack Apple whitelisted softwares to do their mischief. (And please don't reply by saying we can "trust" Apple with our data - I don't, and if I have paid for a computer I consider it mine, not Apple's to meddle with it as they please).
As for the Gatekeeper incident, the only comment I have to add is that I really don't care about Apple's "apology" after they have been caught ...
The services which are exempted either don't access personal data or only do so when you enable a service like iCloud Photos. If you don't trust Apple to not access data when the corresponding service is not enabled, your choices are to not use their OS or not use their OS — a tool like this can trivially be bypassed by anyone who controls the kernel.
Beyond being technically incorrect (a firewall with a whitelist still works) you're missing the larger point: if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it. Run this command to look at the list of applications which aren't subject to the application-level firewall (the lower-level packet filter does still apply):
That list breaks down into two categories: things which you can't safely be on the Internet without (e.g. security updates) and things which aren't enabled unless you enable them (iMessage, Photos, Music, Find My Mac, etc.) and load some kind of data you care about into them.
In the former case, your options are to enable it or switch to a different operating system — you may choose to schedule them but there's no good security policy where you don't install updates promptly.
In the latter case, people come up with these hypothetical scenarios where someone finds a way to, say, enable iCloud music or photos without your knowledge and then do … something … sketchy with it. The problem with this line of thinking is that if you use those services, you can't firewall them and if you don't you're trying to come up with a scenario where someone can start a service, login using MFA and deleting the notification emails, load your data without prompting, but somehow doesn't already have control of your system or an easier way to exfiltrate your data.
The person I replied to had an even sillier version: “Access to our personal data by Apple - intentionally or "accidently"”. That asks us to believe that there's some way Apple would want to access your data, deploy some kind of attack code which bypasses all of the prompts for each stage, but forget to, say, simply disable the firewall entirely or exfiltrate data through a hostname used for other purposes (such as the software update CDN). It's technically possible but it's so farfetched that Hollywood screenwriters wouldn't touch it.
Any time spent playing firewall admin like this would be far better spent enabling MFA on everything you use and reconsidering the other software you install. Defending against the OS vendor is close to impossible and where people in reality lose data it's due to third-party apps / browser extensions, insecure backups, etc. which are both far more important and much easier to make meaningful improvements.
> Beyond being technically incorrect (a firewall with a whitelist still works) ...
Does it really have to spelled out to you - it is meaningless to use an application firewall when you are not the one creating and controlling the whitelist!!
> if you don't trust Apple not to surreptitiously access your data, you can't rely on Apple-managed security mechanisms to enforce it.
Many of us don't - and that is why an operating system is extendable and we use third-party softwares on it. Just like we use anti-virus software on our OS. And sometimes we also use non-Apple softwares for products or features over Apple's because the third-party has a better product.
> The person I replied to had an even sillier version
Silly for you who are just evading the actual issue and instead want to try and focus the debate to "let's discuss your beliefs instead, and pretend everything is normal with an OS vendor deliberately crippling a useful software".
Yes, Apple does want access to your personal data. Yes, the deliberate crippling of firewalls on the macOS is an an ATTACK by Apple against its users towards this end. And yes, malwares can exploit the whitelist to hijack these whitelisted process.
All the other irrelevant babble you spouted on how you have to be "firewall admin" itself is laughable when all you have to do is toggle a button to control whether an app is allowed to connect to the internet.
> Defending against the OS vendor is close to impossible
It needn't be if the OS vendor has good intentions. And that's no excuse to shut up and not criticize them.
> Yes, Apple does want access to your personal data. Yes, the deliberate crippling of firewalls on the macOS is an an ATTACK by Apple against its users towards this end. And yes, malwares can exploit the whitelist to hijack these whitelisted process.
You need to think about this from a security perspective rather than that initial emotional response. You claim but have no evidence that Apple wants personal data and will not obey their own privacy policy. Again, if you believe that, use something else because that level of unethical behavior is incompatible with the level of trust you’re placing in them.
Continuing the theme, Apple did not “deliberately cripple” the firewall. ipfw still works, a VPN still gets all of your traffic, but when they added a new user-level socket filter they made the decision to exempt core services which are either unsafe to disable or only have effect when you voluntarily opt-in to their terms of service. You may disagree with this but it’s not an attack without some evidence of malice.
And, yes, it’s possible that someone can find an exploit in something like Photos or iMessage. The question you should be asking is how often that would stop an attacker because they wouldn’t have permission to disable your local firewall rules. You can click allow, and that’s why malware commonly approves itself, too.
This kind of local firewall is appealing for giving the illusion of security but most people are not going to be able to meaningfully assess the risk (“oh, a connection to AWS. Narrows it right down!”) and in practice these tools train people to click allow because after thousands of false positives that’s always worked. Enabling one for the apps on the list is especially prone to that because they only access Apple’s own servers.
> You need to think about this from a security perspective
An application firewall is a SECURITY software. Crippling it is stupid. And that is exactly why people are very pissed at Apple for doing so.
> Apple did not “deliberately cripple” the firewall.
Yes, they did - they crippled all APPLICATION firewalls. An application firewall controls what apps can access the internet. By deliberately creating a new API with a BACKDOOR to allow some Apple apps to connect to the internet, and forcing all firewalls to use only that API, Apple is intentionally crippling them.
> they made the decision to exempt core services which are either unsafe to disable or only have effect when you voluntarily opt-in
There are many who have been using such Application firewalls for years together, on previous versions of macOS, blocking such "core" services that they don't care about ... they are "core" only to Apple, not for users who don't use it.
> The question you should be asking is how often that would stop an attacker because they wouldn’t have permission to disable your local firewall rules.
This is just a diversionary argument from the fact that crippling firewalls and giving default internet access to some apps actually weakens the overall security of a system.
> This kind of local firewall is appealing for giving the illusion of security
There is no illusion - if you don't use iCloud, Maps, App Store etc., they don't need to unnecessarily connect to the internet and waste our bandwidth, or worse access and transfer our personal data. The same applies to any app on your system. Their job is to block internet access to specified apps and modern application firewalls do this in a user-friendly.
It is gross abuse by Apple to cripple this ability in their OS.
> There is no illusion - if you don't use iCloud, Maps, App Store etc., they don't need to unnecessarily connect to the internet and waste our bandwidth, or worse access and transfer our personal data
Which is exactly what happens now. You’re spending a lot effort protecting against an imaginary problem rather than the kinds of attacks which actually cause problems. If this terrifies you so much, add some ipfw rules and move on. Better yet, think about your threat model and block it at the firewall so you don’t have to rely on Apple to protect you from what you fear Apple will do.
No, it doesn't because I use an application firewall that BLOCKS them (I haven't upgraded to the crippled macOS). Moreover these are not "core" services and the OS functions fine even if they are blocked.
> If this terrifies you so much, add some ipfw rules and move on.
Why should I when the application firewalls I use are more user-friendly and require less effort? And why should Apple get to dictate what software I use or how I use it? (You may be fine with that and may have given in, some of us won't and we will be vocal about it).
> block it at the firewall so you don’t have to rely on Apple
No, Apple won't make me jump through hoops - the better plan is to DUMP apple if they refuse to value their customers needs. There are better alternate available.
> No, Apple won't make me jump through hoops - the better plan is to DUMP apple if they refuse to value their customers needs.
This was exactly what I suggested: if you’re paranoid about Apple’s intentions, switch OSes. Your level of distrust is never going to be satisfied by the decisions they make with the other 99.9999% of their customers in mind.
What is point then to have such app all? if you can’t control _all_ connections then it appears useless. What is the proper solution? Something on router? Is there a way? Can Openwrt do the job of protecting privacy properly?
I know this probably isn't what you're looking for, but for me personally the solution is to not upgrade past macOS 10.15, and to very likely not buy any more Mac laptops or desktops (after 15 years of being a Mac-first user).
Obviously that's a personal choice, but for me losing that level of control of my desktop operating system - and seeing this as the start of a trend that will only get worse - is not acceptable, so I will look to other OSes to do my work.
I'm sure Apple will continue to sell tons of Macs and that's fine...
I'm taking a more mild approach, switching to lugging two laptops around.
One is for DevOps, accessing production systems, servers. That's where my ssh keys will reside. This will run qubes or maybe NixOS. Not sure yet.
The Mac will be left for casual daily use, development (but no production keys), graphics design, fun, general browsing, chat, and whatnot.
I'm still in the process of splitting all my tasks into what should be secure and what shouldn't.
A nice side effect is that I won't be just as afraid of running a random "brew install" or install an app to check it out, since the Mac is anyway going to be low-security.
Of course it's annoying to carry around two laptops, but completely switching to Linux just means I won't make it happen. Maybe some time...
I actually switched to Windows, and I use WSL2 to run a really seamless Linux shell that lets me do all my dev work.
So far it really has been the best of both worlds.. For my particular work, I haven't missed my Mac at all.. The developer experience has been basically identical.
> I know this probably isn't what you're looking for ...
You know , actually after similar mileage with Macs I consider exactly the same solution. I started with Mac as escape from windows. It was fine for some time when Jobs was around and some time after that, but since 2015 I cannot choose Mac Book Pro that would just fit for work with all that idiocy with touch bars, malfunctioning keyboards and idiotic dongles, instead of working horse that has everything you need and makes things simpler.
>I'm sure Apple will continue to sell tons of Macs and that's fine...
And now as MBP 2015 had gracefully died after I provided the best care for it you can possibly imagine, I wish to move away from Macs even more. I do not wish to pay premium money for shitty equipment.
This 2015 model have just fallen apart, starting with screws that by some unknown to me reason where unscrewing themselves and you could not tight them back because some idiot made them non standard to make sure you really cannot do it, not even with the knife. Then I discovered that screen has traces of buttons after closing the lid. Then I discovered those small traces are unremovable. Then battery even with a proper care died anyway after third of cycles it suppose to have. Then screen have stopped working and then this shit have stopped booting completely ( even with external display).
I should also mention power cord ( with cheap plastic) that became yellow and was not always connecting , while it was carefully kept from banding too much. HDMI that in critical situation did not work, with the best cable you can get. OS that was constantly confusing where the main screen is, forgetting the ‘mirror’ option at will and I can go on and on ....
Overall the experience is horrible. I have other models from previous years and nothing like that had happened.
And I am told MBP2015 is considered to be a best model, as after mid 2015 models are even worse, not mentioning connectivity that renders them useless for mobility I need.
So looking at the way Mac is made these days I am not at all convinced they would continue to sell ‘tons of Macs’
in the following years.
Only inertia saves in such situation but for how long? In my case I cannot move from the platform because I’ve decided to write a proper File Manager for Mac. It is almost complete and I simply cannot live without it. I also cannot leave it unfinished as this would be a huge waste of effort. So I’ll have to finish it, start selling it, and then port to other platforms.
>Obviously that's a personal choice, but for me losing that level of control of my desktop operating system - and seeing this as the start of a trend that will only get worse - is not acceptable.
For me too. Anyway, I’ve been exploring gnu/linux for some time now and it appears as the next step. Since Mac is dead I’ll have to stick with linux for a while. I have no other options available.
That excessive. Installing a lock to which the building owner owns a key is still an improvement over not installing a lock at all.
There's a difference between "All your connections are wide open, so any malicious or compromised software can connect to the web" and "Apple can connect to the web, so you have to decide whether to trust Apple."
I mean, if you're on a mac and you don't trust Apple not to be secretly keylogging your passwords or something, I think a firewall isn't going to help you.
Use a better OS. Seriously, just use Linux if you want that level of control. Most users are happy to give up control in exchange for pretty graphics, easy UI, etc.
I would agree actually. I learn linux, but to get into the depths takes some time. It’s not even easy to choose which one to use. And I have code written for Mac platform, that I need to finish. (I’ve described my situation above
https://news.ycombinator.com/item?id=25778247 )
It should be possible to block the IPs these Apple wares connect to. Currently the easiest solution I have found is ProtonVPN, which claims to block them - https://protonvpn.com/blog/big-sur-exclusion-list/ .
(Ofcourse, the best solution is to not upgrade macOS and stick with macOS Mojave).
I tried to block some of the ip-s Mac was connecting to and then apps had stopped working. Back then I thought I did something wrong and didn’t have time to test it further but in light of recent events It could be I have stumbled on the issue with getting permissions for each app that made a lot of ‘good publicity’ for apple...
Users can develop and install custom kernel extensions (.kexts) that can access everything, but they first need to disable System Integrity Protection in recovery mode.
Over the years Apple expanded their frameworks library to reduce need for custom .kexts, but they are still supported even on M1 Macs (as long as they are compiled for ARM64).
So to answer you question - 'root' user on macOS is by default not a true root in unix sense, but can be trivially turned into one by booting computer in recovery mode and running single command in Terminal. Restart into recovery mode is required so that malicious applications cannot change it on their own, even if they would use unknown privilege escalation technique.
It's honestly mind-boggling how many people whine and complain about macOS not "letting" them do this or that when they can turn off virtually every one of their gripes in about two minutes.
The most egregious was someone complaining that /bin and other system folders are read-only [on systems under System Integrity Protection]. Surely anybody with a pressing desire to e.g. upgrade their bash install or any other thing that requires write access to those folders is also capable of figuring out how to turn off SIP?
It's honestly mind-boggling how many people whine and complain about macOS not "letting" them do this or that when they can turn off virtually every one of their gripes in about two minutes.
It it too much to ask to have the normal security protections that macOS provides and still being able to block Apple services with Little Snitch or Lulu or letting Apple services go through a VPN as well?
> It it too much to ask to have the normal security protections that macOS provides and still being able to block Apple services with Little Snitch or Lulu or letting Apple services go through a VPN as well?
This. Apple is making the use of many security functions black or white: either you allow complete control by Apple, or you have little to no protection at all. Instead they could easily allow the user to customize, and make a selection that works for them (which was the standard in older versions of OSX - pre-Big Sur [1]). The above defending of a giant faceless corporation, by @filleduchaos, is what is mind-boggling.
This feature obviously helps protect some users (non tech-literate ones), but for many it means completely turning off many useful security features ('opting out' by turning off SIP) with a lack of any sort of granular control/customization, on a device they supposedly own. It's a shame this new capitalist encroachment on user privacy is met with such understanding.
> This feature obviously helps protect some users (non tech-literate ones), but for many it means completely turning off many useful security features [...]
I'm pretty sure you have the "some" and "many" the wrong way around. In reality, this feature protects many users (non tech-literate ones), but for some that feel the need to turn it off, it, well, won't protect them, because it's turned off.
> Apple is making the use of many security functions black or white: either you allow complete control by Apple, or you have little to no protection at all.
Wow, thank you for providing a perfect example of what I mean.
I specifically brought up upgrading bash because that was the use case that prompted me to actually learn about SIP. It took me all of fifteen minutes to read a few docs on it, restart and disable it, upgrade to Bash 5...and re-enable SIP and move on with my day, because the dichotomy of "complete control" and "little to no protection" you're presenting here is an egregiously false one. But god forbid anybody actually learn about the platform they're criticising (and there are plenty of real things to criticise about macOS that aren't just projected fears from iOS) before clutching at pearls.
I came to macOS from Linux, and there most definitely are conflicts between what I want to do and what Apple thinks I should be doing. Astonishingly I've almost always been able to go ahead and do those things (barring a complete lack of functionality e.g. with dropping support for 32-bit libraries, an unsolvable dilemma I've managed to crack by...leaving one of my devices on Mojave) because I don't just sit on my hands and whine about it. Apparently this is defending a giant faceless corporation, so I should probably wear that badge with pride.
I understand where you’re coming from. My critique was a bit misdirected.
I guess what is behind it is my frustration and anger with the increasing widespread acceptance of black box computing devices - which are supposedly ‘user controlled general purpose computers’, yet are increasingly not, and which are instead actively spying on us and policing us in a million different ways.
[Edit: what follows is an articulation of various things I’m currently witnessing (a stream of consciousness), as well as frameworks I’m currently learning to apply, that I want to record for myself and others - potential allies who are concerned with this as well]
I’m angry that our overall tech and science literacy is constantly decreasing. I’m angry that a lot of things are getting more and more locked in (Tivoization), blocking learning and making it increasingly unfriendly for beginners
What this looks like in practice is that the essential/necessary ‘ladders‘ to learn and accomplish something (the age and current-skill level -appropriate materials or tools/technologies) are kicked away, with those who kicked it away (locking it away) claiming that they did not use those ladders themselves. They instead claim others can follow in their footsteps - without having, or being given, access to the very same ladders they needed to climb up themselves. This is bourgeois gatekeeping. There’s a book written about an economic theory by economist Ha-Joon Chang, called ‘Kicking Away The Ladder’, that I believe illustrates this well:
“How did the rich countries really become rich? In this provocative study, Ha-Joon Chang examines the great pressure on developing countries from the developed world to adopt certain 'good policies' and 'good institutions', seen today as necessary for economic development. Adopting a historical approach, Dr Chang finds that the economic evolution of now-developed countries differed dramatically from the procedures that they now recommend to poorer nations. His conclusions are compelling and disturbing: that developed countries are attempting to 'kick away the ladder' with which they have climbed to the top, thereby preventing developing counties from adopting policies and institutions that they themselves have used.”
The two main strategies originally used by the global north as they developed, yet which global south countries are now denied access to in north-south relations, are: protectionism and government subsidies.
The exploitation that happens today on a large scale between north-south, seen in the way global south countries are plundered and abused by the global north capitalist firms and governments, is the same phenomenon that we see (on a smaller scale) in the global north capitalist education system, where rich capitalists can get their children tutoring and give them much more patience and attention (as well as opportunities to take over a family business or other non waged intellectual labor - in opposition to waged manual labor - and a chance to develop favorable relationships with other capitalists) than parents of working class children, perpetuating antagonistic class relations.
-
Also I shouldn’t be talking about MacOS internals (SIP, etc.) because I don’t know enough about it yet.
Thanks for clarifying, and no, please do not wear any such badges!
>Apple is making the use of many security functions black or white: either you allow complete control by Apple, or you have little to no protection at all.
In that respect, no Apple's no different from Facebook's "agree to share your data or take a hike" move with WhatsApp
It's extremely different. In Apple's case we're talking about a personal computer that someone paid a few thousand dollars for and is their general purpose machine for their own private affairs (unrelated to Apple), and in Facebook's case you're talking about a single-purpose centralized communication app that is free.
Apple Services go through a VPN as well. A VPN redirects all traffic and does not use the content filtering framework which allows the Apple services to bypass restrictions.
So if you install a VPN it will happily route all traffic over it, including traffic from Apple's own applications.
I recently learned that even blackholing the entire /8 block of Apple's IPs at the router, after they bypass your provided DNS servers, after they bypass your /etc/hosts file, macOS then tries to phone home using IPv6.
These attempts* go on 24/7 even with 0 apps open and the computer being idle.
helpd, geod, locationd, cloudd, the list of apps phoning home when your computer is idle goes on and on and on. Nevermind that they have the metadata to track every launch of every app on your OS.
Then you've got Adobe who is apparently convinced that by virtue of installing their software, they own the resources on your machine and network to their heart's content and spam non-stop phone-home messages to adobess.com adobesc.com adobe.io etc etc
I was tired of seeing 7+ Adobe background daemons, launchagents, helpers, brokers, core sync, etc crap that they decided must be running constantly. I made a script that fires every hour and if no Adobe apps are running it just kills all those useless processes. My machine is so much happier now.
launchd sounds scary but it is not that hard to get an agent enabled. It's basically a plist file or two in the right place and a command to enable it. You can have launchd call your shell script once per minute.
I used this to good effect once to log the output of a few debug commands to text, commit that to a git repo, and move on. Then I could come back later and see what was going on before an issue happened on that system.
Regarding finding the adobe process names, you can filter output of `ps aux` based on application path or name to get a current list process IDs and kill those.
In this particular case, watch out for getting into a launchd fight, where launchd is simultaneously killing adobe processes and also relaunching them because of Adobe's own launchd registrations.
Indeed. Some component of Adobe's suite will be responsible for re-enabling them, so it's just a balance between actually using the software and disabling the background tasks.
So block their ASN, and not just IPv4. Apple has a long standing policy that all apps should be useable over IPv6, this is the same for their own applications.
I have quite a restrictive firewall. Like an old school one: accept the necessary, drop the rest.
Found my Mac unusable in these conditions. It always tries to phone home unsuccessfully, so freezes. Then freezes again.
It has the offline mode but it has no firewalled mode unfortunately. Once the cable is inserted it keeps trying.
Downvote? I'm confused. This whole "Apple gets to bypass firewalls" thing is IMO a huge deal.
Whoever figures out how to make a system-wide firewall that can block everything including "unblockable" Apple network traffic likely deserves (again: IMO) all the attention we can give them.
This already exists. Apple processes can bypass app-specific filters (NEFilterDataProvider), but not system-wide firewalls (like the built-in BPF), VPN configurations, etc.
No, they only avoid being filtered by per-process filters. They can't bypass packet filters, by design; system-wide VPN connections work the same way, and cannot be bypassed.
Interesting to see this on the front page of HN - I've been using it happily for years, no complaints. It's illuminating to see just how "chatty" certain apps are (or wish to be!).
So this one says to "make sure you're using 11.1" (aka Big Sur) and the first comment on HN warns there are serious (unclosed) issues with Big Sur on their Github.
Has totally replaced Little Snitch for me recently after being increasingly annoyed by it over a decade of using it. This type of software requires lots of trust in the developer and objective-see has earned that trust with the many great projects they provide.
I miss how LS was much more granular in allowing specific connections. In Lulu when I approve an app, it's all app's connections by default, unless I am creative with a regex to capture proper connections. That's a major downside compared to LS. Or am I missing something?
"Objective-C" is the name of a programming language used for Mac development, previously the primary programming language before Swift and still popular among Mac developers.
"Objective-See", the name of the maker of LuLu, is a pun on Objective-C.
"Objective Development", the name of the maker of Little Snitch, is likely also based on Objective-C.
I'm aware no one asked, but in case anyone was scanning for Windows, simplewall is a reasonable alternative, both free and open source (development powered by donations): https://www.henrypp.org/product/simplewall
We're working on a powerful (also FOSS!) alternative for Windows. It includes DNS-over-TLS and extensive firewall features.
See https://safing.io/portmaster/
It's not completely stable yet, but we are making great progress. We'd love feedback!
Portmaster looks nothing short of amazing. I have tried it some two months ago but for couldn't really get along with it, I can't remember why. I should try it again, many thanks!
Ok, thank you for a clue, I'll give it a try. The last time I checked it was clearly very far from production-ready. It still shouts "this software is a work in progress, do not expect it to be bug free and do not rely on it for any type of security" in all caps on its homepage which suggests it still is. Given all the abandoned attempts I've seen in the past I also feel very skeptical this one too.
I can give you mine, since I use(d) opensnitch for a while.
It works quite well but requires a GUI (obviously), it looks like it primarily supports GTK. If you're hoping to use the machine purely from the CLI (like, when sshing into your work machine) it won't work well.
It is significantly less powerful than LittleSnitch, some options don't exist (like, allowing access to a domain), but you get similar functionality in many cases.
Overall, it's definitely worth testing out to see if it works for you.
> If you're hoping to use the machine purely from the CLI (like, when sshing into your work machine) it won't work well.
There's no cli tool published yet. There's a PoC though that works well.
> some options don't exist (like, allowing access to a domain)
Since version 1.0.0b you can filter by domain. And in latest version by domain, ip, network, uid, port, command line, command path, cmd environment variables, protocol, or any combination of them. You can't filter by interface, but if aomeone needs it open a new issue.
> It is significantly less powerful than LittleSnitch
iptables don't let you know when a particular program tries to access an outside host and choose whether you want to allow that.
Speaking of a desktop (not a server) firewall I'm rarely even interested which host/port/whatever is a connection about. What matters to me is what app initiated it (if it's initiated from outside my PC it should be always blocked).
Iptables used to expose a field attributing a connection to a particular process but this feature was only available in old 2.4.x kernels IIRC.
> iptables don't let you know when a particular program tries to access an outside host and choose whether you want to allow that.
How does this model work for commonly used programs like curl? Do you block it and can't use it at all in your shell scripts, or do you whitelist it and hope that nefarious programs don't use it to exfiltrate data?
This is complicated, yes. This is why I didn't manage to achieve the perfect result with AppArmor - many of the apps I used on Linux are non-native so it seemed I could only allow/block the entire Python or a JVM (or curl, but I rarely use it so not a problem for me). Perhaps there was a way to analyse the parent process and/or the command line, perhaps whatever, AppArmor (let alone SELinux) felt too complicated (and cumbersome to operate) to waste time.
On Windows and Mac I don't really mind enabling/disabling whole Python/Java/whatever because I can do so in a couple of clicks (and I use more native apps there anyway, many untrusted native apps in particular).
By the way there are many processes on Linux which I would like to silence and theoretically could silence by just removing them as I never need them: I mean Avahi, Samba etc. However, today distros have all sorts of essential packages depending on these and won't let you uninstall them without destroying everything.
> but how would you deal with the notifications in a cli env
That's a very interesting question. I'd love to invent something terminal-based for fun and for future occasions when I'm probably going to need that but I never actually needed that so far. I use GUI DEs 100% of time and I don't really care to firewall particular processes on remote servers I SSH to - those have other security policies doing the job pretty well for them.
Perhaps it could be a named pipe a TUI app (TUI running in a separate virtual console, or in a terminal multiplexer) would connect to.
Vuurmuur is an example of a nice TUI firewall app.
This really should be built into every OS or DE at this point.
I don't put sim cards in my phones anymore, and instead use a portable LTE VPN travel router (which runs OpenWRT, on which I have root) because of the things I learned over the last decade from apps like this.
There should be per-host, per-app permissions in any OS that claims to care about privacy, just as Apple recently added per-directory, per-app permissions to fight ransomware.
I'm gonna be the thick one. What advantages does it give me when I have something like pi-hole as my DNS server on the internal network? Surely majority of connections need a DNS resolution. Would love to see some stats showing the amount of blocked connections that bypassed DNS.
Pi-hole has its advantages. But this is also an application firewall. It's a little more convenient to block a whole app then try and figure out which ip it is trying to connect and block that.
Malware (and I include in this definition several services shipped by the OS vendor) typically doesn't rely exclusively on DNS lookups. Many will fallback to hardcoded lists of IPv6 addresses if you blackhole DNS.
I use it for a long time now, nice piece of software. The only problem I have is related to requests per app.
For example, a Sublime Text plug-in (TabNine), even if I allow permanently outgoing connections the plug-in has to make, LuLu will keep asking me for permissions next time.
I use malwarebytes after trying several options. It's merely a good interface to leverage windows firewall with a block-until allow dialogue box. For whatever reason, it's hard to find a firewall for windows that doesn't use a scammy freemium model.
Yes, I used to use TinyWall ( https://tinywall.pados.hu/ ), which is light and simple. But, if I remember right, it uses Windows built in firewall and so I don't know if it can completely block some Windows 10 system software from contacting Microsoft.
ZoneAlarm also used to be good, but used more resources and is not free - https://www.zonealarm.com/software/firewall (note that you do not need their crap browser extensions that it will ask you to install).
We're working on a powerful (also FOSS!) alternative for Windows. It includes DNS-over-TLS and extensive firewall features. See https://safing.io/portmaster/
It's not completely stable yet, but we are making great progress. We'd love feedback!
I have LuLu installed on an old MacBook Pro and it does work well.
It comes with preset rules to allow most of the essential apps communicate with Apple but they can be overridden to stop my computer from even getting the NPT time.
Little snitch does provide some special features, like choosing which network devices shall have which rules and connection maps which shows where each connection goes on a world-map. It also keeps watch on the amount of data each app uses.
I'm curious about this, as it's one of 3 kexts that I get warned about support being withdrawn in a future version of macOS (UAD being one of the others, I forget the 3rd).
I could probably live without LS, but the UAD support being withdrawn is quite concerning given the level of investment I have there.
