hoakley February 3, 2019 Macs, Technology

Last Week on My Mac: The secrecy of privacy

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.

8Comments

Add yours

1

Robert William Leach on February 3, 2019 at 12:14 pm

I’ve been doing just what you suggest. I’ve been blogging (some of) my Apple feedback. Whenever I submit feedback to Apple (if it’s significant feedback), I also blog it under a topic heading called “Today’s Apple Feedback”. If I haven’t yet blogged about it, I save my feedback as a text file in my blog ideas folder. Ive got dozens of submissions in there and there’s been one brewing about Mojave for the past week.

LikeLiked by 1 person
- 2
  
  hoakley on February 3, 2019 at 11:56 pm
  
  Thank you.
  I wish you success with your campaign, but wonder if a bigger and more general campaign using popular social media, like Twitter, wouldn’t get a bit more traction?
  However, judging by the lack of responses here, it looks like most users, sysadmins and developers seem quite happy spending a lot of time finding out what Apple should be delivering us in its documentation. Given the cost of our time, that seems surprising. No wonder Apple generates such vast profits.
  Howard.
  
  LikeLike
3

Jacques Distler on February 4, 2019 at 4:17 pm

I’ll wager that TCC isn’t documented because Apple is expecting it to continue to change.

In your previous article, you were able to get cmpxat to work, essentially by granting full disk access to Terminal.app. Any command run from Terminal.app now has full disk access. But what happens if you want to run cmpxat from a shellscript or a cron job or whatever? Presumably, that still fails, and I am totally in the dark as to how you could go about granting it the necessary access permissions.

This seems like a mess that needs to be cleaned up before making it a publicly-documented API. Thanks, Apple, for inflicting alpha-quality software upon us all!

LikeLiked by 1 person
- 4
  
  hoakley on February 4, 2019 at 6:27 pm
  
  Thank you.
  I haven’t seen any significant change in terms of the interface to TCC since 10.14 was released, and its main features seem to have been stable rather than changing. Of course change is never a valid reason for not documenting: it may have been when Inside Mac was a series of printed books, but everything is online now and easily updated, particularly when you can be bothered to tell developers and users that things have changed.
  The solution to ‘orphaned’ commands being run without Terminal.app at the head of their Attribution Chain seems to be to add that command to the Full Disk Access list. If that doesn’t work, then use Taccy to check the log and see what TCC considers to be its attribution chain – hence that feature in Taccy. There’s no other way that I know of querying TCC to discover the chain.
  Howard.
  
  LikeLike
5

Michael Tsai - Blog - Mojave Privacy Protection Aftermath on February 5, 2019 at 9:29 pm

[…] Howard Oakley: […]

LikeLike
6

Sebastian on February 7, 2019 at 2:54 pm

I’m neither a developer nor on Twitter, so I can’t contribute to this cause directly. But generally, I would suggest that the best target for such campaigns might actually be—in part for reasons you’ve already mentioned—top executives, possibly Tim Cook himself. Given that relative to Apple’s vast customer base, those unhappy with improper technical documentation (and similar specialized issues) are surely a miniscule fraction, attention will hardly be gained by the sheer volume of (hypothetical) complaints; so any force such a campaign might have would have to come from well-reasoned and coordinated complaints directed at those who are actually responsible (and are also the only ones with the means to actually change something).

The apparent lack of interest in your initiative does indeed speak volumes about how Apple has estabilshed a form of customer acceptance that, if anything, only reinforces the strategies the company has chosen to pursue in recent years. It almost seems like users dogmatically (or should I say religiously?) consider what Apple offers them as that which, by definition, must be of the highest standard, just like Apple presents and sells itself as the company that is producing and “serving” to those same standards, no matter how pressing and glaring and increasingly worrisome the issues with the actual products become and how far the company drifts away from actually fulfilling reasonable quality standards. (And then again, it’s not like we’re at the software quality levels a Windows user is accustomed to—yet…)

I do applaud your initiative, even if it turns out there is not much of an audience for it. I indeed think the economic behemoth that is current-day Apple can only be influenced—short of outright refusal to buy its products or genuine economic disasters, which are both unlikely in the near future—by a sufficiently forceful amount of publicly declared dissatisfaction. At least I can’t think of another thing that could indicate to Apple that their bottom line might actually be in danger (which, in turn, is most likely the only thing that in Apple’s own mind could ever effect a change of heart about its established strategies and practices). But I needn’t stress how far we are from such a public outcry even beginning to build up. Much rather, as I said above, the opposite seems to be happening: happiness abounds, and where not, problems are considered “the way it is”, or even “has to be”, rather than something that might be wholly unnecessary and easily avoided were there no more than basic professional care for proper product development, and also some basic respect for the needs of the users buying those products (as opposed to their dollars).

All those ill-advised behaviors and decisions on Apple’s part (many of which you document here) may (or may not) come back to hurt Apple at some point in the future. But for the time being, I’m afraid there is so much inertia in this economic tandem of Apple the giver and the user the taker that there is little hope of anything turning for the better, at least unless Apple itself spontaneously decides to change its definition of what is better and good—which I don’t see happening either.

LikeLiked by 1 person
- 7
  
  hoakley on February 7, 2019 at 8:23 pm
  
  Thanks.
  I think Apple is already hurting because of its lack of documentation: this isn’t just external documentation, but from the bugs we are seeing now, its own engineers often lack key documentation, which is making it harder to develop code, and increasing the rate of bugs.
  Howard.
  
  LikeLike
8

Weekly News Summary for Admins — 2019-02-08 – Cebu Scripts on February 8, 2019 at 10:19 pm

[…] Last Week on My Mac: The secrecy of privacy – Howard Oakley […]

LikeLike

·Comments are closed.

Share this:

Related