Escape Velocity · Article 5 of 12

The Most Honest Liar in the Room

I've spent years pulling evidence off devices for a living. Somewhere in the last decade, Apple quietly became one of the hardest companies in the world to investigate, and one of the hardest to fully trust, for exactly the same reasons.

Somewhere in a box in my garage is an old MacBook I used for practice work early in my career, back when digital forensics on a Mac meant something fairly close to what it meant on a Windows machine: pull the drive, image it, and go looking. You could cat your way through /var/log/system.log. You could pull the Apple System Log database and read it more or less like a diary. If you wanted to know when a script ran, or what a user clicked, the answer was usually sitting in plain text, waiting for someone to search for it.

I mention this not out of nostalgia, but because the distance between that machine and the one my wife uses on a regular basis now tells a more honest story about Apple than any keynote does. Somewhere between 2016 and today, Apple rebuilt the foundations of macOS and iOS almost entirely around a single, coherent idea: the operating system should trust the user less, trust itself more, and answer to Apple before it answers to anyone else, including, in a very literal sense, the person who owns the hardware.

That idea has produced some uniquely impressive security engineering in the consumer technology industry. It has also produced a company whose privacy and security posture is far harder to independently verify than the marketing suggests. Both of those things can be true at the same time.

· · ·

The Vanishing Paper Trail

The plaintext logs I used to read on that old MacBook are, for practical purposes, gone. Modern macOS keeps its system logs in a specialized format now, compressed and encoded in a way you can't just open in a text editor and read. You need Apple's own tools, or software built specifically to decode it, just to turn the data back into something a human can make sense of. Apple calls this the Unified Logging System. Structurally, it's the same idea as before, a record of what the machine has been doing, just locked behind a door only Apple hands out the key to.

But logging is only half of what changed. Sitting alongside those system logs, macOS also keeps a running record of what you actually do with the machine, moment to moment, things like which app had your attention, what you clicked, how your focus moved from one window to the next over the course of a day. Apple calls this Biome, and it works alongside a separate, long-standing background record of how often and how long you use each app. Put those together with the locked-down system logs, and what you have is a machine that knows considerably more about your day-to-day behavior than the one I used to work on ever did, and tells you considerably less about how to go check that for yourself.

This is not evidence that Apple is transmitting your every menu click to a server somewhere. Biome streams and Unified Logging are primarily local, primarily used for diagnostics and the kind of on-device intelligence features Apple now builds its marketing around. But "local" and "private" are not remotely the same thing, and a comprehensive behavioral record that exists on your device, in a format only Apple's own tools can easily parse, is a different thing than no record existing at all. The paper trail didn't disappear. It moved somewhere you can't read it without help, and that help mostly comes from Apple.

· · ·

A Fortress You Don't Hold the Keys To

The second shift is, on its face, an unambiguous win for security. Older versions of macOS ran on a filesystem where a sufficiently privileged attacker, or a sufficiently privileged piece of malware, could write directly into /System or /Library and alter core parts of the operating system. Root access meant the ability to rewrite the machine's foundations, quietly and in a way that was persistent.

Modern macOS closes that door with something called the Signed System Volume. The root filesystem is cryptographically sealed at the block level and mounted read-only, even from processes running as root. An attacker who compromises a modern Mac cannot casually drop a persistent backdoor into system space the way they once could. Persistence has been pushed almost entirely into user-level territory instead, LaunchAgents and LaunchDaemons, scheduled tasks, or the abuse of legitimate, sandboxed application containers and their configuration files. From a defender's chair, this is real progress. It closes off an entire category of attack that used to be depressingly reliable.

But notice what the sealed system volume actually seals. It isn't just malware that loses the ability to modify the operating system you're running. So do you.

The same cryptographic architecture that keeps an attacker from rewriting your system binaries is the architecture that makes your Mac, at a foundational level, not fully yours to modify. That trade may well be worth making — I'm not arguing it isn't. Most people are far better served by a machine that can't be quietly rewritten by an attacker than by a machine they can freely rewrite themselves and rarely do. But let's be clear: the security improvement and the loss of user control are the same engineering decision, viewed from two different chairs.

· · ·

The Ledger Nobody Told You About

If you want to see the part of modern macOS that I find genuinely admirable and genuinely uncomfortable in equal measure, look at TCC, Transparency, Consent, and Control. On the machines I worked with a decade ago, privacy prompts barely existed. If an application ran, it could generally read your Desktop, harvest your documents, or reach for a connected peripheral without asking permission or leaving much of a trace that it had.

TCC changed that. Every time an application on a modern Mac requests access to your microphone, your camera, screen recording, or Full Disk Access, that request and its outcome are logged to a local database, TCC.db. For an investigator, this database is close to a gift. It tells you, with database-level precision, exactly which permissions a piece of software was granted, exactly when the prompt appeared, and exactly whether the person sitting at the keyboard clicked allow or deny. Cases that used to require reason and interpretation now come with a solid audit trail.

Then vs. Now · One Investigator's View of the Mac
What changed between 2012 and today, on the forensics table
  • System logsReadable text files, easy to search → compressed, encrypted .tracev3 archives requiring Apple's own tooling to parse
  • User intentRarely captured in detail → Biome streams and knowledgeC.db tracking app focus and behavior at granular resolution
  • System volumeWritable by any sufficiently privileged process → cryptographically sealed, read-only even to root
  • App permissionsLargely unlogged, taken for granted → every camera, mic, and disk access request recorded with a timestamp in TCC.db
  • Physical acquisitionPull the drive, image it, done → storage soldered to the board, encrypted via the Secure Enclave (T2 chip or Apple Silicon); live acquisition or Apple Configurator in DFU mode required
  • MalwareCustom Mach-O binaries, malicious kernel extensions (kexts) → Gatekeeper, notarization, and XProtect push attackers toward living-off-the-land techniques and "ClickFix"-style social engineering

This is, functionally, a comprehensive behavioral log of your relationship with every piece of software on your machine, built by Apple, stored on your device, in a format precise enough to reconstruct a timeline of your decisions down to the individual prompt. TCC exists to protect you — that part is genuine, and it represents a real improvement over the free-for-all that preceded it. But the same design that lets a security professional reconstruct exactly what an app did and when is a design built entirely around the premise that Apple's operating system should be the ultimate record-keeper of what happens on a device you paid for. The privacy protection and the surveillance capability are, once again, the same mechanism.

· · ·

A Vault That Can't Be Cracked — By Anyone

Physically, the modern Mac is a different kind of object than the one I used to work on. Pulling a drive out of an older MacBook, or putting a machine into target disk mode, used to be a routine part of the job. Storage was a separate, socketed component. You could treat it as evidence independent of the machine that held it.

Apple's newest chips changed that. Storage on a modern Mac is soldered directly to the logic board now, and its encryption keys live inside a separate, physically isolated security chip, one that even Apple's own operating system can't reach into directly. The old trick of physically pulling a storage chip and reading it on its own, something investigators used to rely on constantly, is effectively dead on these machines. What's left is working with the device while it's still running and unlocked, or using Apple's own specialized recovery tools, all of it gated by encryption that simply didn't exist on the machine I trained on.

From a security standpoint, this is a fantastic way of protecting a lost or stolen device. A thief who walks off with a modern MacBook or iPhone is not walking off with your data in any practical sense. That is a real and significant win, and I don't want to undersell it in the process of making my larger point. But it's worth noticing what this architecture also accomplishes. It makes the device practically un-serviceable by anyone outside Apple's ecosystem, un-repairable in the traditional sense, and un-investigable by anyone who doesn't have Apple's cooperation or Apple's own tools. The vault that keeps thieves out is the same vault that keeps everyone else out too — including, when it matters, independent verification of what Apple itself might be able to reach.

· · ·

Living Off the Land

The malware I used to look for on Macs a decade ago tended to be straightforward once you found it: Trojans bundled into cracked software, malicious extensions buried in the operating system, backdoor programs that behaved like backdoor programs on any other computer. Apple has since built several layers of defense that check whether a piece of software is what it claims to be before letting it run at all, and that's made this category of attack significantly harder to pull off. Unverified software trying to quietly install itself now runs into friction at nearly every step.

Attackers adapted, as they always do. Rather than write custom malicious software Apple's defenses are built to catch, the modern approach on macOS leans on tools that are already installed and already trusted, turning the operating system's own utilities against it. Social engineering campaigns that trick someone into copying a command into Terminal, sometimes called "ClickFix" attacks, have become common precisely because there's no suspicious program to block when the person at the keyboard is the one typing the command. Browser-based attacks follow the same logic: why fight through Apple's defenses when the browser tab is wide open?

This, too, is a genuine improvement dressed in the shape of a new problem. Apple made a certain category of attack much harder. Attackers found the door that was still unlocked, which in this case is largely the same door every operating system leaves unlocked: the person at the keyboard, asked nicely enough, in the right moment of frustration or urgency.

· · ·

The China Question

Everything described so far is architecture — genuine, verifiable, and consistent with Apple's public privacy positioning. The China question is different, because it's a business decision, and business decisions can move in ways that architecture alone cannot protect against.

In 2018, Apple began operating iCloud services for mainland Chinese users through a partnership with a state-owned company, Guizhou-Cloud Big Data, in order to comply with Chinese data-localization law. As part of that arrangement, the encryption keys for those users' iCloud accounts — keys that had previously been held exclusively on U.S. servers, reachable only through the U.S. legal system — moved to servers physically located in China. iCloud data remains encrypted. But the entity holding both the data and the keys to unlock it is no longer solely a company bound by U.S. law. Chinese authorities can now request that data through GCBD directly, without needing to go through Apple's own legal process at all.

I raise this not to single out Apple for operating in a market with laws Apple doesn't control — plenty of companies face the same regulatory pressure, and the alternative, refusing to operate in China at all, carries its own costs that aren't obviously better for anyone. I raise it because it's the clearest illustration in this entire article of a distinction worth thinking about: everything else I've described is engineering, verifiable by researchers, testable, consistent. This is policy, and policy is a decision Apple can make differently tomorrow, in a different country, under different pressure, without changing a single line of the underlying code.

· · ·

The Most Honest Liar

I called this piece "The Most Honest Liar in the Room" because that's genuinely how I've come to think about Apple, relative to the companies covered earlier in this series. Compared to Windows telemetry that can't be fully disabled, or a Google account that assembles a searchable model of your entire life as a matter of course, Apple's approach to privacy is real. The architecture backs up the marketing more often than not. The sealed system volume, the Secure Enclave, TCC's permission logging, the aggressive push against unsigned code — these are not slogans. They are load-bearing engineering decisions that make Apple devices measurably harder to attack and, in most everyday ways, more respectful of the person using them than the alternatives.

But "more honest than the others" is not the same as "honest and fully verifiable," and it's worth being precise about the difference. Every one of the security improvements in this article also functions, from another angle, as a mechanism that makes Apple's own claims harder for an outsider to independently check. The logs that would let a researcher verify what a device is actually doing are encrypted and proprietary. The system volume that keeps attackers out also keeps users from confirming what's really running underneath. The vault that protects your data from thieves is the same vault that means nobody — not you, not an independent auditor, not even, in some configurations, Apple's own opposing legal jurisdiction — can fully confirm the claims from outside Apple's walls. And the one place where the architecture doesn't apply at all, the China arrangement, shows plainly that the privacy Apple sells is ultimately a decision the company makes, revisable whenever the regulatory pressure in a given market makes revising it the path of least resistance.

None of that makes Apple the villain of this series any more than Microsoft or Google were. If anything, it complicates the villain framing further, which is sort of the point. Privacy marketed as a premium feature, baked into a walled garden only Apple holds the keys to, is still privacy that depends on trusting a single company's word — just a company whose word, so far, has generally held up better than most. That's worth something. It just isn't the same thing as verification, and it isn't the same thing as control.

In the next article, I want to widen the lens beyond any single company — to the platforms most people never think to name as surveillance infrastructure at all, and to the data brokers who buy, sell, and aggregate what all of them collect, quietly, in the background, whether or not you've ever touched their product directly.