I had the same question, so I checked the paper that is referenced in the article (it's at Reliably Erasing Data from Flash-Based Solid State Drives).
It turns out that the concerns are not at the physical level; it's not the old problem of stray magnetic signatures that might be reconstructed. Instead, the problem lies in the fact that when you tell the SSD to write at a given block, and then later, you tell it to overwrite the same block, it doesn't actually do that. The logical block address mappings on an SSD are more sophisticated than most traditional hard disks.
The explanation in the paper is quite lucid:
SSDs use flash memory to store data. Flash memory is divided into pages and blocks. Program operations apply to pages and can only change 1s to 0s. Erase operations apply to blocks and set all the bits in a block to 1. As a result, in-place update is not possible. There are typically 64-256 pages in a block (see Table 5).
A flash translation layer (FTL) [15] manages the mapping between logical block addresses (LBAs) that are visible via the ATA or SCSI interface and physical pages of flash memory. Because of the mismatch in granularity between erase operations and program operations in flash, in-place update of the sector at an LBA is not possible.
Instead, to modify a sector, the FTL will write the new contents for the sector to another location and update the map so that the new data appears at the target LBA. As a result, the old version of the data remains in digital form in the flash memory. We refer to these “left over” data as digital remnants.
The researchers did show that the built-in "Secure Erase" feature on some SSDs did correctly erase the entire drive; however, it was not present or failed on 8 of the 12 drives tested. Overwriting actually did work pretty well in many cases according to the paper, but it wasn't perfect.
There are also limitations to the numbers of times that a given cell of flash memory can be written to before the cell will no longer accept the write; something on the order of 10,000 times (give or take). To make up for this limitation, SSDs contain a great deal of “extra” storage. Memory controllers onboard the SSD monitor where data is written and parcel out writes to all the cells to prevent prematurely exhausting cells that might otherwise be subject to a large number of rewrites.
The result is that within the SSD structure a logical file’s contents will be slowly shifted from one group of cells to other cells as changes are made to the file; but content in the old cells is simply left behind, to avoid “wasting” anther write to the cell.
This write limitation is one reason one does not want to run defrag utilities on SSDs as they more rapidly exhaust the number of available write operations; and defragging a device with no moving parts is of little value in improving file read rates.
Sorry. IF it had said erasing FILES, I would have gotten it. That sector translation is used for wear leveling. But it said erasing the DRIVE. That means you overwrite free space or the entire drive, sector by sector, in a way that allocates every sector to a dummy file as it goes. That way you have ultimately cleared every sector regardless of translation.
Also obviously, you can’t erase the drive at the sector level alone without allocation to a file system because the translation by sectors will hopscotch around at the physical level. That does rule out some disk clearing utilities.
“Secure” deletion of individual files is obviously pointless on an SSD and has been pointed out in the literature already. But if you properly clear the drive (magnetic or SSD) with a utility like WinHex (which does build files of “junk” data as it goes), they have no secret way to snoop and you’re good.
I know drives and encryption. I think they were deliberately ambiguous for the sensation. OTOH, this post is useful information. (I have no connection with WinHex other than reporting a few bugs over the years.)