I have a theory that I believe is supported by enough evidence for you to believe it, as well.

Mind you, this is definitionally a conspiracy theory; please don’t let the connotations of that phrase bias you, but please feel free to read this (and everything else on the internet) as critically as you wish.

I believe that Apple is preserving unencrypted server connections in their operating systems in an effort to enable global location tracking of their userbase by passive monitoring of major internet backbones.

This is supported by timelines and context, which will be provided.

Several important connections (TSS, OCSP) are made from Apple devices in plaintext (that is, completely unencrypted). This began for historical reasons, but has been repeatedly reported to Apple. They have not fixed it.

TSS checks happen on update. OCSP checks happen, among other times, on app launch.

Apple committed in writing a few major versions (i.e. ~3 years ago) to providing a preference setting for disabling online OCSP checks in macOS when I made a stink about it, within one year. Not only did this not happen within a year (a rare instance of Apple actually outright lying), but someone was kind enough to write me and tell me that Apple has edited the webpage to remove this promise. Presumably there are no plans to offer users ability to disable OCSP checking, which leaks which apps are being launched on your system, when you launch them.

Not only can you not disable it, they’re still not happening over encrypted (https:) connections. This is straightforward to fix, but it hasn’t happened.

Apple’s webpage says:

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 using on their devices.

These security checks have never included the user’s Apple ID or the identity of their device. To further protect privacy, we don’t log IP addresses associated with Developer ID certificate checks, and we make sure that any collected IP addresses are removed from logs.

The problem is that the connections are still unencrypted! Anyone in the world who can watch the internet traffic to or from your computer, or to and from Apple, or between your computer and Apple (this is a lot of people), can make their own logs, with all of the IP addresses and all of the launched apps. If you use enough apps, the specific constellation of your apps is probably pretty close to uniquely identifying you.

The OCSP checks (“Gatekeeper”, in Apple’s terminology) are not the big deal, however.

When you update a modern mac, it needs something called a boot “ticket” for the new OS. This ticket is cryptographically signed by Apple, and is unique to your specific Mx Apple Silicon CPU/SoC (or your specific T1/T2 security chip, if you are using an Intel mac).

The request to Apple for this boot ticket is via an API (called TSS), and includes specific unique identifying serial nubmers of your computer (such as your chip’s ECID) that never, ever change. It’s done on every major OS update, and, you guessed it, it’s done totally unencrypted. Anyone watching the backbone traffic on the internet will be able to pair ECIDs with client IP addresses on every major macOS update. (Client IP addresses identify city-level location. With the information available to DHS/FBI from the carriers and cable companies, they identify a specific building and subscriber name.)

This is a pcap taken today of the OS updater included in 13.4, released in May of this year, transmitting my ECID in plaintext.

I screamed loudly about this in April 2022 and ended my post with “Continued transmission of plaintext identifiers will be assumed as malicious intent. Fix it.”

It was not fixed. Not in the next release, not in the next major version.

It’s still not fixed in Ventura 13.x, at least as of 13.4 (May 2023). Apple has been leaking this customer PII across the internet unencrypted for seven years, ever since the introduction of the first T1 chip in the original Touch Bar MBP.

First, during the update, Apple’s updater has to send your activity data back to the mothership even when analytics transmission is explicitly disabled. (This is why xp.apple.com is in so many hosts file privacy blocklists.)

Then the updater can get to the important work of leaking your plaintext ECID across the whole internet.

I would be likely to give Apple the benefit of the doubt here, if not for two very important mitigating factors:

1. Apple does not allow plaintext server communications in apps released by developers in the App Store. This is explicitly against the rules, and they have tools available for app developers to use that make 100% encrypted connections the unavoidable status quo (App Transport Security). But for some reason for seven years and counting they didn’t mandate this for their own OS updates.

2. Apple has a documented history of preserving cryptographic backdoors to aid US government surveillance.

You might argue that the latter is now invalid, given that there is now an option to enable end to end encryption (on this page, hereinafter referred to as E2EE, but called “Advanced Data Protection” by Apple) for iCloud and thus iCloud Backup. That’s also not valid, and I’ll explain why.

First, iCloud E2EE is opt-in. The setting is buried, and there are no prompts to enable it, so approximately 0% of iCloud users have turned it on. It might as well not exist.

Second, iCloud E2EE is woefully incomplete. When you iMessage with someone, they have iCloud Backup on by default, and non-E2EE by default, which means that approximately all of your iMessages (including all image and document attachments) will still be readable by Apple and the FBI because they are backed up twice: once from each end of the conversation. Unless you and ALSO everyone you iMessage with has enabled E2EE (which, today, is never, ever true) then your iMessages are subject to surveillance by Apple and the whole of the US government that can force them to turn them over.

Furthermore, the E2EE for iCloud Photos is not designed to preserve privacy. Even though iCloud Photos now supports E2EE for the content of the photos and videos stored, the file metadata is not E2EE, and the metadata includes the FILENAME and also a unique hash of the unencrypted file content. This means that if you make a first-of-its-kind Winnie the Pooh meme and save it to your camera roll (hooked up to an E2EE-enabled iCloud Photos account), then send it via secure means (Signal, or in-person AirDrop, or whatever) to another person who has iCloud Photos enabled (also with E2EE) and they save it, Apple can see that you both have the same file, the only two people in the world with it.

They can see who had it first. They can see who had it next, and when. They can see where it went after that. This is with full “E2EE” turned on, and without even using Apple messaging apps. This leaks your social graph, too, and it provides a nice list of dissidents who all have the same file.

This applies to all files in iCloud Drive, too, not just your photos. Share a file securely within a group of people who all have E2EE enabled for their iCloud Drive? Guess what, Apple now knows they’re a group, and by extension the US and Chinese governments can, too.

If you enabled E2EE for iCloud Drive, would you expect that Apple sysadmins can read all of your filenames? How about the FBI without a warrant?

“Privacy, that’s Apple.”

Any repressive government can now go to Apple with an image file or document (or its hash) and demand a list of every single phone number, payment card number, full name, and last known device location of everyone in iCloud who has a copy of the file, even if all of those people have opted in to Apple’s false-sense-of-security E2EE system.

Note that this was always possible before, too. But it’s still possible, even under the current E2EE system. So far, it’s farce.

Why Bother?

What exactly is the point of rolling out this E2EE feature if:

• you’re not going to prompt to migrate people to it
• you still enable authoritarian repressive surveillance of your users even when it’s turned on, because its design sucks
• you still leak the social graph of the users based on the path and time of spread of unique files

Apple has designed and operated truly private systems before. iCloud Keychain and Health are two bits that have been E2EE and are, as far as I can tell, immune to surveillance orders or corrupt governments (such as those in Apple’s two biggest markets).

(Please don’t write me about how the iCloud plaintext content hashes are to support deduplication. Apple already did in HT202303. That’s not the point, and it’s irrelevant. Also please don’t write me about how E2EE is bad for most users because users will lose all their keys and then lose all their photos and be sad. It’s called sneak’s law and I wrote it. It’s irrelevant to the topic today.)

Apple says in HT202303 that they are “committed to ensuring more data, including this kind of metadata, is end-to-end encrypted when Advanced Data Protection is enabled”. Maybe if they hadn’t dragged their feet for the FBI years ago then privacy would actually be baked into this product by now.

Note well: You can’t use Homepods, Apple Pay, Handoff, or Passkeys without opting in to iCloud; each year choosing not to use iCloud comes with a larger list of disabled functionality on your device. I imagine the Apple Vision will be similarly hobbled without sending Apple and the FBI a constant realtime stream of your life’s activity in the form of iCloud metadata. A ton of the functionality of Apple devices is missing if you don’t submit to the ability to be surveilled.

Wrapping Up

iCloud is a privacy nightmare. iMessage is not end to end encrypted due to both endpoints escrowing their secret keys to Apple by default in the non-E2EE iCloud Backup. Even if you turn on E2EE on one end, it’s ineffective because the other end still has it off.

On every macOS update, you transmit plaintext TSS API requests which include your unchanging ECID, alerting everyone on the internet backbones of your ECID-to-IP mapping, allowing your movement to be tracked over time.

On many app first launches (not every launch), you transmit plaintext identifiers leaking what developer’s app you have launched and when (and client IP, again). (Note that most developers only publish a single app, so this aliases to which app you have launched.)

Furthermore, Apple knows all of these things, and has opted to do nothing meaningful to mitigate the threats.

I think that macOS has too many plaintext network privacy leaks, for far too long (in the context of everything else I’ve enumerated here) for this to be carelessness, coincidence, or deprioritization.

Finally

Please take the time to go to Berlin, and visit the Stasi museum, if you think my warnings about the potential for abuse by the FBI when they are not constrained by the need for probable cause or search warrants are overblown.

This is the same FBI that wrote Martin Luther King Jr. anonymous letters telling him to kill himself.

Presently, the US government is accessing the full content of around seventy thousand(!) Apple accounts per year (as of 2022) without a search warrant, per Apple’s own transparency report. The numbers are much higher when you include warrants issued with probable cause.

My concern is not so much that Apple is the threat, as Apple is not in the business of oppression or imprisoning journalists, but the governments that can meaningfully compel Apple: the United States, and the People’s Republic of China. (Google could pull out of China and lose their customers; however approximately 100% of everything Apple sells is made in China, by Chinese people, in factories subject exclusively to Chinese law. China has more control over Apple presently than the USA does.) Anything Apple can know, the CCP or USG can know.

A society that is under constant and total suspicionless police surveillance is a society that is, given enough time, actually doomed.

Apple is complicit in building this society currently, and it poses an existential threat to freedom worldwide if it is not rectified.

Finally, if you still don’t believe that Apple would be game to play ball in such a manner, read this. There isn’t much wiggle room for large corporations to refuse the direct demands of the military in the USA, there’s simply too much asymmetry in terms of organizational goals. Corporations are ultimately extremely fragile and far too vulnerable to the state’s will.

Footnote

I’m experimenting with blogging more quickly and with less time spent editing. Please provide feedback on this or any other post on the BBS or via email.