Apple Reneged on OCSP Privacy

My prediction: another year from now Apple finally implements the ability to opt out, but doing so needlessly and by design causes some essential part of the system to stop working completely, like iCloud or the app store or something.

(Have I become too cynical?)

@Bri anyone who wants privacy from Apple isn't using iCloud (effectively unencrypted) or the App Store. Why do privacy theater? If you want privacy, stop using Apple services in the first place. There are already levers in the OS for disabling iCloud and the App Store and the other phone-home.

I'd like to take this opportunity to point out that the App Fair app (https://appfair.app) includes an "App Launch Privacy" preference that allows you to temporarily disable the OCSP lookup during app launch. This works both for apps that are launched via the App Fair app itself, as well as any other apps that you launch within the ALP window.

Yes, it is inexcusable that this information is transmitted in plaintext, but I feel like there should also be a conversation about the type of power this information grants Apple in the first place.

My understanding from reading the documentation and HN threads is that with Full Security enabled, ARM Macs will only run a macOS build that's been signed for that individual machine. It's also my understanding that this approach has been in place for quite a while on iOS devices.

While this approach is great for its intended purpose (preventing rollback attacks), this also means that if one is signed into iCloud on an ARM Mac or iDevice, the ECID can be used by Apple to target individual users should they wish. I would feel better about this situation if I could verify that my personalized copy of macOS/iOS has the same bits as everyone else, but I am not aware of such a method.

This built-in ability of Apple to send individualized OS builds has the potential for all manner of abuse, whether government-ordered or at Apple's own initiative. I feel like the only check on Apple's behavior is potential civil liability and loss of trust should such abuse take place and become public.

Even if one wanted to dismiss the possibility of compelled behavior or nefarious intent on Apple's part, there is the matter of bugs. We know from the steady stream of security updates that client-side Apple software ships with a lot of vulnerabilities, many of which are discovered only through the efforts of third parties. However, security researchers do not get access to Apple's servers, nor do we get public disclosure of any server-side security vulnerabilities in the infrastructure that powers Apple ID, iCloud, OCSP, the Developer ID CA, Notarization, XProtect, or Apple's 1st party signing servers for their OSes and apps.

Given the critical role that Apple's infrastructure plays in this chain of trust, it seems reasonable for Apple to establish and maintain this trust by 1) publicly disclosing server-side vulnerabilities/patches and 2) allowing rolling audits of 1st-party OS, app, and server software by at least one independent 3rd party.