how to stop Sierra sneakily downloading to your mac


I’ve not been very happy with Apple this week. Not only are they mistreating developers, but they’re also mistreating their customers.

If you have chosen not to upgrade to Sierra for some reason, but your mac is both compatible and has enough disk space for the Sierra download, Apple’s servers may download the entire 5GB Sierra installer to your machine without asking you for permission first.

If you have data caps, or are on a plan that offers differential pricing depending on time of use, this could totally ruin your month.

If you want to ensure that Sierra does not silently download to your mac, you’ll need to uncheck the ‘Download newly available updates in the background’ option in App Store’s Preferences pane in System Preferences (see image above).

Who knew by ‘updates’ that Apple were going to include upgrades of 5GB when they ticked that box? Well, now you do!

Unfortunately, your decision not to upgrade to Sierra won’t stop Apple infecting your machine with it’s own little adware notification, and you’re likely to see this at some point or another:


Screen Shot 2016-10-04 at 22.06.30.png

Note that there is no option to say “Don’t remind me again”, so there’s no telling how often you’ll be irritated with this unwanted pop-up.

Hmm, whatever happened to old-fashioned good manners, aye Apple?  ;)


Navigation markers added to SD6


The recent update to Script Debugger 6 added a subtle, but much-needed new feature.

Now, scripters can take advantage of the same kind of navigation markers familiar to users of Xcode (pragma marks) to quickly navigate to user-defined sections of the script.

Scripters can now create a marker with a double-dash and double arrow marker, followed by whatever label they choose.

-->> myMarker here!

For me, this is a great boon, and I’ve changed all the section headings in my templates to the new navigation marker syntax, meaning I can easily jump to the various sections from the Navigation bar at the top of the script.


Further Reading:
Script Debugger 6: The Complete Review

iCloud Drive “file couldn’t be opened”



Today I encountered a problem in which none of my files on iCloud could be opened. The issue (almost certainly self-inflicted after I’d been poking around in iCloud’s underbelly…) was peculiar in a couple of ways.

Although all files refused to open, Quick Look had no problem displaying every file’s contents (shame that we lost the ability to cut and paste from Quick Look in El Capitan, as that would have presented me with an option for recovery). Another oddity was that iCloud files that were currently open could still be saved to, but once closed, refused to open, showing the dialog above. Yet more worrying was that neither copying and pasting a file to another location outside of iCloud with the Finder nor trying to restore from Time Machine worked.

Logging out and logging back in again also did not resolve the problem, as I’d hoped. However, I was prevented from just trying a full restart as I had critical processes running elsewhere on the computer.

One option that I successfully employed was to use the ditto tool on the command line to copy a Pages document to another location (note that the Pages format is actually a directory rather than a single file, so ditto is a good tool for this). However, while this might be useful in an emergency, it’s hardly a practical solution to repairing the whole of the iCloud Drive.

Instead, I took the seemingly scary option of unlinking the mac from iCloud Drive in System Preferences > iCloud. You’ll get a warning like this:


I then re-enabled iCloud in the hope that this would refresh whatever it was that had become out-of-sorts. Unfortunately, that still didn’t work. I next tried unlinking again, logging out and re-linking after logging in. Still no dice, and by this time I was sufficiently worried that there was nothing for it but to halt all my other activities on the computer and try a restart. Possibly the system holds something in a memory cache that needs to be flushed, I’m not sure. In any case, I took the step of unlinking iCloud first, then restarting, then re-linking after reboot. Success (and relief)!

I don’t fancy trying to reproduce the issue to see if the reboot alone would have solved it, but that would be my first step if the issue occurs again. Otherwise, the unlink, reboot, and re-link method seems to do the trick.


Dropbox hack blocked by Apple in Sierra


With the release of the latest version of the Mac operating system, 10.12 macOS Sierra, it’s pleasing to see that Apple have fixed a bug I reported against El Capitan in October of last year, and wrote about on this blog here and here.

The TCC.db is now under SIP, which means hacking the Accessibility preferences is no longer possible.

The bug basically allowed anyone to circumvent the authorisation warning to place an app in the list of Accessibility apps in System Preferences > Security & Privacy. It still required sudo, but an app (Dropbox being the most high profile offender) that got your admin credentials in other ways could insert itself into Accessibility and make it almost impossible for the user to remove.

Users can still alter Accessibility in the normal way (through Sys prefs GUI), but trying to hack the SQL database via Terminal now returns:

Error: attempt to write a readonly database.

Looking at xattr in Terminal for /Library/Application\ Support/ confirms this with the reply: TCC

Hopefully, this fix will be ported to EC as well. At the moment, it’s still possible to run this hack in OS X 10.11.6.


how to clear recents from a Dock tile


One handy feature of Dock tiles is they work with Expose to let you easily see recent documents. For example, even without launching Scrivener, I can hover over its Dock tile, swipe down with four fingers on the trackpad and get a look at my recent Scrivs, as shown above.

The only problem is, sometimes Dock tiles get in a mess. Take a look at my Script Editor recents list:


Hmm, not a very helpful list. And yet, there isn’t an easy way to clear it either. You might think that using the ‘Clear menu’ option in the menu bar might do the trick, but on it’s own, it won’t. It’ll clear the list in the menu bar, but not in the Dock tile.

The trick is to kill the Dock process after using the menu command. So

1. Launch the app in question
2. Choose File > Open Recent > Clear menu
3. Quit the app.
4. Now launch the, and on the command line execute killall Dock

And with that, you should have a nice clean Dock tile for that app:


Hope that helps!🙂

applescript: remove characters from a string

Screen Shot 2016-08-26 at 18.01.54

One of the things I’m often finding myself doing is trying to remove characters from strings, particularly html codes and other markdown clutter. Rather than laboriously messing around with offsets and the like, we can make our lives simpler by making a quick handler that leverages Cocoa’s stringByReplacingOccurrencesOfString method.

For example, suppose you’ve got a sourceString containing something like this

Screen Shot 2016-08-26 at 18.08.57

We can strip all the tags out by calling our handler like this, once for the opening tags and again for the closing tags. Note how the variable names have changed in the second call:

Screen Shot 2016-08-26 at 18.13.06

The beauty of this is it doesn’t just remove one instance of the tag, it removes all occurrences of them, so this handler is a real life-saver when you’ve got a whole page of markdown to clean.

To achieve this you’ll need to add a couple of declarations to the top of your script, as well as the handler:

Here’s the declarations you’ll need:

use scripting additions
use framework "Foundation"
property NSString : a reference to current application's NSString

Here’s the code for the handler:

on remove:remove_string fromString:source_string
set s_String to NSString's stringWithString:source_string
set r_String to NSString's stringWithString:remove_string
return s_String's stringByReplacingOccurrencesOfString:r_String withString:""
end remove:fromString:

Enjoy! 🙂

which macs can upgrade to Sierra?

Screen Shot 2016-08-21 at 13.36.22

With macOS 10.12 Sierra due out sometime this month, some will no doubt be wondering whether their current mac will make the cut.

First thing you’ll need to know is your model identifier. If you’re using DetectX or FastTasks 2, it’s displayed at the top of the Profile log. In FastTasks 2, you can also find it in the menu under ‘Model Overview’.

Screen Shot 2016-08-21 at 14.09.05

If you’re not using either of those, you can get your model identifier from  > About This Mac > System Report… Look for ‘Model Identifier’ under the Hardware Overview section.

Barring any unlikely last minute changes from Apple, here’s the full list of models that are supported:








discovering how Dropbox hacks your mac

Screen Shot 2016-08-26 at 23.05.27

Update: Dropbox hack blocked by Apple in Sierra

Following my post revealing Dropbox’s Dirty Little Security Hack a few weeks ago, I thought I’d look deeper into how Dropbox was getting around Apple’s security.

After a little digging around in Apple’s vast documentation, it occurred to me to check the authorization database and see if that had been tampered with. According to the docs:

In a policy-based system, a user requests authorization—the act of granting a right or privilege—to perform a privileged operation. Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server—used to obtain the user’s password or other form of identification, which also ensures consistency between applications. The Security Server—a Core Services daemon in OS X that deals with authorization and authentication—determines whether no one, everyone, or only certain users may perform a privileged operation.

The list of authorization “rights” used by the system to manage this “policy based system” is held in /var/db/auth.db database, and a backup or default copy is retained in /System/Library/Security/authorization.plist.

Looking at the default with

defaults read /System/Library/Security/authorization.plist

we can find that there is an authorization right for System Preferences’ Accessibility list, which says:

"system.preferences.accessibility" = {
class = user;
comment = "Checked when making changes to the Accessibility Preferences.";
group = admin;
shared = 0;
timeout = 0;

That file’s comments also state that “The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false if not specified.”

In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences. Is it possible then, that Dropbox had overriden this setting in the auth.db? Let’s go and check!

To see what the current policies are, you have to actually read the sql database in /var/db/auth.db. There’s various ways of doing that, but the easiest for me was to access auth.db through the command line using the security tool. Issuing the following command in Terminal will return us the currently active policy for Accessibility:

security authorization read system.preferences.accessibility

On my machine, this returned:

Screen Shot 2016-08-26 at 20.57.12

Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac.

Security on OS X is a complex beast, however, and there are other authorization protocols at work. One that I already knew of is tccutil. If you issue man tccutil in Terminal, you’ll see this:

tccutil(1) BSD General Commands Manual tccutil(1)

tccutil — manage the privacy database

tccutil command service

The tccutil command manages the privacy database, which stores decisions the user has made about
whether apps may access personal data.

One command is current supported:

reset Reset all decisions for the specified service, causing apps to prompt again the next time
they access the service.

To reset all decisions about whether apps may access the address book:

tccutil reset AddressBook

Darwin April 3, 2012 Darwin

I had heard of a hack of this utility that was related directly to adding apps to Accessibility list over a year ago when I stumbled across this stackexchange page. In short, what that hack suggests is that you modify tcc directly by inserting an entry into the sql database located here /Library/Application Support/

You can read the current list with the command:

sudo sqlite3 /Library/Application\ Support/ 'select * from access'.

To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue:

sudo sqlite3 /Library/Application\ Support/ “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);”

(*note the code given on the stackexchange page isn’t quite correct for the latest builds of the mac operating system, in which the access table now has 7 columns and so requires and extra “NULL” on the end as shown above).

I tested this with several of my own apps and found it worked reliably. It’ll even work while System Preferences is open, which is exactly the behaviour I saw with Dropbox.

It remained to prove, though, that this was indeed the hack that Dropbox was using, and so I started to look at what exactly Dropbox did after being given an admin password on installation or launch. Using DetectX, I was able to see that Dropbox added a new folder to my /Library folder after the password was entered:

Screen Shot 2016-08-26 at 21.36.35

Screen Shot 2016-08-26 at 21.37.09

As can be seen, instead of adding something to the PrivilegedHelperTools folder as is standard behaviour for apps on the mac that need elevated privileges for one or two specialist operations, Dropbox installs its own folder containing these interesting items:

Screen Shot 2016-08-26 at 21.40.45

Not one, but three binaries! I wonder what they do? The first thing I did on each was to run the strings command on them. I still haven’t determined what that 1.5MB DropboxHelperInstaller binary is doing (that’s pretty big for a binary for a helper app), but its jam-packed with strings relating to file compression and encryption. The string output for dbfseventsd binary didn’t reveal anything much interesting, but with the deliciously named dbaccessperm file, we finally hit gold and the exact proof I was looking for that Dropbox was using a sql attack on the tcc database to circumvent Apple’s authorization policy:

Screen Shot 2016-08-26 at 23.05.27

This is all the more telling when we look at what Dropbox themselves say when queried about why their app is in the list of Accessibility apps here. After a great deal of obfuscation, misdirection and irrelevance in which they mention everything about permissions in general and nothing about Accessibility in particular, or that they’re hacking their way into the user’s Accessibility list rather than going through the supported channel of presenting the user with a dialog box and asking for permission, comes this line:

we need to request all the permissions we need or even may need in the future.
(my emphasis)

Ostensibly, that’s in the context of Drobpox on mobile apps, but since the question isn’t related to mobile apps at all, I think interpreting anything said there as being honest is naive at best. What I do suspect, especially in light of the fact that there just doesn’t seem to be any need for Dropbox to have Accessibility permissions, is that it’s in there just in case they want that access in the future. If that’s right, it suggests that Dropbox simply want to have access to anything and everything on your mac, whether it’s needed or not.

The upshot for me was that I learned a few things about how security and authorisation work on the mac that I didn’t know before investigating what Dropbox was up to. But most of all, I learned that I don’t trust Dropbox at all. Unnecessary privileges and backdooring are what I call untrustworthy behaviour and a clear breach of user trust. With Apple’s recent stance against the FBI and their commitment to privacy in general, I feel moving over to iCloud and dropping Dropbox is a far more sensible way to go for me. For those of you who are stuck with Dropbox but don’t want to allow it access to Accessibility features, you can thwart Dropbox’s hack by following my procedure here.


Further Reading:

Dropbox hack blocked by Apple in Sierra

Revealing Dropbox’s Dirty Little Security Hack

Hackers steal over 60m Dropbox user account passwords

How keyloggers get around OSX Security


make a Sierra USB bootable installer

Screen Shot 2016-08-21 at 13.06.29
For those participating in Apple’s public beta program or developer program, here’s a script that will make a bootable flash drive installer of Sierra for you. Of course, you’ll need to have downloaded and saved the original installer before running it on your mac for this to work.

When an installer is made available to you from Apple, the first thing to do after downloading it is to quit the installer if it auto runs. Insert your blank USB thumb drive, and make sure it’s at least 8GB (16GB recommended).

Screen Shot 2016-08-21 at 13.36.22

You can either run the script immediately with the installer app still in your /Applications or /Downloads folder, or you can move the installer first to your preferred location. It doesn’t make any difference to the script since it’ll ask you for the location of both the Installer and the USB drive before doing its thing. It’ll also give you an option to cancel out if you made any mistake in specifying the location or you just change your mind. The script will ask you for an administrator password as it needs elevated privileges to run the createInstallMedia routine.

Note the script continues to run in the background until the installer has been created. It sleeps for an interval of 10 secs between checking the job status. Since it takes around ten minutes for the createInstallMedia routine to finish its work, you could comfortably increase that sleep time 30 secs or more if you desire. The script will present you a dialog when it detects all is done:

Screen Shot 2016-08-21 at 13.37.32

To use the bootable installer, just pop it into a mac, reboot holding down the ‘option’ key and choose the USB drive to kick off the installation process on a partition of your choice.

The full script is available here.


how to fix a ‘file in use’ problem


Sometimes when you try to eject a disk, unmount a volume or empty the Trash, you get caught out by some app or process that’s using the file and won’t release it. This is usually signalled by a warning dialog telling you the said file is “in use” or is “locked”.

Part of the difficulty of dealing with this problem is that the warning message may not actually tell you which process is hanging on to the file or give you any options on what to do next to solve the problem.

Sounds like a job for a quick bit of bash scripting then!

We’ll write a one-stop script that leverages a few different command line utilities to help us out here. First, our script will call fuser to report the processes using the file. Then it’ll use ps to get those processes’ ID numbers and, after asking us to confirm what we want to do, it’ll feed those to the kill command to quit them and release the file.

The whole script is available here.

To use it, save the script as a plain text file in the root of your home folder (alternatively, save it in an /sbin folder. You can do echo $PATH on the command line to get a list of places you can save it to if you’re not sure).

Secondly, give it executable permissions with

chmod +x <script name>

When the problem strikes, jump into Terminal and type

./<script name>

Add a space, then type or drag the file from Finder onto the command line and hit ‘return’ if necessary. The script will do the rest.

In the image below, I first gave my script (named ‘releaseFile’) exec permissions. Then I called it and chose ‘a’ to quit all processes holding on to the file (in this case, only one process).


Hope that helps. Enjoy!🙂

%d bloggers like this: