Secure Empty Trash missing on El Capitan

babowa wrote:

FWIW, I've never used it - it is superfluous unless you are selling the Mac or regularly allow others access to your machine.

As babowa probably knows, El Capitan's Disk Utility does offer a secure erase function that is useful when selling a Mac; however, it is a whole disk erase that avoids (most of) the unreliability of the now removed secure empty trash function. For the details, open Disk Utility's builtin help & search for "Erase a Volume." The relevant section is step 4:

To prevent the erased files from being recovered, click Security Options, use the slider to choose how many times to write over the erased data, then click OK.

Writing over the data three times meets the U.S. Department of Energy standard for securely erasing magnetic media. Writing over the data seven times meets the U.S. Department of Defense 5220-22-M standard.

Note that there is no longer a 35 pass erase option -- that "voodoo incantation" finally has been removed! Also note that the DoE standard 3 pass erase is intended only for magnetic media, not SSD's. Likewise, the old 7 pass DoD 5220-22-M standard was originally written for magnetic media & is effectively obsolete, having been replaced with a set of DoD standards that specify different procedures depending on both the storage media type & the type of data it contains, up to & including physical destruction when highly classified data is involved.

Although there are differing opinions about it, most data security experts believe a single pass erase (like the second from the left slider position in the DU option) is adequate to make data that is stored on modern high areal density magnetic media hard drives unrecoverable by all but the most advanced forensic techniques, & the three pass one makes recovering significant amounts of data even using those techniques impractical.

I've always used the 3 pass erase when I was about to sell the Mac and have never used secure erase. As for my SSD in my MBP, I will be taking a hammer to it when/if the time comes and reinstall the original HD.

As I understand it, the reason the single pass erase is considered adequate for modern high density servo-controlled drives is that the head stack position is so precisely positioned & the tracks so narrow that there is no 'spillage' into the gaps between tracks & no residual vestiges of older data patterns left in the track that can be detected without disassembling the drive, extracting the platters, & using specialized (& very expensive) highly sensitive equipment to scan them for that.

It is the kind of thing a government might be able to do if they were looking for state secrets but well beyond the capabilities of a used Mac buyer or criminal hacker.

Addendum:

I’m now using Terminal’s "secure remove” (srm) function to

accomplish this since there’s now no specific solution in

the Finder, without FileVault on any disks. Older system,

no Flash drive/memory in use.

Enter srm (followed by a space) into a new Terminal window,

then drag & drop a desired file into the Terminal window at

the cursor. The full file path of the file is entered.

Press Enter. There’s no feedback except that Terminal is

indeed working to srm the file.

-russ

babowa wrote:

I've always used the 3 pass erase when I was about to sell the Mac and have never used secure erase. As for my SSD in my MBP, I will be taking a hammer to it when/if the time comes and reinstall the original HD.

As I have kept all my Macs past the point of reasonable "sell ability", I use the hammer approach

on all the drives before recycling. It is also good for frustration venting!!!

And as far as anything else on active computers, the bottom line is that if someone is

targeting a person, they will get what they want. If not from their computer directly,from

their digital imprint in the world, their internet traffic., their phone calls, and the most devious of

all Google searches. For all those really concerned, put you tin foil hats on!!!

srm will overwrite the file's storage space on the drive, but it will not touch any other location where vestiges of its data might remain. From http://srm.sourceforge.net (emphasis added)

srm is a secure replacement for rm(1). Unlike the standard rm, it overwrites the data in the target files before unlinking them. This prevents command-line recovery of the data by examining the raw block device. It may also help frustrate physical examination of the disk, although it's unlikely that it can completely prevent that type of recovery.

Too late to edit my last reply, also check out http://sourceforge.net/projects/srm/files/?source=navbar which says in part (emphasis added):

All users, but especially Linux users, should be aware that srm will only work on file systems that overwrite blocks in place. In particular, it will *NOT* work on reiserfs or the vast majority of journaled file systems. It should work on ext2, FAT-based file systems, and the BSD native file system. On ext3 srm will try to disable journaling of data, see the verbose output if this fails.

Hopefully, this is enough to convince anyone that srm is *not* a reliable way to secure sensitive data.

Do you work for Apple? If not then why the superior attitude? Clearly you have no experience in secure environments. If the issue is that Apple does not have a way to "securely delete files" from an SSD then why not just detect that and react accordingly? Is that too difficult? It certainly is not for me. It would take maybe 5 seconds to code a way to detect the type of storage being used. Secondly, dispatch somebody to code a secure solution for SSD. (We securely delete from SSD all the time.) Problem solved. If you are satisfied with this unconscionable mess so be it. But do not suggest that the rest of us do not have a very valid complaint. This is unacceptable.

Xwhite wrote:

(We securely delete from SSD all the time.)

How?

Do you work for Apple?

No one here works for Apple. It is a user to user forum. But a few of us have electrical engineering degrees and/or work on commercial file system development and spend a lot of time working at the hardware level with disks and SSDs.

So how do you securely erase an SSD when the SSD hardware never actually writes over the sectors with your data on it, or when the SSD hardware removes a chunk of cells because they no longer maintain 100% integrity, but still have some of your data in them? Or a disk drive that has replaced a sector with a spare and normal software will no longer see that sector. Or the software you were using to edit that file made a scratch copy with your data, that is separate from your file. Or the software saves your file by writing a new file, then using rename to replace the original with the new file, and the file system just frees the original file so its storage is now sitting in the free list with all your sensitive data in it? Or the operating system writes your application's memory to the page/swap files and someone scavenges the page/swap files for useful information?

I'm not trying to be superior, I just happen to know a lot about how computers, operating systems, file systems, and storage devices work.

+1

Not everyone uses Secure Empty to trash secure files. I find that if I have a file that is locked or active and I really do want to delete it, I click on secure delete and it trashes it. It's like a force trash. Without this feature I have to close out of the program, empty the trash and restart the program. It would have been easier just to keep the feature. Sometimes I think developers over think things and don't realize there are multiple uses for apps. It's frustrating that they don't really take a poll of something before they just go and delete it from the next system. My rant, I'll get off my soapbox now. The Cocktail Utility is going to give me what I need.

lcawkins wrote:

Not everyone uses Secure Empty to trash secure files. I find that if I have a file that is locked or active and I really do want to delete it, I click on secure delete and it trashes it. It's like a force trash. Without this feature I have to close out of the program, empty the trash and restart the program. It would have been easier just to keep the feature. Sometimes I think developers over think things and don't realize there are multiple uses for apps. It's frustrating that they don't really take a poll of something before they just go and delete it from the next system. My rant, I'll get off my soapbox now. The Cocktail Utility is going to give me what I need.

There is legal liability to saying you do something that doesn't really do it.

If you want a delete this file even if it is opened or locked feature, then give Apple feedback that you desire this feature.

Or write an Applescript (or Automator) script that does what you want.

lcawkins wrote:

Not everyone uses Secure Empty to trash secure files. I find that if I have a file that is locked or active and I really do want to delete it, I click on secure delete and it trashes it. It's like a force trash. Without this feature I have to close out of the program, empty the trash and restart the program.

Which is what you should do if the OS says a file in the trash is in use. Otherwise you risk several possible problems, including corrupting the trash folders (there are actually several of them) & leaving an app or an underlying process in an unstable state.

For locked files that you own that are not in use, you no longer have to unlock them. If they are locked before dragging them to the trash, you get a warning that the file is locked with the option to continue. Do that & even though the file is locked, you can empty the trash without problems.

Bob, I am totally confused by your post. I have a file I have worked on, don't want anymore and I put in the trash. When I go to empty the trash it won't empty because it says its either active or locked. I just go up to the secure empty and it empties the files for me. What legal liability are you talking about? It's not a secure file that I'm deleting, but just a regular file.

R C-R. I do not have time to constantly close out of programs to empty the trash. Especially if I know exactly what I purposely put in the trash. There are times when a file I have closed out of still says it's active even though technically it should not be. So by using the secure empty the file gets tossed and I can continue working. I have yet had any problems doing this, and have not had any problems with the programs used when doing this including the "trash". As to your second point. I have put locked files in the trash with El Capitan for which I do not receive the warning message until I attempt to empty the trash. For which I would do a secure empty and the file is deleted.

I have used Mac's since the conception of the II FX. There have been a lot of changes over the years and it's frustrating to me to have a feature in one system/program that I use a lot (not necessarily this feature) just disappear in the next. Sometimes I think the developers don't ask the users enough questions about their programs before they decide to remove a feature and we find out after the fact whether it's a legal issue or not. It shouldn't be when users revolt that things get changed back in the next version.