In Case You Didn't Know:
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.
At least in the EU, it sounds like this should be in violation of the ePrivacy directive (aka the cookie law).
There’s an open complaint  about the IDFA on the same basis...
That seems to be stretching it. The user is informed about the IDFA on setup (one can argue that that is a violation), so it’s not like “Apple’s operating system creates the IDFA without user’s knowledge or consent” because they do inform you.
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.
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.
It not stretching. The ePrivacy directive requires that user _is offered the right to refuse such processing by the data controller_, so it also refers to Apple itself.
How do you know that apple is logging GeoIPs and performing this association with appleIDs? Or are you just saying it’s possible to do so?
He’s just saying it’s possible to do so.
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.
There are ways to communicate over the internet that don't disclose the source IP of the client doing the connecting. Tor also uses TCP/IP, so your oversimplification of my post is... not accurate.
> 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.
Perhaps Apple doesn't log your hardware UUID + IP. You'll have to take their word for it.
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 . So "Apple doesn't retain that info" might boil down to semantics since it might be allowing someone else to do it.
"There's a camera in your bathroom, but how do you know it's recording?"
Apple has to log client IPs on these systems to prevent abuse, to stop people doing things like scraping every public key for every iMessage user and then publishing the diffs.
IP to ISP/Location mapping is just a lookup table, and can be done at any time now or in the future.
With a datetime and IP, you can geoIP any time in the future. It's a single ETL operation. So you treat it like they do, one way or another.
This assumes they don’t scrub it before storing it, which we know they do for some services, and we have no information about others.
We can’t in fact treat it like they do. We can only treat it like they might be able to.
Well anyone can do the same and you’d be none the wiser.
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
While I'm glad they fixed it (upgrading past Catalina was not going to happen), It's going to take me a LONG time to trust them again.
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.
This firewall issue isn't the only privacy feature strip from Big Sur release. Unfortunately no big media care about other huge problem Apple introduced.
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 M1, that's by design. If you install macOS on an external volume it doesn't have that behaviour.
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)
How do you know it's "by design"? By default macOS was always using this encryption scheme, but there was always possibility to have an optional FDE. Now this is broken and I can't even manage to get macOS installed when any encrypted partition is present since it's also cause installer to fail.
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.
Apple Silicon Macs use per-file encryption tied to the credentials: https://support.apple.com/en-gb/guide/security/secf6276da8a/...
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.
Why is that so important? Your disk encryption key is certainly stored in memory for the duration of your session (which on Macs might as well be forever since they don’t need to shutdown), so anyone with your user password can gain access either way.
> (the OS volume itself isn't encrypted and is read-only, the data volume is encrypted with your password)
Wait, WHAT? Can someone with an M1 encrypted volume Mac check this directory and see if you see thumbnails?
A full writeup of this is at the link . This has been a well-known thing in computer forensics for many years, which is why *full* disk encryption is so important.
Everything in the Data volume is encrypted. The System volume is signed by Apple and is the same on every Big Sur Mac (SSV feature).
This can be disabled through csrutil though.
The OS volume is a read-only image now - just system files only, and is signed etc
No such file or directory on my M1 Air.
Most users don’t want a separate password for disk encryption though, so I’m not sure it’s a huge problem?
IMO that's a big problem. They are completely different risk categories. My FDE password is absurdly long and complicated, since I never want someone who gains physical access to get all my data, but my Linux user account password isn't as long since it's main purpose is to stop someone from getting passed my lock screen if I was to leave my system unattended.
Both are 'physical access'.
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.
Most users probably also didn't care about the first-party firewall exemptions. They could have asked people if they wanted a separate password for disk encryption (e.g. a small checkbox).
It is highly non-trivial to extract private key from Apple encryption chips, last time I heared the price is at least 100K USD, and probably much higher now. So unless one values own secrets that high, a short password could be OK.
It's about choice and control over your data - an educated user knows that with hardware encryption, it is very difficult to retrieve data if the hardware fails. There's also the trust factor where you would prefer to have the keys, rather than trust some device.
(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.
Is it no longer possible to set a separate password by reformatting the disk in Recovery to one of the "Encrypted" options before (re-)installing to that volume?
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.
Hm, isn’t the trick is to have a separated account just to boot into with a strong password and remove the primary account from a set of accounts allowed to unlock the disk? I have used that on older macos not to bother with reinstallation of os to enable password-encrypted partition.
I am glad that the public backlash forced them to fix a deliberate BACKDOOR that they had introduced (by design) in the Network Extension Framework that macOS Big Sur now forces all the firewalls to use. (At least, they claim to have removed it). But it is hard to trust them again, and I would prefer to use a firewall that uses its own kernel extension to manage the network than using Apple's API again. (Obviously that's going to be really hard with the changes they have made to the OS).
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.)
"Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized."
Apple has no love for privacy nor ever had. They are in a market position where their main competitors - Google primarily, Microsoft and Amazon - are highly dependent on revenue streams extracted by monetizing personal information.
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.
When Apple launched iOS 6, it was the first operating system to include per-app privacy controls around access to things like microphone, camera, photos, etc. Controls we consider fundamental today. It did not mention it a single time in any of its PR or marketing at all. The first reference you find to it will be from Apple blogs who were surprised to stumble upon it in the iOS 6 beta. It took Android two more years to launch a similar feature.
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.
The first except for Blackberry. Before IOS or Android even existed Blackberry had granular per app permissions.
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.
If you’re curious about more of the history (now, almost a decade ago), this was the scandal that likely motivated the above:
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)
That's not true at all. Even early Nokia (Symbian) or Blackberry phones had fine grained permission prompts. As did early Android, actually, but they were deemed to annoying for users.
Apple does deserve credit for leading and influencing Android in this regard, but neither the concept nor the implementation is new.
Android had permission system before iOS implement it, but it was just a prompt for list of permissions at install time so not much worth like current one.
Having been a programmer through the 90's, and watched Microsoft (and Oracle, et. al.) through their most malfeasant years, I'm very cautious about giving companies the benefit of the doubt. However, the fact that Apple is leaving hundreds of billions of dollars on the table by NOT monetizing their aggregated user data does seem to indicate that their will is strong here, and that "they" mean what "they" say about privacy. The kind of money they AREN'T making from this move would try any mortal's soul.
Or it wouldn’t really be that much more. How do you come up with hundreds of billions of dollars? Who are the buyers?
Isn't "it's in our financial interests right now" about as much "love" as you'll get for anything by a corporation? Saying "Apple has no love for privacy, they're only doing it because it sells" sounds moot to me, every company only does things because they sell.
By choosing which markets you operate in and which products you develop you have a fair bit of influence which things are in your "financial interest".
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.
In common speech, "love" is expected to last eternal, not just to the end of the quarter. I'm not really a romantic, but using the word "love" in a corporate context defiles it.
Companies are made up of and run by people and the decisions made by those people are not necessarily solely profit-driven.
That doesn't mean that making money is not important to these people; of course it is. But it's not the only factor.
That's quite an extreme-end of capitalist way of looking at it.
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.
ironically, most of these companies are out of China because they don't want to comply with Chinese laws. Not apple https://applecensorship.com/
> ironically, most of these companies are out of China
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/ )
"Brain test game was deleted from the Chinese App Store".
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 PRISM revelations in particular made me realise that we can really only rely on Linux for security, since Apple, MS, Amazon and all the big tech companies are onboard with cooperating with the NSA. If you've read the way eg the CIA installs snooping software on Macs and PC's, they hide the Mac version in your hidden EFI boot volume, even from the factory.
It's enough to make you never trust them again.
Factory installed CIA snoop software on Macs is news to me, especially bearing in mind most of the factories are in Taiwan. Where can I find out more?
Also if the spyware is installed in firmware at the factory, how is Linux going to help you?
> especially bearing in mind most of the factories are in Taiwan
Zyxel, Asus, and other manufacturers of networking devices (with backdoors of course) are also there.
Well I think it's mac specific software.
I learned about it from wikileaks. Eg https://wikileaks.org/ciav7p1/cms/space_2359301.html
Security isn't the same as privacy. Linux desktop security is poor but its privacy can be okay.
If it's important for you and Linux security is not enough for you, consider using Qubes OS.
Why us it poor? (Genuinely asking).
It’s inaccurate to say “Apple selling user data to US government”. That’s not what the article claims (the word “sell” doesn’t even appear in the text), and there are in fact many consumer data brokers who really do sell data to law enforcement.
I don't think it's inaccurate; the IC pays the data providers (presumably for implementation/overhead) for receiving the FAA702 (PRISM/FISA) data.
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".
A reimbursement for effort/overhead is not the same as selling for profit. Again, there *really are companies who sell consumer data to law enforcement for profit*, so it's important to use the correct language and make the appropriate distinction. Do I like that Apple does that? No. Do I think the actual policy conversation is best served by accuracy in language? Yes.
very nice - this was one of my main contentions on Big Sur.
Will upgrade once 11.2 is stable :)
My other major contention is that Display Stream Compression has been broken since .0 betas through .1.
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.
Which monitors are you using?
Two Asus 27GN950-B's (https://www.lg.com/us/monitors/lg-27gn950-b-gaming-monitor) connected by USB-C to DP.
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.
I'm still on Mojave to use 32-bit apps. Any way to use 32-bit in Catalina or later?
No, and there never will be. It's not the execution of 32bit code that's the problem (you can trivially re-enable that with a kernel flag, if you want), but rather the removal of every 32bit library from the OS. Without those libraries, apps won't run.
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.
You may find https://twitter.com/pvtmert/status/1339329302857457666 interesting
For my 32 bit binaries, the easiest way to use them is to run the Windows version, because that OS has better backwards compatability.
It's possible to get a Mojave VM up and running but it was nontrivial when I gave it a shot
If I'm not mistaken, WINE is now capable of running 32-bit Windows binaries on 64-bit-only macOS as well, so that may also be an option particularly for more simple apps.
I’m using a Mojave VM with VMWare Fusion on my laptop (that runs Catalina) on the rare occasion of needing to run 32bit apps. Install & setup was easy, without any problems. VMWare Fusion is a paid app, but VirtualBox should be able to do the same for free.
Why do you want to upgrade though? What's Mojave lacking that Catalina has?
The latest XCode that supports deploying to iOS 14 devices, unfortunately.
Same. Still on Catalina due to this.
An Apple employee tweeted after the news with 11.0 that this was a bug so I'm not surprised, but happy to see it fixed!
Adding entire feature without justification (ContentFilterExclusionList) is not a bug.
Calling it a bug is misleading.
The feature could be a workaround for a bug. That is, one of their internal services didn't handle being blocked well, and instead of fixing that service they just added that feature as a temporary workaround to make sure the new firewall functionality didn't break any important/core features of MacOS
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.
A bug? Not a feature?
Glad they changed their mind anyway.
There's no link because the tweet was deleted soon afterward. The tweet seems to have been very ill-advised.
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.
bug was in the design. (or in decision leading to design)
"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."
Does anyone know how this impacts little snitch?
It impacts all application firewalls on macOS - Lulu, Little Snitch, HandsOff, TripMode, RadioSilence etc - equally. Meaning, they can all now block the apps that Apple had exempted, in future versions of macOS Big Sur.
It lets Little Snitch 5 block Apple processes without editing a system file.
Which processes should I block? I prefer to share less.
It's great to see community feedback actually works, I really hope people can talk about having the option to disable .DS_Store now
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.