Mac Geekery

Just to update this topic, the “Locum” file in Leopard doesn’t contain the “srm” string any more, and ‘/usr/bin/srm’ apparently is no longer involved since “Secure Empty Trash” seems to work just fine when it has been removed.

However, the “Finder” executable now contains the string “_FXSecureEmptyTrashLevel” and it turns out this can be used as a property in the “com.apple.finder.plist” file. So potentially, no more hacking of executables required to change how “Secure Empty Trash” deletes files.

In terms of the values that “_FXSecureEmptyTrashLevel” accepts, there is probably some underlying logic but beyond the fact that they should be numerical (the actual data “type” doesn’t seem to matter), it’s a bit of a puzzle to me. From trial and error, a value such as “-1” (the minus sign is important) results in the 35 passes (following the Gutmann algorithm) to be used. The equivalent of ‘srm -s’ (a single overwrite with random data) results from a value of eg. “9” (or others ending in “9”). So far, I haven’t stumbled on an actual numerical value that gives the default 7 passes, although that is what is used in the absence of a “_FXSecureEmptyTrashLevel” property, or with what are perhaps invalid values such as non-numeric strings or booleans.

Somewhat disturbing is the fact that many values will cause “Secure Empty Trash” to delete the file insecurely without overwriting it at all, and without any notification to the user (as of 10.5.2 anyway). This is much worse than 10.4 or 10.3 where a file that was unsuccessfully “secure deleted” would at least be left in place so that the user would notice that it didn’t work. Now, people may be left with a false sense of security, not realizing that pieces of their data may still be on the hard drive ripe for the picking. It raises the question of whether secure destruction of data can be entrusted to the “Finder”…