If FileVault is able to complete its encryption of the drive, then the original plaintext versions of the files should not be available using the normal disk-block-access APIs. If Apple didn’t erase/overwrite those blocks, it would be a pretty lousy security protocol since any app could simply read through the device’s unallocated blocks to get the content.
But that only covers what you can access with software. A data recovery service that removes the flash chips or uses alternate firmware in the SSD controller might be able to access the “garbage” blocks of flash storage and these might contain data. This is the problem the MacObserver article is trying to solve.
As you may be aware, when you overwrite a logical block on an SSD, it doesn’t overwrite the corresponding physical block (the way it does on a hard drive). Instead, the physical block is marked as garbage and a new block is allocated for the new data.
At some unspecified point in the future (the specifics will depend on how the SSD controller firmware is implemented), the garbage will be “collected”. Without going into too much detail, the flash chips in SSDs erase data at a larger granularity than they can write data. So you might be able to write to individual 512-byte blocks (or maybe small collections of them), but you may only be able to erase large groups of physically-contiguous blocks (maybe several MB). During the garbage collection process, valid data is moved in order to create large blocks of contiguous storage that can be erased (either free or garbage blocks).
Garbage collection can be time consuming and it uses a lot of processor power in the SSD’s controller, so it is generally only done during idle periods or when required to complete requests (which usually kills performance). Which means that you have no way of knowing when the garbage blocks will actually get erased.
Furthermore, when you delete a file, its blocks may not get marked as garbage until they are overwritten (e.g. by a new file that is assigned the same logical blocks). If your SSD is using TRIM then this won’t be a problem - TRIM allows your system software to pro-actively tell the SSD controller that a deleted file’s blocks are garbage. This will make the data inaccessible to software, but the physical blocks won’t get erased until garbage collection can process them.
in other words, how much security do you require? If you only want to make the data inaccessible to software, then the encrypt-erase method will be more than sufficient. You could also just have software write zeros to every logical block, which will mark everything as garbage (and collect much of it).
If you need to protect against someone using data recovery forensics to bypass the SSD controller to read the garbage blocks, then there’s no way to be certain. If this matters to you, then you shouldn’t be giving away that SSD. If you can’t remove it from the Mac, then you may be out of luck.
Regarding the cryptographic erase mechanism, I question whether it is actually better than classical secure-erase mechanisms (writing random data followed by zeros to all blocks). I don’t think either mechanism is guaranteed to make data stored in garbage blocks inaccessible to someone directly accessing the flash chips.
The encryption process is going to overwrite every logical block, and if the drive is full of data, most of those blocks will be garbage collected. But the same thing will happen if you just write random data to the device two or three times. The result will probably be good enough, but you have no way to be 100% certain.
The only way to completely protect against direct access to the flash chips is to encrypt with FileVault from day-one, before you put your data on the SSD. Then you can be certain that your data never existed in plaintext on the device in any block. Discarding the key at that point will ensure it’s all inaccessible. But encrypting a drive full of data immediately prior to losing they key just seems to me like a computationally expensive version of writing random data to the device.