Apple Platform Security (Jan 2026) [pdf]

They made C memory safe? This is a big thing to gloss over in a single paragraph. Does anyone have extra details on this?

> On devices with iOS 14 and iPadOS 14 or later, Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code designed to prevent memory- and type-safety issues that are typically encountered in C programs. For example, it helps prevent most vulnerabilities in the following classes:

> • Buffer overflows, by ensuring that all pointers carry bounds information that’s verified when accessing memory

> • Heap exploitation, by separating heap data from its metadata and accurately detecting error conditions such as double free errors

> • Type confusion, by ensuring that all pointers carry runtime type information that’s verified during pointer cast operations

> • Type confusion caused by use after free errors, by segregating all dynamic memory allocations by static type

Apple's commitment to privacy and security is really cool to see. It's also an amazing strategic play that they are uniquely in the position to take advantage of. Google and Meta can't commit to privacy because they need to show you ads, whereas Apple feels more like a hardware company to me.

It sucks that Apple decided to monitize iPhone the way they have, by controlling the owners ability to install software of their choosing. Ignoring the arguments one could make about this making it "more secure" it's clearly disrespectful to the power user that doesn't want to beg Apple's permission to use their computer. I'll grant them their security claims are sound, but it's hard to take them serious regarding privacy arguments.

Our choices are either (A) an OS monitized by tracking user interaction and activity, or (B) monitized by owning the basic act of installing software on the device, both of these options suck and I struggle to give up the more open option for one that might be more secure.

But all the software is closed source, and there is little to no opportunity to verify all these security claims. You don't have the encryption keys, so effectively the data is not under your control.

If you want to see security done well (or at least better), see the GrapheneOS project.

You can request a downloadable a copy of any/all of the data that Apple has associated with your account at https://privacy.apple.com.

This apparently includes retrieving all photos from iCloud in chunks of specified size, which seems an infinitely better option than attempting to download them through the iCloud web interface which caps downloads to 1000 photos at a time at less than impressive download speeds.

Glad there's still at least one tech company that cares about personal security / opsec.

Web version: https://support.apple.com/guide/security/welcome/web

Given that A19 + M5 processors with MIE (EMTE) were only recently introduced, I wonder how extensively MacOS/iOS make use of the hardware features. Is it something that's going to take several years to see the benefit, or does MIE provide thorough protection today?

Somehow, they conveniently forgot to mention these "security" features:

1. Constant popups about "application requesting access" on macOS. That often happens without any user's activity.

2. If you leave the permission popup open for some time (because it's on a different screen), it auto-denies. And then you won't be able to find ANY mention of it in the UI.

3. macOS developers can't be assed to fix mis-features, like inability to bind low ports to localhost without having root access (you can open any listening port on 0.0.0.0 but you can't open 127.0.0.1:80).

Sometime I wonder how much overhead all these security features take in terms of performance.

I would really like to see a benchmark with and without security measures.

262 pages!!! Pretty interesting to see how the different SoCs have evolved security wise over time.

Protects the device well... against the owner of the device using it as they wish :)

No mention of Pegasus and other software of such sort. Can latest iOS still be infected?

There is no point creating such document if elephant in the room is not addressed.

Wow, this is hardcore (pun intended).

Then they turn around and upload your iMessages to their own servers in a form that they can read, breaking their own E2EE. Google Messages fixed this issue a long time ago. Why hasn't Apple? https://james.darpinian.com/blog/apple-imessage-encryption