4 ms·

Wait, my engineer-sense is tingling. Why are they just deleting the key? If they really couldn't access the Poke after deleting the key, wouldn't they want to s

by sbisker 14y ago

Wait, my engineer-sense is tingling. Why are they just deleting the key? If they really couldn't access the Poke after deleting the key, wouldn't they want to save storage costs by deleting the encrypted message contents too? Unless, of course, the key isn't the only way the message can be decrypted.

CJefferson 14y ago
Making sure no pokes end up getting stored on a backup, or in a cache, or temporary directory, could be tricky. Having to only have one thing, stored specially, to clean out might well be easier to organise in a big already existing framework.
- furyofantares 14y ago
  A backup doesn't make sense without also backing up the key. Caching could make sense without caching the key if the key is way smaller than the data, but why cache something that only needs to be read once?
  - carbocation 14y ago
    I assume they're taking advantage of systems that are already in place, at scale, at Facebook. Then, to ensure that this app has the privacy that people expect from an app of the ephemeral kind, they are baking in additional precautions. In this case, a key that gets destroyed is the precaution. I am not an insider, this is just a guess, etc.
ConstantineXVI 14y ago
If the designer was particularly paranoid, they could be keeping the keys in RAM only (on machines without swap, of course). If the keys never touch disk, easier to purge them and know they're gone.
loxs 14y ago
I think that they have an extremely durable/redundant data store, which is effectively "write-only". You write to some server that replicates its data to other machines, possibly in remote data centres. Read about "eventual consistency" if you are interested. This makes it practically impossible to delete data reliably. You can never be sure whether or not "ghost" copies remain after you delete data. For example on machines that failed and went offline between the write and the delete. You can expect that such machines "eventually" will receive the delete command, but you cannot be sure. Especially as the system is designed to heavily prefer data redundancy. I would guess that encryption itself is a "trick" to avoid having to solve the "deletion problem".
vidarh 14y ago
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.
- sbisker 14y ago
  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.)

by sbisker 14y ago

CJefferson 14y ago

Making sure no pokes end up getting stored on a backup, or in a cache, or temporary directory, could be tricky. Having to only have one thing, stored specially, to clean out might well be easier to organise in a big already existing framework.

furyofantares 14y ago
A backup doesn't make sense without also backing up the key. Caching could make sense without caching the key if the key is way smaller than the data, but why cache something that only needs to be read once?
- carbocation 14y ago
  I assume they're taking advantage of systems that are already in place, at scale, at Facebook. Then, to ensure that this app has the privacy that people expect from an app of the ephemeral kind, they are baking in additional precautions. In this case, a key that gets destroyed is the precaution. I am not an insider, this is just a guess, etc.

ConstantineXVI 14y ago

If the designer was particularly paranoid, they could be keeping the keys in RAM only (on machines without swap, of course). If the keys never touch disk, easier to purge them and know they're gone.

loxs 14y ago

I think that they have an extremely durable/redundant data store, which is effectively "write-only". You write to some server that replicates its data to other machines, possibly in remote data centres. Read about "eventual consistency" if you are interested. This makes it practically impossible to delete data reliably. You can never be sure whether or not "ghost" copies remain after you delete data. For example on machines that failed and went offline between the write and the delete. You can expect that such machines "eventually" will receive the delete command, but you cannot be sure. Especially as the system is designed to heavily prefer data redundancy. I would guess that encryption itself is a "trick" to avoid having to solve the "deletion problem".

vidarh 14y ago

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.

sbisker 14y ago
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.)