Apple removes first-party firewall exemption in macOS 11.2 beta 2
twitter.com
twitter.com
Big Sur on M1 (and possibly on Intel) maintains a persistent, hardware-serial-number linked TLS connection to Apple (for APNS, just like on iOS) at all times when you are logged in, even if you don't use iCloud, App Store, iMessage, or FaceTime, and have all analytics turned off.
There's no UI to disable this.
This means that Apple has the coarse location track log (due to GeoIP of the client IP) for every M1 serial number. When you open the App Store app, that serial number is also sent, and associated with your Apple ID (email/phone) if you log in.
Apple knows when you leave home, or arrive at the office, or travel to a different city, all with no Apple ID, no iCloud, and no location services.
This has always been the case on all devices using iOS, too.
This change is essential for blocking such traffic, and I'm glad for it, but there is a long way to go when it comes to pressuring the pro-privacy forces inside of Apple to do more.
There’s an open complaint [0] about the IDFA on the same basis...
[0] https://noyb.eu/en/noyb-files-complaints-against-apples-trac...
Regardless, you can always reset it if you want. And “at” WWDC 2020 (half a year before this complaint), Apple made cross app tracking opt-in.[0]
I applaud the EU for leading the way in consumer protection, but every time I hear about it in regards to technology, it always feels heavy handed with the arguments being a stretch sometimes.
[0]: https://www.adexchanger.com/privacy/apple-wwdc-2020-a-versio...
This claim that Apple are tracking your location because they use TCP/IP to receive connections, has been made many times now.
Nobody has so far presented evidence that Apple does in fact geolocate people or even that they persistently store IP address information related to user accounts.
I don’t know for sure that they do not, but I do know that they are aware that keeping IP addresses is a potential privacy leak, and so at least some of their services are definitely designed to scrub ip addresses from records at the point of ingestion and replace them with anonymized keys before they are passed on to services within the company.
So they know that keeping IP address logs is a potential privacy issue and are working to alleviate that.
I would be surprised if they do this for everything yet, but as far as I can see Sneak is making only a theoretical accusation, and not one which he has more than speculation about.
As far as I can see, statements like these...
“Apple knows when you leave home, or arrive at the office, or travel to a different city, all with no Apple ID, no iCloud, and no location services. This has always been the case on all devices using iOS, too.”..
...are complete bullshit as written, even though we can’t rule out the possibility.
“ Apple doesn’t retain a history of what you’ve searched for or where you’ve been.” is on Apple’s privacy page here: https://www.apple.com/privacy/features/
So if someone can find evidence for such accusations, perhaps there is some legal liability for Apple.
> Nobody has so far presented evidence that Apple does in fact geolocate people or even that they persistently store IP address information related to user accounts.
We're talking about IP address logs related to hardware serials, which cannot be changed. User accounts can.
So for everything not using such a method, what I said is true, which is almost everything.
If you said “Apple should use Tor for everything so that eavesdroppers cannot deduce people’s locations via GeoIP” that would be a fair statement.
Sayid “Apple keeps records of your location history”, is speculation which you have never substantiated, despite repeated challenges.
However what I said still holds despite this small exception.
IP address logs certainly can be changed before storage.
But there's even less guarantee that the government doesn't log that information.
After all, Apple dropped plans of implementing E2E encryption of iCloud backups after the FBI asked them [1]. So "Apple doesn't retain that info" might boil down to semantics since it might be allowing someone else to do it.
[1] https://www.cnbc.com/2020/01/21/apple-dropped-plan-for-encry...
Weirdly, this isn’t news - anonymous sources have said before that it was due to FBI pressure.
But this doesn’t have anything to do with Apple logging locations.
If sneak’s claim was correct, there would be nothing we could do about it.
If we’re talking about iCloud backups, at the very least you can turn those off and do them locally.
I’m pretty sure that even if e2e backups do come, they won’t be on by default because of the problem of users managing their own keys.
The implementation was scrapped.
There are ways of solving these problems, throwing up hands and saying "it can't be done anyway" is silly. Apple has done a lot of things that couldn't be done: a computer without a floppy or serial ports, a phone without a keyboard, a headset without cables between your ears.
Building the iPhone was difficult. Building APNS and iCloud was difficult. Building the App Store was difficult. Building the Apple Watch was fucking difficult. Building the Ax line of mobile chips was difficult. Building the M1 was difficult. Don't forget about airpods, homepods, and all the other mindbendingly hard shit Apple does all the time now.
Apple does insane technical achievements on a regular basis. Secret sharing for e2e backups is well within their capabilities. Google even managed to e2e encrypt Android backups.
The problem is that Apple serves at the pleasure of the US military intelligence apparatus, and they know it.
It doesn't take a weatherman to know which way the wind blows.
Nobody is saying this.
Also I agree with you - e2e secret sharing is possible, although hard for users with just one device - I.e. a lot of people.
And yes, Apple has solved a lot of fucking hard problems, slowly, and incrementally.
Just because they haven’t done it yet doesn’t mean they won’t.
You have no evidence at all that any of this is because “Apple Serves at the pleasure of US military intelligence”.
You keep making claims that are pure speculation as if they are true.
I actually agree with keeping pressure up on Apple to implement E2E backups.
I guess you don’t think that’s ever going to be possible though.
IP to ISP/Location mapping is just a lookup table, and can be done at any time now or in the future.
We can’t in fact treat it like they do. We can only treat it like they might be able to.
Apple knows this, so shipping systems that leak information in this way is tacit acceptance of the military spying going on on the networks to which Apple's servers are connected.
Well this is true of every single connection made by every single app on every single device, for every upstream.
That means everyone is tacitly accepting the military spying going on on the networks to which their servers are connected.
That’s not actually an unreasonable position as far as I’m concerned, and you previous comments about this being true unless Tor is embedded have some validity. I say some because I’m unconvinced that Tor is quite ready to handle all traffic yet.
What is unreasonable is your focus on Apple.
By excluding the fact that your complaints are a general problem with TCP/IP and apply to essentially any service, you don’t seem to be doing a great job of informing people about the reality of the problem.
It’s also worth noting that if your position has now moved to how the tracking could be being done by someone monitoring Apple’s network rather than Apple themselves, you are tacitly acknowledging that your claim that Apple is keeping records of your location are just speculation.
Unless of course you go on and install LittleSnitch or the Windows equivalent, which is something I’m not sure even the all of the HN does bother to do anymore.
And then you’re left off with trusting Microsoft or intel or AMD with their unaudited management engines running on-cpu with DMA access, oh and whatever is running in the EFI firmware...
It’s (did)trust all the way down
The fact that they could rationalize their own thought process to think this was a good idea or even anywhere close to acceptable, at best leads me to doubt their judgement. At worst, well it's best to assume incompetence over malice but you can see what doors this would open in the future. Now we know they CAN do this without it being obvious to most users, which is a new dimension of risk regardless of intent.
My only hope they will also fix full disk encryption in this update. Since Big Sur broken installation of macOS on passphrase-encrypted disk partitions.
I bought into M1 hype and now it's end up that you no longer able to have separate password for the disk encryption.
On the internal disk, it's there because they carried over the iOS infrastructure, where your login password is the FDE one.
macOS also now boots before asking for your password, like iOS.
(the OS volume itself isn't encrypted and is read-only, the data volume is encrypted with your password)
I obviously find it being absolutely terrible "design" decision since there no way on earth anyone can count disk encryption key that is unlockable by user password or faceid secure.
PS: If someone have any idea how having separate boot password can be hacked aroud I'll really appreciate the advice.
Was carried over from iOS.
A way to bypass it _should_ be possible, but will entail having the System volume of the volume group to have different properties than the Data part.
Otherwise the OS will fail to load. (on Apple Silicon Macs, macOS is fully booted already when you input the password, so if you encrypt macOS...)
On older Macs, a Preboot UEFI application application prompts you for the password prior to booting.
What you can do as a workaround:
Create a second account which you'll only use to unlock the drive and then run sudo fdesetup add -usertoadd unlockUser and then sudo fdesetup remove -user PrimaryUser. That'll give the rights to unlock the drive only to that unlock user.
You can also use sudo fdesetup removerecovery -personal to destroy the ability of the recovery key to unlock the drive.
What is the privacy implications of two users (both with administrator accounts) sharing an Apple Silicon Mac?
Both users have access to all the data in that case. It got carried over from iOS which didn't have multi-user support.
(and this is by-design, protection granularity is the volume)
Is it possible to make sure that encryption key only available using this "unlock" user passphrase?
Also in case of travel or emergency it's much easier to just power it off. At the same time there is tons of ways how someone can steal your day-to-day lock screen password.
Wait, WHAT? Can someone with an M1 encrypted volume Mac check this directory and see if you see thumbnails?
> $TMPDIR/../C/com.apple.QuickLook.thumbnailcache/
A full writeup of this is at the link [1]. This has been a well-known thing in computer forensics for many years, which is why *full* disk encryption is so important.
This can be disabled through csrutil though.
If one does not power down your system, your FDE is unlocked. So they only need your Linux user account password to get access to the data on your disk.
FDE only protects your data when it's locked. Normally this is when your system is shut down.
Storage encryption can be attacked differently than a running system.
(E.g. Some Western Digital drives have problems with their hardware encryption and made the data on it irretrievable for many - https://github.com/andlabs/reallymine/issues/53 . More here - https://carltonbale.com/western-digital-mybook-drive-lock-en...).
What is being questioned and criticized is the removal of this choice. Especially when a product claims a commitment to privacy.
That's how I set up multiple passwords for FDE on a recent hackintosh build, but I don't have an M1 and this wasn't Big Sur, so maybe I'm missing something obvious that has changed lately and I'm way off-base.
It had to manually be done in that order though, otherwise it defaulted to the user account password for FDE.
I know many Apple's fan see this as a positive move.
But let's not ignore the pattern of privacy violations and user data collections due to deliberate design and the "apology" and "changes" that follow once CAUGHT. A few of these that immediately come to mind are:
- Apple selling user data to US government: https://www.theguardian.com/world/2013/jun/06/us-tech-giants...
- Apple iPhone 11 tracks user location even when location services are explicitly turned off by user (another BACKDOOR): https://www.silicon.co.uk/mobility/smartphones/apple-iphone-...
- Apple macOS tracks every app that you use: https://sneak.berlin/20201112/your-computer-isnt-yours/
- Apple introduces BACKDOOR in its API to allow Apple apps to bypass application firewalls: https://www.patreon.com/posts/hooray-no-more-46179028
(For those who want to diss me for the above, realise that Apple's new found love for privacy doesn't mean shit without such public scrutiny and discussions. And if you want it to last, remain suspicious and VOCAL on any such possible violations.)
Apple is in a position to cut that stream without affecting its bottom line, so it does it and claims privacy as a core value.
I won't look a gift horse in the mouth, but I have no doubt that the tables could switch at any time.
Yes, Apple is doubling down on its competitive advantage here. But to claim it does not and never cared for privacy is just ignoring the facts and the history. It moved the industry forward.
I don't disagree with your argument though, of the modern mobile OSs Apple moved to towards the per-app model before everyone else. I just find it interesting when Apple or Android gets coverage/credit for a feature that has long existed but was forgotten or ignored.
But noone bought the phones so who cares?
The list of prior work that influenced Apple, or any tech company, is usually far too long to list.
Agreed, but that doesn't mean we should default to "Apple was the first" simply because we can't wrap our heads around the pre-iPhone days.
> You can set permissions that control how third-party applications on your BlackBerry device interact with the other applications on your device. For example, you ca control whether third-party applications can access data or the Internet, make calls, or use Bluetooth® connections.
https://www.t-mobile.com/support/public-files/images/legacy/...
https://www.theverge.com/2012/2/7/2782947/path-ios-app-user-...
Congresspeople sent letters to app developers as a result (not even Apple, ha). iOS 6 was then seeded to the public four months after that article.
But! It actually goes earlier than this. Apple started phasing out access to device identifiers used to track users across apps in iOS 5: https://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-ud...
(again, none of this was marketed to anyone)
Apple does deserve credit for leading and influencing Android in this regard, but neither the concept nor the implementation is new.
https://www.youtube.com/watch?v=39iKLwlUqBo
Jobs @ D8
People are quick to forget because back then everyone (including HN) was praising Google for everything under the sun.
https://developer.apple.com/documentation/corelocation/clloc...
EDIT: Oh, I see, if you are referring to the PR or marketing portion, I think it is certainly clear that Apple had a pro-privacy stance, but that did not make its way into the company's _consumer_ marketing:
https://web.archive.org/web/20120718122643/http://www.apple....
E.g. creating a company with a business model which benefits from taxing CO2 emissions (Tesla) is morally great. Whereas having a business model which benefits from cheap oil (VW) is less so. Product decisions (electric vs. fuel engines) have a large effect on your long-term financial interests.
There are bits in the law about management having a fiduciary duty to shareholders, but that mainly means that they aren't supposed to be stuffing their own pockets at the expense of investors. There's a wide birth for management to decide what kinds of profit are and are not worth it.
This change may even depress the stock price directly as disgusted owners sell (this harms the ability of current shareholders to earn a return, as the loss is now but the future revenues are discounted).
The market is as moral as its shareholders, which is far less than perfection but a lot better than zero.
The case in question is Dodge vs. Ford and rather than believe memes about it just read the darn wikipedia page: https://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Co.
That doesn't mean that making money is not important to these people; of course it is. But it's not the only factor.
Companies build a vision or image for how they behave and a lot of that is going to be driven by marketability.
For example Microsoft has taken a very pro-developer stance since Satya Nadella took over. Not just because it's directly profitable to be pro-developer, but because it helps their long term image, culture etc. This goes a long way to explaining a lot of their recent actions like helping Github be available in Iran again and open sourcing large parts of C# / .NET.
So the question becomes: are Apple being pro-privacy because it's a long term stance they want to take and make a basis for their company culture because it's something their customers really want. Or are they taking the stance simply because it doesn't impact their own profitability right now, but would drop it if there was an obvious potential income stream.
And thus is indirectly profitable.
> That's quite an extreme-end of capitalist way of looking at it.
It's only extreme if you can show that companies routinely take the moral stance even when it impacts their short- or long-term profitability. Is Microsoft good now despite its best interests, just because it decided to take a moral stance?
Of the three companies named:
- Google's user-facing services (search, email, app store, docs, ...) are blocked, but Google Ads (which are censored) and Android (which comes without any content that would require censorship) are still sold.
- Microsoft: I'm not aware of any of their products being unavailable. Windows is the dominant desktop operating system in China, and I'd be surprised if the app store wasn't censored. Bing search results are definitely censored (they tell you so at the bottom of the page).
- Amazon isn't selling much that could run afoul of censorship, except possibly books (remember when Amazon used to be an online bookstore?) but in China their market is mostly targeted at the niche of high-end imported goods. (Note the country-of-origin indicators on https://www.amazon.cn/ )
I was telling my friends who moved from China and kept their iPhones, to just buy a new one... just in case...
These are just changes to the app catalog, what reason do we have to believe that a bunch of brain training apps being dropped or withdrawn is evidence of censorship? Has any of this been verified with the App publishers?
The only way to do better than Apple is a full FOSS stack, and that comes with different challenges and is more of a hassle to maintain.
Well, the GP has a quite damming list showing that it doesn't. It's only empty marketing.
It's enough to make you never trust them again.
Also if the spyware is installed in firmware at the factory, how is Linux going to help you?
Zyxel, Asus, and other manufacturers of networking devices (with backdoors of course) are also there.
https://arstechnica.com/information-technology/2021/01/hacke...
Devices like this are used by the government and military contractors as well, and as you can see such vulnerabilities are trivial to detect so you can't count on the opposition finding out about it and using it. This one was picked up days after the firmware release. The smoking gun would be government and military admins secretly being advised by the CIA to close these security loopholes, so the government is protected but everyone else isn't. IMHO that would get Snowdened almost immediately. There's no way they'd keep a lid on that, there would just be too many people involved.
As with a lot of this conspiracy theory stuff, it only makes sense if you don't think about it too much. Once you actually start thinking through the consequences and practicalities, it doesn't hold together.
Understatement of the year. Secret account is exactly what people call "a backdoor".
I learned about it from wikileaks. Eg https://wikileaks.org/ciav7p1/cms/space_2359301.html
https://www.pcworld.com/article/3184435/wikileaks-documents-...
But breaking almost all software by default just because some incompetent users keep choosing to install malware is not a great strategy.
You're making excuses for the lack of security innovation on Linux workstations. They've fallen behind.
There are solutions that are intended to force the sandboxing by opening a new Xserver for every application, e.g. Firejail [0], but that comes with another set of interoperability problems.
Wayland was supposed to address some of these concerns, but it will only do so for applications that natively talk wayland protocol, not the ones that connect through x-protocol via xwayland
Which data is picked by the US government, and no warrant is required. Apple provided data on 30,000+ users to the US government without a warrant in 2019, per their own transparency report.
If they received money for the program, they are indeed "selling user data to [the] US government".
Nitpicking about whether they made a profit has no bearing on the statement “Apple selling user data to US government”.
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.)
> 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-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).
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".
Without spending a lot of time sshd has allowLists (AllowGroups) and match directives
Sudo also has per group config
As a user on any operating system what you can and can’t do is controlled by a list
Perhaps the issue is the list isn’t user controlled ?
Perhaps the issue falls into the “I own and control my device” vs “we sell you a safe, foot gun safe, easy to use device (in their opinion)”
Back doors are typically not disclosed to the user, and can't be turned off. So for example an automatic software update mechanism isn't a back door, as the user is aware of it and can typically turn it off if they are concerned about security.
An undisclosed mechanism that allows Apple apps to circumvent firewalls does very much fit the description of a back door.
Intent doesn't matter with regards to back doors. Most back doors are not made with malicious intent, or at least the vendors usually claim that they only had good intentions for the back door. (Eg. see the recent reports where a router manufacturer had a secret password that they claimed was only used for software updates)
The danger about back doors is that malicious software can use the back doors to circumvent the security measures, just like Patrick Wardle demonstrated that it was possible to use Apple's content filter exclusion to circumvent firewalls.
They're lying.
They can say whatever they like, it's another story they've got no credibility. It was quite obvious it was very much a deliberate action (just look at the naming, itself)
Due in no small part to HN. If it weren't for this community, the word would not have spread as far as it did to pressure them to make this change.
Thanks to all of you and everyone at HN who works hard to keep this place as awesome as it is.
Apple competitors Google and Microsoft which control the great majority of OS installs both for mobile and desktop don't even pretend to care about privacy. I have collected over the years reports about dozens of underhanded tactics they use to manipulate users into sharing data, when they're not downright forcing them to do it.
Currently Google is showing in the EU a modal pop-up asking users to accept to be tracked or fuck off to a labyrinth of "See more" and "Other options" which are obviously violating the GDPR. They got fined five times already for GDPR violations.
Microsoft have told their non-enterprise customers to bugger off and learn to live with telemetry. They're actively working around people blocking telemetry and they're being investigated for these practices.
How about a thank you that at least someone at Apple listens to their customers?
I do so because I am an Apple user - this is being typed on a mac mini. I also own other Apple hardwares.
I also advocated for Apple hardware within my family & friends to switch from Android to Apple quite successfully (I am the IT guy in my circle). I did so because I would like to believe their commitment to privacy they have publicly stated. (Tim Cook being Gay adds to that trust because he understands that privacy is not just about hiding secrets but protecting ourselves from political persecutions by those who do not like some part of our identity - whether it be regional, gender, political, cultural, religious, sexual etc.).
It doesn't mean I trust them blindly or completely or will allow them to screw my customer rights (like right to repair, and OWN my device). Would you?
And here are those contributions spelled out for you: Apple is the only company preventing Google from having the private information of all smartphone users on the planet on their servers.
Maybe not to you. It should be for Apple, if they actually care about their users / customers.
> Apple is the only company preventing Google from having the private information of all smartphone users ...
No, it isn't. There are other worthy contenders to both ios and Android, like Sailfish OS. (In fact, using a Sailfish OS mobile phone actually protects my data from both Apple and Google - it's a double win for me).
And unlike you, my idea of privacy isn't trusting one corporate over another, but ensuring that no corporate has access to my personal data itself in the first place - I absolutely do not want Apple to have access to any of my data. (And whether you like it or not, until Apple does precisely that, I will keep criticising it).
We just had this Szajer scandal, where a powerful outspoken homophobe was caught in an gay orgy.
The gay experience (shame, rejection and discrimination) also comes with increased chance of "co-morbid" personality defects, which may be more pronounced worh exceptional wealth and status.
Queer solidarity by gay men is not a given anymore.
Compromise in security and prviacy clearly has been deemed worth by someone at Apple before the stink was raised.
For most of us, the real world decision is to either work with a company which is actively working on undermining privacy or with one which is trying to improve things.
In the real world, Apple still gets to have their business and people work with them, but enough stink is raised to both externally and privately to get them to change their decision. Which they have evidently done here, so working as intended. Reputation damage is a thing if it involves conversations with other F100 companies.
This particular debacle is one of the reasons why $CurrentCorpo I am occasionally working with decided to skip Big Sur until much later in the lifecycle - not the only one, though.
Will upgrade once 11.2 is stable :)
I have 2 27" 4K HDR 144Hz monitors.
On Catalina I can drive them at full spec on my 2019 Mac Pro, with a W5700X.
On Big Sur, my options are HDR @ 60Hz, or SDR @ 95Hz.
Not to mention the monitors also got a firmware update to unlock 165Hz, which neither Catalina or Big Sur recognize.
I have heard about the issue on a few other forums with other monitors. The only one I haven't heard about in either direction is the ProDisplay XDR.
You can sometimes get away with copying a handful of individual frameworks from older versions of macOS to newer ones, (I recently got Mountain Lion's QuickTime to work on Mavericks this way), but for so many libraries, many of which operate at a low level, it's just not going to happen!
Mojave is still a perfectly fine OS for a while longer. And you can of course use virtual machines, although personally I'd probably opt for dual booting if it really came to that.
I did try this, when Catalina first came out. But maybe I gave up too quickly (It was a "there is no way this will actually work" type of thing), or maybe I tried the wrong app...
It's possible to get a Mojave VM up and running but it was nontrivial when I gave it a shot
Calling it a bug is misleading.
I'm not saying this is what happened, but without actually knowing what happened we can't assume the intention was to exclude everything in this list forever either.
Glad they changed their mind anyway.
I don't know how anyone can describe this as a "bug", because as the linked article describes, there's an explicit "ContentFilterExclusionList" in the Info.plist file with a list of the specific Apple services excluded. That's not by accident, it's by design.
Coding a feature and providing a configuration file thereto is not a bug.
"The bugs were related to Apple deprecating network kernel extensions (NKEs) in Big Sur and introducing a new system called Network Extension Framework, and Apple engineers not having enough time to iron out all the bugs before the Big Sur launch last fall."
Before, I was trying to figure out how mac's would ever be used anywhere near something classified or secret for a company.
- pro/dev users who act as their trend setters (see recent backpedals on keyboards and Mac Pro form factor)
- people hacking stuff where it’s popular enough they want more influence on the UX (bootcamp)
That they purposefully added in the first place to let only Apple apps bypass third-party firewalls?
Every family has that one computer geek who everyone asks for advice, which ultimately influences purchase decisions.
"Some system processes bypassing NetworkExtensions in macOS is a bug, in case you were wondering."
Reply[2] by David Dudok de Wit, developer of TripMode:
"Glad to see it's being reconsidered as a bug, because Apple told us it 'behaves as designed' (FB7740671 + FB7665551). And why is there an exclusion list in the first place? I'd love to know more and see this documented."
Reply[3] by Russ:
"Can't get too specific but I promise it's really mundane/boring software development stuff... like two features that interact in an unintended way kind of boring."
Comment[4] on Russ's original tweet by Sérgio Silva:
"Yes. A bug with its own configuration file /System/Library/Frameworks/NetworkExtension.framework/Resources/Info.plist ContentFilterExclusionList"
[1] https://web.archive.org/web/20201118140434/https://twitter.c...
[2] https://twitter.com/david_ddw/status/1329017113709842437
[3] https://twitter.com/xenadu02/status/1329030446269620224
[4] https://twitter.com/sergiojdsilva/status/1328991480657162242
Relying on a personal firewall on the device itself seems ill-fated. Maybe it could be considered an additional layer of security, but I've yet to work at a place where a personal firewall is part of the security concept, no matter which OS. It's either firewalls at the gateway, maybe additional ones for certain departments, or mandatory proxy servers if you're stuck in the 90s.
Clearly if your kernel or userspace are compromised that's not much use, and that's where external controls kick in.
You can't determine (absent some custom network and protocols) which piece of software was responsible for a given packet once you leave the device though, so that's the (current) best place to do that - if you want to impose policies controlling the hosts and protocols an application can use, you will want to implement this on-device, then firewall for the superset of all of those at the network level.
In essence it's about raising the number of independent failures required to result in a compromise. If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.
> In essence it's about raising the number of independent failures required to result in a compromise.
Sure, it doesn't hurt, minus maybe the case that a vulnerability in that firewall itself is used.
> If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.
That's a requirement I guess. You don't want accountants and HR people handling popups by a firewall app. :-)
> Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE.
The most common place this would come up would be with SREs/Devs that have access to prod (and thus the "Cardholder Data Environment") from their laptops. It can also apply to business users that have access to certain admin dashboards in some organisations.
Microsoft provides the sources and special builds for sensitive environments.
They work with governments worldwide and open their source code to get certified.
As far as I understand it never was Apple's priority.
Now, if they could empower lower levels to make these decisions before the issues blow up in the wider world context, all the better.
It's just that as an engineer you are often in a bubble and can't foresee every implication of your decision. That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback. And on this occasion just like on many other they will take action if necessary.
Except that Apple did not take action. Firewall developers such as Little Snitch did become aware of the issue during the beta releases and gave feedback to Apple, which Apple ignored and shipped it anyway to the public. https://blog.obdev.at/a-hole-in-the-wall/
Look, I don't mean to criticise. But how do you know that Apple didn't start working on a fix when they were told about it?
Apple doesn't exactly say when they start working on a fix for something, or else we would have known earlier.
Not to mention that "removing the ContentFilterExclusionList" is a hacky fix suggestion. Doesn't mean it's the actual hollistic fix, and there weren't other under the hood changes for this issue.
You've got in backwards. The ContentFilterExclusionList was itself a hack. It never should have existed.
Some people are handwaving about a mysterious vague problem that calls for a ContentFilterExclusionList, but Little Snitch has existed for many many years on the Mac and has been able to block everything, including Apple services. There was no problem with that until Apple decided to exempt itself from getting blocked.
It might or might not be a hack, but that's orthogonal to the functionality or whether it uses a ContentFilterExclusionList.
The fact that it wasn't there before, or that it is a misguided feature idea, doesn't mean it was done as a quick and dirty implementation or that it's hastily made feature done via cutting corners.
If you accept the need for your own apps to bypass user application filtering (eg. because you consider your traffic/apps integral to the OS operation) then that's the kind of thing you'd implement -- and you could do it with a team of 100, working for months with fine specs, to deliver the same thing.
There's nothing inherently hacky about it.
>There was no problem with that until Apple decided to exempt itself from getting blocked.
That's neither here nor there though, as to whether it was done as a hack - or, to get back to the point, as to whether they could just rip it off trivially.
People forget this is not just a single feature, but part of a change to how network filtering is done (not through a third party kernel extension anymore), accompanied with new APIs.
If this one change is in a pool with tens of thousands of other possible changes, and it also has to go through one or more QA cycles? Sure, why not 6 months?
Because the first WWDC preview version of Big Sur was released to developers on June 22, 2020, and Big Sur was released to the public on November 12, 2020, so Apple needs to be able to fix issues identified during the beta period much quicker than in 6 months.
No OS does, including FOSS distros / OSes.
Apple just has to fix "the most important issues" with the most bang for the buck identified during the beta period before release.
Which they do.
The ones they consider less important are put in a backlog.
You can find "issues identified during beta releases" still open and unfixed for all OSes, some even going 10 years back, long after the release was out...
You're assuming that changing that list is the only thing they needed to do. Have you thought about why they felt they needed that list to begin with? Maybe because they wanted to quality control that all their core services could graceful handle being blocked by a firewall first? That is, the job wasn't changing the list. The job was probably quality control of everything potentially blocked by that list.
Or they just didn't think it was such an important issue. Most MacOS users by far probably don't care.
No, you're assuming that I'm making that assumption. Why would you assume that?
> Most MacOS users by far probably don't care.
It's frustrating that people keep ignoring the fact that I was directly replying to this comment: "That's why Apple has the Developer and Public Beta releases for iOS/OSX so that external users can provide feedback."
If feedback during the betas does not make Apple take action, then the comment I was replying to was wrong.
Your response seems a bit ironic, though, because public backlash is exactly what caused Apple to backtrack.
They shouldn’t have been broken in the first place, but hey.
I've also lived my entire life in the North (which for some reason is called the Midwest).
From the perspective of Apple, this wasn't even an issue at all. It "behaves as intended". https://twitter.com/david_ddw/status/1329017113709842437 So that's why Apple didn't fix it. You don't fix something that you don't think is broken.
I was replying to a comment that literally said, "That's why Apple has the Developer and Public Beta releases for iOS/OSX", so maybe you should argue with that comment instead of with me.
I wonder what the backstory to the original decision was.
Pure speculation: a "bug" was reported in which something was broken, and it turned out to be because a third party firewall was blocking access to some Apple-hosted service, and someone started working on "how to fix the bug", and the "bugfix" was to make sure third party software can't do that.
This more or less confirms my hunch. Thanks for inside perspective on it. That’s how literally every other org works but I know Apple got this reputation for having a very executive-micromanaged culture under both Jobs eras, it’s good to have a reminder that at the end of the day it’s not the borg.
The impression I always got was more like a mid-to-late USSR than the Borg (in structure rather than efficacy, the USSR didn't work, apple does). Everyone in the Borg is (supposed to be) identical, whereas Apple seems like a structure of lots of groups of often brilliant people working in seperate-but-equal subtrees, working under a (especially under Jobs) ideologically-inspired dictator from the top down. The way Apple are fairly reticent to document what they make partly informs the comparison.
Why, you might ask, would this be a matter of cutting corners? Well, fault tolerance is hard. What happens when the OS can’t reach external services it depends on for security features? Well, Apple found out recently in quite an embarrassing way. Given the almost immutable yearly release cycle, I would be astonished if they didn’t just duct tape some whitelist in because a more resilient solution wasn’t ready.
The Mac "OSCP appocalypse" occurred in November on the day that Big Sur was released to the public, with the exclusion list still present, and a number of firewall developers were already aware of the exclusion list and had reported bugs to Apple.
This was your claim. What is the justification for the claim? The comment seemed to imply that it was the OCSP problem. Otherwise, no other explanation was offered by the comment.
I observe a lot of HN commenters don't vibe with how Apple controls & develops their ecosystem. Yet, instead of go elsewhere, complaining and acting like being oh so very special enough to know how things should be done is preferred; while expecting a major company to just cater to their personal whims.
I'm unsure if it's entitlement I'm witnessing or just people that feel like they have no faith in Apple's competition at making anything better than Apple currently has.
I like Apple products, but I try to avoid any illusion that they’re good guys on a corporate scale. They’ve proven they’re not in a lot of ways (see many recent articles about their labor practices). That doesn’t mean every thing they do should be equally scrutinized with a pessimistic predisposition. But I really don’t fault anyone for assuming a large for profit organization will prioritize their own priorities over everything else.
The thing I try to moderate that with is understanding their actual priorities and not just falling into blind cynicism.
I want them to listen, since the decisions they make affect the ecosystem I've adopted for my extended family (for whom I'm the main technical point of contact,) and poor ones will affect me and them disproportionately.
So to me, it doesn't feel at all like entitlement, rather, the wishes of a longtime, loyal customer hoping they continue down the path of listening to those of us who have promoted their products and helped make them successful.
110% this.
Other laptops are awful hardware. Including the Dell XPS line and the new thinkpads.
In this case Apple responded well and that's great. We don't know how many of these decisions are already being squashed each day through appropriate governance.
This means that after I update to 11.2, to preserve location privacy from Apple, I must now verify each and every OS update in the future.
We need a better system.
Their original action that triggered this was them wanting to own your Mac.
First of all, there are surely many people who influenced the creation and release of this feature and I don't think it would be accurate to assign a single motivation to all their work.
Second, I don't think it's wrong to say that "boneheaded management cutting corners" by prioritizing the needs of other internal teams over the needs of the user is in some sense them "wanting to own your Mac". Although that is a dramatic way to describe it.
It’s beyond dramatic. It’s absurd. I’ve worked on so many projects and deadlines that have had to make such decisions, even decisions that eventually fell to me. In numerous cases I could cast aspersions on some of the management motivations, but even so I couldn’t describe it as them trying to own the product they’d sold to customers. In most cases it was a balance of market pressure and resources. In the cases where I’ve had to make those calls, it’s been balancing market pressure specifically so I had more room to satisfy users.
I don’t think Apple engineers are immune to this. They have to ship big things on a tight deadline. When they can’t satisfy everyone they have to make choices. Sometimes they don’t make the best choices.
Hopefully you don’t have these weights in your job. But lots of us do.
FWIW you can just turn off the Gatekeeper feature which is what I assume you're complaining about.
https://news.ycombinator.com/item?id=25746007
In sum, they’re intentionally circumventing DNS, /etc/hosts, and even IPv4 blackholing by attempting to send their phone-home packets through IPv6. Then if you block that as well your computer constantly freezes.
Where does “constantly freezes” come from? You didn’t mention that in your linked post. And if your computer “constantly freezes” with Apple blackholed, why wouldn’t it also be constantly freezing when your network connection doesn’t reach the internet? I’m pretty sure they use an apple.com URL for their reachability test, so your blackhole should be blocking that too.
:: domain.example
$ echo "0.0.0.0 cloudflare.com" | sudo tee -a /etc/hosts
$ getent hosts cloudflare.com && getent ahosts cloudflare.com
2606:4700::6810:85e5 cloudflare.com
0.0.0.0 STREAM cloudflare.comDNS should be enough, I shouldn’t have to black hole Apple’s entire /8 to stop macOS from phoning home when I’m not using the computer and no apps are running.
Much more likely is that they were aware of outbound firewalls like Little Snitch and want to evade user attempts to block their software, as discussed in the main article here.
::/0 domain.example
$ getent hosts cloudflare.com && getent ahosts cloudflare.com
2606:4700::6810:85e5 cloudflare.com
104.16.133.229 STREAM cloudflare.com
$ echo "0.0.0.0 cloudflare.com" | sudo tee -a /etc/hosts
$ getent hosts cloudflare.com && getent ahosts cloudflare.com
2606:4700::6810:85e5 cloudflare.com
0.0.0.0 STREAM cloudflare.comIt's for your own good!
But your claim that “any OS will start to show trouble” is not how it’s supposed to work, nor how it used to work before 24/7 connections, nor even how it should work assuming you’re ok with phone-home daemons.
An OS in general has a few layers with caches and monitors and resolvers etc, and if you block a few of them, in a partial manner, they tend to get in to an extreme version of the bus bunching problem. Windows still does that with their 'network identification' where sometimes something goes wrong in the probing process and the connection hangs on "identifying" indefinitely. And that's just a silly "optional" service (which should default to the public profile and only change from there instead of defaulting to no connection at all).
Seems to be an interesting problem: if it works fine with no connection and fine with a complete connection but not 'in between' (which is the best way I can describe it so far) you'd think it must be some common library or component in a network stack that causes this. macOS has some reachability system that might be in play here, perhaps if it flags the network as 'reachable' but then gets REJECT'ed it goes bad? Or the other way around: marks network as 'unreachable' but traffic flows anyway?
Now, I do have an issue with apsd specifically on Big Sur, but "sending phone home packets" isn't it.
The screenshot is an example of traffic to Apple unsolicited by the user.
Do you expect a dialog box every time it resolves a hostname? Users want features like Messages which depend on the push notifications service shown, not the details of how it’s implemented.
This is also Exhibit A for where the idea for things like firewall allow lists come from: there are always people who will block something they don’t recognize and then complain about “bugs” after the system does exactly what they requested.