This week has been a quiet news week, which is probably a good thing. What with the election shenanigans raging to and fro I’ve sort of peered at the news with a cautious, jaundiced eye and been pleased that the default recommended behavior has not – for once – been to actively recoil. When we’re living in a world where my news feed is sending me stories about byzantine security measures in macOS and not doubling up on every specie and varietal of The Current Apocalypse then I’m prone to taking the win. It’s the little things, etc.
Still, some little things are – depending on where your priorities lie – big things. I refer of course to the minor brouhaha about macOS and GateKeeper – the former being a hugely popular and recently updated operating system (you may have heard of it) and the latter being Apple’s ingenious quarantining mechanism designed to keep nasty things from happening to your Mac. The current controversy kicked off with an article from November 12th which pointed out that with the advent of Big Sur/macOS 10.16/macOS 11 Apple was constantly collecting a lot of information about what programs you were opening, where you were when you opened them, what the time and date was, and what computer you were opening them on. Further, it noted that as a partner in PRISM Apple was essentially turning all this data over to The Powers That Be in order that Big Brother can track your every movement.
This, I’m sure we can all agree, sounds Bad. But – as in so much of life – an ounce or two of perspective can often throw things into a different light.
First of all, what the heck is GateKeeper?
Good Question.
Thanks!
GateKeeper’s ancestor was a system that Apple put in place back in 2007 which eventually evolved into a two-part mechanism designed to make sure that anything you download and install on your Mac isn’t riddled with malware. Initially it was a pretty basic tool; applications downloaded to your computer were quarantined until you explicitly gave permission to open them for the first time, and provided you knew what you were doing (or were at least prepared to say that you knew what you were doing) then the presumption was that nothing was apt to go awry. A year or two later Apple upgraded the system so that Mac OS X would check the downloaded application for known malware threats, and then the whole thing was spruced up again with Mac OS X Lion to incorporate signed apps.
And it’s this mechanism – the checking for signed apps – that’s really the crux of the recent concern. In a nutshell, here’s how the process works.
- A developer – let’s call him Dave – wants to write a macOS application. He signs up for an Apple Developer account, goes and bangs out his masterpiece in Xcode, and signs it with a certificate denoting his Developer ID.
- A customer – let’s call him Bob – purchases this amazing application. When he runs it, his Mac looks at the application, notes the certificate that Dave signed it with, then sends an inquiry to Apple to make sure that the application is legitimate and actually written by an actual Apple-approved Developer. Said inquiry is in the form of a hash that contains an identifier of the application that’s being opened.
- The OCSP (Online Certificate Status Protocol) responder at Apple looks at the hash it’s been sent, notes that yes, everything looks okay, and then tells Bob’s Mac that the application is okay to run.
This system is not without its flaws, but they tend to be the obfuscatory variety and not the destructive sort. The worst of the bunch is that occasionally a developer certificate will expire, so when the application is launched the hash pushed to OCSP is refused, leading to a lot of frustrating inabilities to open the application. Fortunately, renewing a developer certificate is a relatively simple process.
There’s also been some alarm about the fact that these hashes are sent with non-encrypted http instead of https, although logic dictates that if you use a certificate-encrypted https session to check for an OCSP certificate then you’ll first need to decrypt the https certificate, and eventually it’s certificates all the way down, which would at least give all the elephants something to look at.
Still, the idea that your computer is constantly sending a stream of information about what applications you’re running out to The World™ sans encryption isn’t a great look. So much so that Apple has published an updated document on the subject, thus.
It’s comforting to read that kind of thing, but one should also trust and verify. Thankfully, a lot of that kind of heavy lifting is done by better and wiser minds than mine; for example – Jacopo Jannone, who published an article that did a fascinating deep dive into the OCSP process. I’d encourage anyone who’s remotely interested in looking under the hood of their computer to follow his process. I mean, I know that I did; using Wireshark to capture an OCSP request for CodeRunner.app I was able to pull the serial number of the application and match it to what was being sent to OCSP, as well as noting that once that was sent the first time the app was opened after a reboot no further requests were sent, even after opening and closing the app.
So, a storm in a teacup, then. Apple isn’t tracking your every move via application opening and closing (or if they are then they’re doing a shockingly inefficient and terribly-implemented job of it). There’s still a temptation to disable your Mac’s ability to go talk to OCSP but that’s a temptation to be metered or avoided. Gatekeeper might seem like some authoritarian mechanism, but it’s a vast improvement on the absence of any kind of check or balance. In a world without rational, transparent security – even the kind that leaves an uncertain taste in your mouth, it’s all too easy to end up with a fully open sandbox where applications can run unmetered and unchecked, and send a lot more information out than the time and date you anonymously open a browser…