My engineer-sense says that every item of data written is at risk of being copied into places you wouldn't think to delete them from.
Note that they are not saying they are not deleting the encrypted message contents too. What they are saying simply indicates that what they promise is that they delete the keys.
There are practical reasons to do it this way: You only need to ensure that you delete one key per user (you keep a "current" key, that is anything up to two days old, and a previous key that you delete once it reaches two days), vs. deleting a possibly much larger amount of data entries that might also be more likely to be cached all over the place.
If I were to design a system like that, I'd try to delete the contents, but assume that I'd miss something, and aim to delete the keys too. I'd probably also make at least portion of the key depend on a site-specific set of secret rolling over with time that it should be policy not to log etc. to make it even less likely that the full key would survive longer than it should.
Agreed that that's a good reason not to promise to delete the data. However, they don't even say they'll try to delete it, do they?
Of course, "trying" is legally just a terrible way to not promise and still get sued. I get why their lawyers would want them not even mention the data itself.
Still...Facebook is not exactly trusted when it comes to the privacy of just about anything. They're trying to operate a service in the grey area between what they want to do and reality, and doing so depends heavily on people's trust in their intentions. You can guess how much I trust Facebook to keep my data private right now (if not from my timeline, then from the government, etc.)
Note that they are not saying they are not deleting the encrypted message contents too. What they are saying simply indicates that what they promise is that they delete the keys.
There are practical reasons to do it this way: You only need to ensure that you delete one key per user (you keep a "current" key, that is anything up to two days old, and a previous key that you delete once it reaches two days), vs. deleting a possibly much larger amount of data entries that might also be more likely to be cached all over the place.
If I were to design a system like that, I'd try to delete the contents, but assume that I'd miss something, and aim to delete the keys too. I'd probably also make at least portion of the key depend on a site-specific set of secret rolling over with time that it should be policy not to log etc. to make it even less likely that the full key would survive longer than it should.