Is Apple's clunky screen-splitting really used by 'Mac power users'? I've never seen a single person ever use it, and 'power users' use apps like BetterSnapTool or Magnet to do the job properly.
Not that I'm encouraging the Sherlocking of great apps, but I don't really understand Apple's reluctance to make proper use of ever-increasing screen sizes. I user BetterSnapTool and couldn't really operate without it - with a 27" screen a tool like that is a requirement as far as I'm concerned. Even Windows does this better than Apple, and the new Windows leaks show they've moved this further on, though still not as far as 3rd party apps. I was really hoping a new OS would finally add this kind of essential functionality natively.
I have Magnet and like it, but I'd probably use Apple's solution (I like that you can resize the split easily) if only there was a damn keyboard shortcut for it. The full screen shortcut is occasionally unreliable too.
Yeah, I'm going to need a LOT more information about how this works under the hood before I trust it to really erase my data on a machine with unencrypted, removable storage - which a decent number of Macs still use.
All storage can be encrypted (right-click and encrypt the drive or enable Filevault for a system drive). To securely erase it, it would be encrypted first and then erased normally, that's what the system erase does. For extra peace of mind, the drive can be filled with content after erasing.
It's quicker with new systems because the OS is on a read-only partition and the user data is all on a separate encrypted partition. They just wipe the encryption keys for the data partition without affecting the OS.
I know storage CAN be encrypted. That's how iOS works, obviously, and it would work on a Mac if FileVault is enabled. But if you don't have FileVault enabled, does it securely erase the entire user space? That could take quite some time. Or does Monterey transparently encrypt all internal storage a la iOS, whether FileVault is enabled or not, so that the erase can be securely done merely by deleting the keys? Again, I'd really like more info about how this works at a low level. And also for machines like Mac Pro that might have different types of storage. On SSDs, for example, merely writing zeros across the entire disk/partition will miss the over-provisioned area and also cause unnecessary wear on the drive.
Yeah, I'm going to need a LOT more information about how this works under the hood before I trust it to really erase my data on a machine with unencrypted, removable storage - which a decent number of Macs still use.
All storage can be encrypted (right-click and encrypt the drive or enable Filevault for a system drive). To securely erase it, it would be encrypted first and then erased normally, that's what the system erase does. For extra peace of mind, the drive can be filled with content after erasing.
It's quicker with new systems because the OS is on a read-only partition and the user data is all on a separate encrypted partition. They just wipe the encryption keys for the data partition without affecting the OS.
I know storage CAN be encrypted. That's how iOS works, obviously, and it would work on a Mac if FileVault is enabled. But if you don't have FileVault enabled, does it securely erase the entire user space? That could take quite some time. Or does Monterey transparently encrypt all internal storage a la iOS, whether FileVault is enabled or not, so that the erase can be securely done merely by deleting the keys? Again, I'd really like more info about how this works at a low level. And also for machines like Mac Pro that might have different types of storage. On SSDs, for example, merely writing zeros across the entire disk/partition will miss the over-provisioned area and also cause unnecessary wear on the drive.
You don't understand how SSDs work. They have a table that points to "logical" blocks. The logical blocks are not in the true order of the physical blocks. This is done for wear leveling. You wipe/clear the table, and the drive is almost instantly securely erased.
SATA & NVMe drives have low level "secure erase" commands. These wipe the table that points to blocks. It only takes a few seconds. The drive is left with "random" data spread all across the drive, because 4k chunks (block size) that can hold parts of multiple, different parts, in a random order is meaningless.
And then there are drives that have built-in encryption. Unknown to the OS - the drive has encrypted the data. There are low level commands to tell the drive to "reset" it's encryption key, rendering the data unusable.
Here are the commands I use from a Linux USB stick to securely erase a SATA SSD. Linux also has an equivalent NVMe tool for the same operations.
hdparm --user-master u --security-set-pass xxxxxxxx /dev/sdx
Set a temporary password so secure erase will work properly.
hdparm -I /dev/sdx
Verify password is set by “Security enabled” output.
hdparm --user-master u --security-erase xxxxxxxx /dev/sdx
Start secure erase
hdparm -I /dev/sdx
When the secure erase is finished the security password will automatically be cleared.
This is verified by the “Security not enabled” output.
You don't understand how SSDs work. They have a table that points to "logical" blocks. The logical blocks are not in the true order of the physical blocks. This is done for wear leveling. You wipe/clear the table, and the drive is almost instantly securely erased.
I do know all of that, actually, and no, wiping that table would not erase anything, any more than a quick format of any drive erases data. There are tons of tools on the market to recover data from exactly that event (a quick-format). Destroying pointers to scattered data doesn't mean that data can't be reconstructed. That said, I'm not aware of any method of only doing what you describe anyway, so it's kind of moot.
SATA & NVMe drives have low level "secure erase" commands.
Yes, and that is the proper way to wipe solid-state storage. But does Monterey's command issue a secure erase? If it did, it would also wipe out the recovery partition, but maybe Apple has some proprietary solution to avoid that, but I'm not sure how that would work, say, in a Mac Pro with third-party storage.
These wipe the table that points to blocks. It only takes a few seconds.
Yes, but...
The drive is left with "random" data spread all across the drive,
No it isn't. ATA's Secure Erase (and its NVMe equivalent) wipes that table, but (in any drive I've ever tested it on) also issues an "erase" to every block in the device, including blocks in the over-provisioned area that are normally unreachable via other means. This resets all blocks to an "unwritten" state, ready to receive data. This not only securely wipes the drive, it can also restore like-new performance to drives that had slowed due to being near capacity. When reading these "unwritten" blocks, most drives report all $00 or $FF's.
because 4k chunks (block size) that can hold parts of multiple, different parts, in a random order is meaningless.
I couldn't disagree more. 4K chunks could hold a surprising quantity of data containing SSNs, names, birthdates, etc. in a device used for handling such data. Especially in compressed formats such as XLSX. But again, this is kind of moot, since there is no way to erase the pointer table without also erasing the blocks, unless a drive has just completely failed to properly implement Secure Erase.
And then there are drives that have built-in encryption. Unknown to the OS - the drive has encrypted the data. There are low level commands to tell the drive to "reset" it's encryption key, rendering the data unusable.
Yep, and that is also an acceptable way of securely erasing a device - this is how iOS does it. A decent drive will still issue an "erase" to every block, though, to restore performance. "Secure Erase" on an SSD isn't really just about security, and it doesn't add much time if you're "erasing" the whole device at once. Maybe a minute or so?
But again... none of that tells me how *APPLE* does this in *MONTEREY*. Obviously no one here knows that. Believe me, I'm WELL versed in how data CAN be securely destroyed. My point was simply that I want Apple to go into more detail about how Monterey will handle the task, like they have with the same feature on iOS. They probably will, and they're probably doing it right, but I'd still like to hear the details.
(BTW, you can skip the "--user-master u" parts. That's the default.)
You don't understand how SSDs work. They have a table that points to "logical" blocks. The logical blocks are not in the true order of the physical blocks. This is done for wear leveling. You wipe/clear the table, and the drive is almost instantly securely erased.
I do know all of that, actually, and no, wiping that table would not erase anything, any more than a quick format of any drive erases data. There are tons of tools on the market to recover data from exactly that event (a quick-format). Destroying pointers to scattered data doesn't mean that data can't be reconstructed. That said, I'm not aware of any method of only doing what you describe anyway, so it's kind of moot.
SATA & NVMe drives have low level "secure erase" commands.
Yes, and that is the proper way to wipe solid-state storage. But does Monterey's command issue a secure erase? If it did, it would also wipe out the recovery partition, but maybe Apple has some proprietary solution to avoid that, but I'm not sure how that would work, say, in a Mac Pro with third-party storage.
These wipe the table that points to blocks. It only takes a few seconds.
Yes, but...
The drive is left with "random" data spread all across the drive,
No it isn't. ATA's Secure Erase (and its NVMe equivalent) wipes that table, but (in any drive I've ever tested it on) also issues an "erase" to every block in the device, including blocks in the over-provisioned area that are normally unreachable via other means. This resets all blocks to an "unwritten" state, ready to receive data. This not only securely wipes the drive, it can also restore like-new performance to drives that had slowed due to being near capacity. When reading these "unwritten" blocks, most drives report all $00 or $FF's.
because 4k chunks (block size) that can hold parts of multiple, different parts, in a random order is meaningless.
I couldn't disagree more. 4K chunks could hold a surprising quantity of data containing SSNs, names, birthdates, etc. in a device used for handling such data. Especially in compressed formats such as XLSX. But again, this is kind of moot, since there is no way to erase the pointer table without also erasing the blocks, unless a drive has just completely failed to properly implement Secure Erase.
And then there are drives that have built-in encryption. Unknown to the OS - the drive has encrypted the data. There are low level commands to tell the drive to "reset" it's encryption key, rendering the data unusable.
Yep, and that is also an acceptable way of securely erasing a device - this is how iOS does it. A decent drive will still issue an "erase" to every block, though, to restore performance. "Secure Erase" on an SSD isn't really just about security, and it doesn't add much time if you're "erasing" the whole device at once. Maybe a minute or so?
But again... none of that tells me how *APPLE* does this in *MONTEREY*. Obviously no one here knows that. Believe me, I'm WELL versed in how data CAN be securely destroyed. My point was simply that I want Apple to go into more detail about how Monterey will handle the task, like they have with the same feature on iOS. They probably will, and they're probably doing it right, but I'd still like to hear the details.
(BTW, you can skip the "--user-master u" parts. That's the default.)
A "quick format" is not the same as a "Secure Erase". A quick format only removes the partition table, but logical block order/pointers are still kept. A Secure Erase via SATA/NVMe erases the logical block order/pointers. Any 4k block might contain only bits or bytes of HUNDREDS of files. Without knowing the logical block order or pointers, it is impossible to recover from - the entire drive is "random" (order) data. Maybe I didn't explain "logical table" well enough - it is not the partition/file/folder layout table. It is the SATA/NVMe controller table of logical mapping of blocks to physical 4k chunks of SSD/NVMe storage. When you wipe that logical mapping, it's all suddenly just a random jumble of data.
macOS doesn't care about the recovery partition. If it is not there, then it will boot from the internet. It's highly likely (but not known yet) that a SATA/NVMe secure erase command is exactly what Apple does. Just in the past week, I've booted a 2019 16" MacBook Pro from the recovery partition. Instead of just deleting the OS/Data APFS container, I accidentally wiped the entire drive. The new/clean OS install took a while, because even though I had booted from the recovery partition (which copies it to a RAM disk), wiping it out didn't phase macOS - it just downloaded the OS again, played out the drive & installed.
You are just plain wrong about what a SATA/NVMe Secure Erase command does to a SATA SSD or NVMe drive. The secure erase only takes seconds. It is physically impossible for it to wipe/write to the entire drive, and it does not need to (see above). And if it did (it doesn't), then it would place unnecessary wear on the drive. Note that for spindle SATA drives, it takes a long time, because they can't change the "appearance" of the logical block layout, like they can with SSD/NVMe. SATA spindle drives take forever for a "Secure Erase" command.
With regards to SATA SSDs & NVMe drives, you are not as well versed as you think you are. I'm not sure you understand the "logical mapping" of physical blocks.
It's highly likely (but not known yet) that a SATA/NVMe secure erase command is exactly what Apple does.
I agree, and that is all I was wondering aloud about. lol
As for secure erase, I never said SSDs wipe/write the whole drive, I said they "erase" the whole drive, which is a MUCH faster process. And there are devices that do a cryptographic wipe, as you describe - iOS devices, the old Sandforce-based SSDs, etc. I've no idea how Apple hardwired storage handles a secure erase command; I've never tried it. But for the vast majority of SSDs, they definitely do an "erase" pass of the entire physical NAND.
That said, after googling, I can see where you got the idea that SSD's simply destroy the keys and that's why the erase is so fast. It seems to be a VERY common misconception. And it is plausible, since the Secure Erase is relatively fast compared to overwriting the whole drive, even at SSD speeds (yet not nearly fast enough to just delete a key). Especially since there was at least a handful of drives that did, in fact, operate that way. It isn't typical, though.
The proof is in the write performance restored by doing a Secure Erase. An SSD that has been heavily written to, especially without TRIM and little over-provisioned space, will lose a significant amount of write performance as it runs out of "unwritten" blocks to write to. Remember, an SSD cannot simply overwrite to a block that already has data in it. An SSD has to erase a block before it can write to it. All the blocks on a new SSD are in an erased/unwritten state, so it can skip that step and just write data very quickly. But a nearly full SSD may have to do an "erase" first before it "writes". Even worse, while an SSD may be able to write in 4K blocks, it can only erase in 128K blocks (or some ratio in that ballpark). So to overwrite one 4K block, it has to read 128K, erase 128K, then write 128K back, replacing one of the 4K blocks in that group with the new data. That obviously takes a LOT more time than writing 4K to an area that is already "erased" TRIM and over-provisioning allow most modern SSDs to generally avoid this situation, but if you work at it, you can put a drive in such a state where write performance is severely degraded, and let's say for the sake of this discussion, that's what we've done. Now issue a Secure Erase, and write performance will instantly be restored to like-new. That is pretty definitive that it's doing an "erase" to the entire drive. You can also scan the drive using dd, and you'll see that there is no data (encrypted or otherwise) stored in any blocks. Most drives report "erased" blocks as either containing all zeros or all ones at the bit level. Here is a slightly dated article discussing this. How to restore your SSD to peak performance
Still, with Secure Erase (and the newer Sanitize), you're kind of at the mercy of how the firmware manufacturer implemented it. Drives sold by respectable names in the last 10 years or so generally do a good job, I think, but some older drives didn't, and I've even heard that some early ATA HDD drives ignored it entirely. lol YMMV
It's highly likely (but not known yet) that a SATA/NVMe secure erase command is exactly what Apple does.
I agree, and that is all I was wondering aloud about. lol
As for secure erase, I never said SSDs wipe/write the whole drive, I said they "erase" the whole drive, which is a MUCH faster process. And there are devices that do a cryptographic wipe, as you describe - iOS devices, the old Sandforce-based SSDs, etc. I've no idea how Apple hardwired storage handles a secure erase command; I've never tried it. But for the vast majority of SSDs, they definitely do an "erase" pass of the entire physical NAND.
That said, after googling, I can see where you got the idea that SSD's simply destroy the keys and that's why the erase is so fast. It seems to be a VERY common misconception. And it is plausible, since the Secure Erase is relatively fast compared to overwriting the whole drive, even at SSD speeds (yet not nearly fast enough to just delete a key). Especially since there was at least a handful of drives that did, in fact, operate that way. It isn't typical, though.
The proof is in the write performance restored by doing a Secure Erase. An SSD that has been heavily written to, especially without TRIM and little over-provisioned space, will lose a significant amount of write performance as it runs out of "unwritten" blocks to write to. Remember, an SSD cannot simply overwrite to a block that already has data in it. An SSD has to erase a block before it can write to it. All the blocks on a new SSD are in an erased/unwritten state, so it can skip that step and just write data very quickly. But a nearly full SSD may have to do an "erase" first before it "writes". Even worse, while an SSD may be able to write in 4K blocks, it can only erase in 128K blocks (or some ratio in that ballpark). So to overwrite one 4K block, it has to read 128K, erase 128K, then write 128K back, replacing one of the 4K blocks in that group with the new data. That obviously takes a LOT more time than writing 4K to an area that is already "erased" TRIM and over-provisioning allow most modern SSDs to generally avoid this situation, but if you work at it, you can put a drive in such a state where write performance is severely degraded, and let's say for the sake of this discussion, that's what we've done. Now issue a Secure Erase, and write performance will instantly be restored to like-new. That is pretty definitive that it's doing an "erase" to the entire drive. You can also scan the drive using dd, and you'll see that there is no data (encrypted or otherwise) stored in any blocks. Most drives report "erased" blocks as either containing all zeros or all ones at the bit level. Here is a slightly dated article discussing this. How to restore your SSD to peak performance
Still, with Secure Erase (and the newer Sanitize), you're kind of at the mercy of how the firmware manufacturer implemented it. Drives sold by respectable names in the last 10 years or so generally do a good job, I think, but some older drives didn't, and I've even heard that some early ATA HDD drives ignored it entirely. lol YMMV
You are simply wrong. I've secure erased (SATA SSD & NVMe) many (50+) of at least 6 x manufactures and they are all just a few seconds. I have never seen ANY take longer that 2-5 seconds. Performance increases on all of them after the secure erase, indicating that the SSD block map is cleared/reset.
I know how the SATA/NVMe (SSD) secure erase command works. You simply aren't getting, I'm not explaining it well enough, or you just want to be a "one up" & argue.
I'm not sure you're reading my posts thoroughly, because I specifically addressed why fast secure erase times are not incompatible with a full "erase" of the drive. And the performance increase is actually in support of my argument. lol I also explained that you can see for yourself by using dd and hexdump on a secure-erased drive. I even cited an article describing the process and how it works to restore performance, which is itself a side effect of a full "erase" pass, not of merely resetting a mapping table.
I have done a secure erase on about as many drives as you, on about as many different brands, so our experience levels seem to be about the same. But I've also performed all of the above procedures to confirm my understanding of what was going on at a low level, and that the drive data was, indeed, erased. (Again, NOT overwritten) If you're as intellectually curious, do the benchmarks and the dd - the results are pretty definitive. But I agree, the discussion has probably otherwise run its course.
Comments
SATA & NVMe drives have low level "secure erase" commands. These wipe the table that points to blocks. It only takes a few seconds. The drive is left with "random" data spread all across the drive, because 4k chunks (block size) that can hold parts of multiple, different parts, in a random order is meaningless.
And then there are drives that have built-in encryption. Unknown to the OS - the drive has encrypted the data. There are low level commands to tell the drive to "reset" it's encryption key, rendering the data unusable.
Here are the commands I use from a Linux USB stick to securely erase a SATA SSD. Linux also has an equivalent NVMe tool for the same operations.
hdparm --user-master u --security-set-pass xxxxxxxx /dev/sdx Set a temporary password so secure erase will work properly. hdparm -I /dev/sdx Verify password is set by “Security enabled” output. hdparm --user-master u --security-erase xxxxxxxx /dev/sdx Start secure erase hdparm -I /dev/sdx When the secure erase is finished the security password will automatically be cleared. This is verified by the “Security not enabled” output.How to Securely Erase Your SSD Without Destroying It
macOS doesn't care about the recovery partition. If it is not there, then it will boot from the internet. It's highly likely (but not known yet) that a SATA/NVMe secure erase command is exactly what Apple does. Just in the past week, I've booted a 2019 16" MacBook Pro from the recovery partition. Instead of just deleting the OS/Data APFS container, I accidentally wiped the entire drive. The new/clean OS install took a while, because even though I had booted from the recovery partition (which copies it to a RAM disk), wiping it out didn't phase macOS - it just downloaded the OS again, played out the drive & installed.
You are just plain wrong about what a SATA/NVMe Secure Erase command does to a SATA SSD or NVMe drive. The secure erase only takes seconds. It is physically impossible for it to wipe/write to the entire drive, and it does not need to (see above). And if it did (it doesn't), then it would place unnecessary wear on the drive. Note that for spindle SATA drives, it takes a long time, because they can't change the "appearance" of the logical block layout, like they can with SSD/NVMe. SATA spindle drives take forever for a "Secure Erase" command.
With regards to SATA SSDs & NVMe drives, you are not as well versed as you think you are. I'm not sure you understand the "logical mapping" of physical blocks.
I know how the SATA/NVMe (SSD) secure erase command works. You simply aren't getting, I'm not explaining it well enough, or you just want to be a "one up" & argue.
This is my last reply.