Archive for September 10, 2018

Monday, September 10, 2018

Mojave’s New Security and Privacy Protections Face Usability Challenges

Rich Mogull:

Apple has been inching down this path of protected files in macOS since it introduced Gatekeeper and sandboxing. With each release, Apple has tightened the sandboxing screws to limit the traditionally near-unfettered access of apps.

[…]

You might be thinking that there’s quite a bit more that deserves protection, and you’d be right. In fact, Mojave extends protection to data in Mail, Messages, Safari, Home, Time Machine, and certain administrative settings, but without the granular notifications of the data types we’ve been discussing. Apps can request access to data in Mail or Messages or Safari too, and they’ll appear in the Full Disk Access list in the Privacy pane of the Security & Privacy preference pane.

I don’t think there is actually a way for apps to programmatically request Full Disk Access.

Apple needs to improve Mojave to provide both developers and users with clear alerts that avoid the pitfalls that crippled so many similar attempts in the past. There’s a reason any mention of Windows Vista still sends shudders down the spine of anyone who worked a help desk during those perilous times. And the company needs to improve the current situation for anyone who creates AppleScript-based apps to make sure such apps don’t prompt constantly for access.

Luc Vandal:

Well this is going to be fun in a couple of weeks!

See also: xkcd.

Previously: AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms, Apple Events Usage Description, Call Recorder for FaceTime Won’t Be Compatible With Mojave, Ghostery Lite, Little Flocker.

Update (2018-09-11): Christopher P. Atlan:

Even with full disc access apps can’t access rootless_mkdir folders (a.k.a DataVaults). So a backup app can’t make a perfect replica.

Update (2018-09-13): Howard Oakley:

Important lessons for Mojave early adopters are:

  • Mojave’s privacy protection extends to some folders beyond your Mojave startup disk; these aren’t currently documented, but include /Library/Applications Support/com.apple.TCC.
  • When you think an app needs to be given Full Disk Access, it may actually be a helper tool which must be added to the Privacy settings, not the app itself. This appears to be a special case to the rule that command tools are traced through their Attribution Chain to the ‘parent’ app which called them in the first place: in this case, adding the C3 app to Full Disk Access doesn’t give its command tool helper com.bombich.ccchelper full disk access. This may be because it is run as a Launch Service, but none of this is documented.
  • Third party apps which use helper tools, as C3 does, need to be provided with a mechanism similar to that in C3 to guide the user through the process of adding their helper tools to the Full Disk Access list, when required. As far as we know at present, that cannot be performed by the app, but requires the user to make that addition. Users can add command tools to the Full Disk Access list, but need to be helped to do so.

Update (2018-09-19): Mike Bombich:

If you would prefer a simple “CCC is trying to access your data, would you like to allow that? Allow/Deny” dialog – hey, so would we! I spoke with members of Apple’s Privacy Team at Apple’s developer conference in June, and I suggested offering such a dialog for notarized applications – apps that Apple has deemed to be free of malware. They were adamant that users should not get a simple dialog; they want it to be hard for you. If you’re feeling Mo’hassled by Mo’jave, let Apple know that you’d like a simpler UI for granting full disk access to notarized apps.

Update (2018-09-24): Patrick Wardle:

Mojave’s ‘dark mode’ is gorgeous ...but its promises about improved privacy protections? kinda #FakeNews

Update (2018-09-26): Dave Nanian:

Looks like our little Finder Extension, built with Automator, doesn’t work under Mojave.

It also doesn’t prompt for authorization. Because AEApocalypse.

Automator actions run from Services menu don’t prompt for AppleEvents - bug 44799942 - sigh.

Update (2018-10-03): Howard Oakley:

A few who have upgrade to Mojave are finding apps which either don’t display the expected consent dialogs, or display them once and never again, so preventing them from giving that app access to protected data or services. Here’s what to do if you are having problems.

Ettore Software:

6: Over on the right, locate TypeIt4Me in the list of apps that are allowed to control your computer

7: Untick the checkbox next to TypeIt4Me, then tick it again and close System Preferences

Shane Stanley:

Nonetheless, there has been no formal direct announcement, so this will come as a shock — and pain point — for some users. If you use third-party additions, you will need to start looking elsewhere for equivalent functionality. Either AppleScriptObjC or some of the publicly available script libraries offer similar abilities to some of the commonly used commands, and it’s possible some addition authors will offer equivalent or similar functionality in faceless background applications or script libraries.

Update (2018-10-05): Daniel Jalkut:

As an alternative, I wonder if Apple could introduce some kind of “Security Profiles” feature for Terminal so that individual windows within the app could be run when different permissions? This could build on Terminal’s existing support for “Profiles” which already support varying Terminal settings dramatically on a per-window basis.

Howard Oakley:

If you’re suffering problems with TCC, in particular when you have an app which should be generating a consent dialog but doesn’t, as well as checking that app’s entitlements and usage strings using Taccy, try inspecting the log with the single predicate 'subsystem == "com.apple.TCC"' and looking for an exchange involving that app’s ID. It is easy to do that in Consolation 3, as you can make the app’s ID a filter, rather than part of the predicate. Once you have located the relevant log entries, remove that filter and browse all the messages from TCC around that time.

If you’re struggling to work out what to add to your Full Disk Access list to get a command to work, then you should be successful when you add the item listed in the ACC field of the Attribution Chain shown by TCC.

Update (2019-01-04): John Martellaro:

What I had the most fun with was the more thorough app authorization required in Mojave. My first encounter was the most striking and annoying.

[…]

I mention this procedure because I am sure that, back in September, there was a lot of literature about Mojave’s additional app authorizations. But if you wait, as I did, the articles explaining it all fall off one’s radar. This is one reason to, nowadays, upgrade ::cough:: soon after the rest of the community does, even on a production Mac.

Update (2019-09-18): Craig Hockenberry:

This is the key: my backup script has been failing silently with “operation not permitted” for who knows how long — only today did I discover it — and that my backups were incomplete.

[…]

From the dev forums they previously said they don’t plan on changing the behavior. Nor is there an easy way for a program to tell if they have Full Disk Access or not. We fell back on querying the contents of a directory we know should exist and if that fails prompt for FDA.

“git log --follow” Enthusiastically Tracks Empty Files

Mark Dominus:

This bug I just found in git log --follow is impressively massive. Until I worked out what was going on I was really perplexed, and even considered that my repository might have become corrupted.

[…]

It appears that Git, having detected that book/Watchmen.blog was moved to movie/Watchmen.blog in Febraury 2012, is now following book/Watchmen.blog backward in time. It sees that in January 2012 the file was modified, and was formerly empty, and after that it sees that in June 2009 the empty file was created. At that time there was another empty file, wikipedia/mega.notyet. And git-log decides that the empty file book/Watchmen.blog was copied from the other empty file.

At this point it has gone completely off the rails, because it is now following the unrelated empty file wikipedia/mega.notyet. It then makes more mistakes of the same type.

Update (2018-09-14): Mark Dominus:

The roadblock is: how does --rename-empty fit together with my proposed --rename-size-threshhold flag? Should they be the same thing? Or should they be separate options? There appear to be at least three subsystems in Git that try to decide if two similar or identical files (which might have different names, or the same name in different directories) are “the same file” for various purposes. Do we want to control the behavior of these subsystems separately or in unison?