Imagine playing a team sport, and midway through a match the referee tells you that all the rules have changed, but they’re not telling you how, just that what you have been doing so far has been banned – in part.
That is, in effect, what Apple has done with Mojave’s privacy protection. More than six months later, with just a few months to go before it will undoubtely all change again in macOS 10.15, the only coherent account of this extensive new subsystem within macOS is a single presentation made at WWDC last June. Yet Apple knew that these changes brought lots of problems to developers, system administrators, and users alike. If there was one issue which was raised time and again during Mojave’s beta testing, it was negotiating privacy protection.
Before Mojave’s public release, Apple’s alarm bells should have been ringing. Several well-argued blog articles pointed out serious issues which were inevitable unless changes were made. Tweaks and fixes did happen, but Apple didn’t respond to any of the issues raised by explaining how to negotiate the problems remaining.
Take one very general issue: running a command tool which needs access to protected folders on a Mac. Although a task which a lot of developers need to do, this appears to have been omitted completely from the presentations given at WWDC last June. Neither is it documented in any article or guide provided by Apple which I have been able to locate.
The earliest reference that I can find to the mechanism used to run command tools under Mojave’s Transparency Consent and Control (TCC) is my article here on 28 August 2018, when it was still in beta. By examining the log, I noticed that TCC was using what it termed an Attribution Chain, at the head of which is normally a GUI app like Terminal.
For the last five months, I have looked high and low in Apple’s developer and user documentation for an official account of this, and information as to how TCC determines the Attribution Chain, which in turn informs us – developers, sysadmins and users alike – which app or tool we should add to the Full Disk Access list.
You already know the answer: Apple has not even mentioned any of this. Mojave’s privacy protection is undocumented, by Apple at least.
Maybe this is on grounds of security?
If that was true, then Apple would be trying to achieve security by obscurity, widely known as a fool’s choice. This has been repeatedly debated in many different contexts since it was first examined objectively back in 1851. I cannot seriously believe that explaining to us how to use command tools successfully with TCC could compromise its security, and if that really were the case, then TCC is a house of cards waiting for a puff of wind.
The only explanation that I can come up with is that Apple is prepared to invest substantial sums in engineering what is effectively a major new sub-system in macOS, and in promoting its claim to provide users better privacy than its competitors, but won’t invest a cent in explaining to those same users how to work with its new sub-system.
In other words, Apple doesn’t document macOS for its users and developers purely to lower its costs, hence to increase its profits, as proper documentation would cost it (relatively little) money.
Instead, we all have to invest our time and money discovering how to use this undocumented sub-system, something that simply doesn’t register with Apple or its bottom line. I’m sure that since last June, there have been plenty of issues recorded in Apple’s Bug Reporter which result from this lack of documentation. That’s fine, because it’s a confidential reporting system, and no one outside Apple has any idea of the scale of those reports.
What if – whenever we expend significant time trying to solve a problem which should have been readily addressed had Apple spent a little money on documentation – we were to declare this in a public place? Maybe something like:
Two days to discover which app in TCC’s Attribution Chain, due to lack of docs
as a tweet? Should we @ this at an appropriate official address, or give it a suitable hashtag, perhaps?
I’m loathe to suggest that these should be send to @AppleSupport, who invariably seem to struggle as much as we do from Apple’s no-documentation policy. Equally, this is not a problem for Apple engineers to be bothered with. I’m sure that every good engineer is as distressed by this policy as we are.
But until we start shaming Apple into doing something about this, we will continue to stumble along in the dark, effectively giving our time and effort freely to bolster Apple’s profits.