Last Week on My Mac: Making essential services fail-safe

We never seem able to learn how widespread disinformation is. Anyone can pop up on a website claiming to be a “security researcher” and push out all sorts of wild claims. Not only that, but the wilder their claims, the harder we find it to focus on what really is important.

Last Thursday, 12 November, Apple had a bad day with online services. Perhaps the most prominently affected was the release of macOS 11.0.1 Big Sur, yet by far the most consequential was a failure in which for several hours left many users unable to launch the apps which they use every day.

By a strange coincidence, someone claiming to a “hacker and security researcher” chose that same day to publish an article alleging, among many other things, that “your computer now serves a remote master, who has decided that they are entitled to spy on you”. He then uses that overtly paranoid thought to discourage anyone from buying Apple’s new M1 Macs – a motive which should lead you to wonder whether it’s ulterior. He also states categorically that “there will be no way to boot any OS on the new Apple Silicon macs that won’t phone home” without apparently even having seen, let alone used, an Apple Silicon Mac.

Those who take the trouble to read the carefully-researched account by Jeff Johnson, one of the most knowledgeable and experienced Mac developers on the planet, will get an accurate picture of what happened. In short, when you launch an app in a recent version of macOS, which I believe includes Catalina and possibly Mojave as well as Big Sur, macOS checks its signing certificate with an external service, to confirm that the certificate is valid and hasn’t been revoked. This is performed using a standard protocol, OCSP, and is now the preferred method of checking the validity of security certificates for other purposes, including those for TLS in secure web connections.

We did have an alternative in macOS, which used to maintain a local database of revoked certificates, or so we suspect, until over a year ago. At the height of its use, that database was updated every couple of weeks. So if Apple revoked a certificate being used to sign malicious software, it could take another two weeks or more before that revocation had trickled down to all active Macs. One of the advantages of the newer OCSP approach is that your Mac can block software within minutes of Apple revoking its certificate, something we saw only too well with the recent accidental revocation of some old HP printer software.

This checking of certificates is quite separate from another phenomenon which Jeff Johnson has studied in Catalina, in which notarization checks are performed when executable code is first run. Those checks are normally only run once on any given executable, though, so while you can question whether it delivers data you’d rather not share with Apple, in practice any potential impact is far more limited than a service which operates pretty well every time you launch a signed app.

I’ll leave you to ponder whether Apple is going to dominate the world by studying all your app certificate checks on its new M1 Macs, but point out a far more real and immediate danger: Apple’s OCSP service. What happens when, as occurred last Thursday, it isn’t available?

There are fallbacks. If your Mac doesn’t have an internet connection at all, or the route to Apple’s OCSP service is blocked, your apps still open, with their certificates unchecked. It’s when that service isn’t inaccessible, but has failed, that the biggest problems arise. This is a well-known engineering problem, fail-safe design.

As Apple so devastatingly demonstrated last Thursday to millions of Mac users around the world, its design of the trustd signing certificate check doesn’t fail safe in those circumstances. It may be difficult to design a mechanism which is both fail-safe and secure, but without that, checking certificate revocation using a service is forever flawed.

I for one am very happy that my Macs enjoy these security protections, but repeatedly disappointed that there are so many weaknesses which make them unreliable. Security is only ever as good as it is reliable. When the user is denied access to their work simply because there’s a problem with a single remote service, the Mac as a computing platform is inherently unreliable. But see the Postscript below.

For those who subscribe to paranoia, even a reliable service won’t be good enough. Indeed, the only choice they have starts with building their own PC, building their own Linux, and surviving without placing any trust in vendors like Apple. That means no AppleCare, no Apple Support, no Apple Store, no notarization, and only the security which you create and maintain for yourself. If you really feel that you can’t trust Apple, then that’s your only course. And the best of luck to you in tackling the likes of Facebook and Google.


Apple announced on 16 November 2020 that “to further protect privacy, we have stopped logging IP addresses associated with Developer ID certificate checks, and we will ensure that any collected IP addresses are removed from logs.” It will also be making the following changes over the coming year to the OCSP mechanism which Macs use to check for revoked certificates:

  • “a new encrypted protocol for Developer ID certificate revocation checks”;
  • “strong protections against server failure”;
  • “a new preference for users to opt out of these security protections”.

I’m very impressed: this must be one of the fastest and most complete responses of its kind. Thank you, Apple.