#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation).
-
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
@harrysintonen
> This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
> TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
But this is the main selling point of Signal's Perfect Forward Secrecy that everyone says is so important and nobody should use a messenger without it...
PFS isn't really about security in the normal sense, it's about the data transmitted being ephemeral and irrecoverable through cryptographic guarantees. That's why DeltaChat's upcoming implementation will not use the PFS terminology but will be called "reliable deletion".
So now we have another case of Signal's PFS being broken: first through the iOS notification database not being cleared properly, now through MacOS not actually removing the deleted messages from the database.
I think people need to stop trusting Signal's word and start demanding detailed proof that their security promises hold up on every platform. -
@harrysintonen
> This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
> TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
But this is the main selling point of Signal's Perfect Forward Secrecy that everyone says is so important and nobody should use a messenger without it...
PFS isn't really about security in the normal sense, it's about the data transmitted being ephemeral and irrecoverable through cryptographic guarantees. That's why DeltaChat's upcoming implementation will not use the PFS terminology but will be called "reliable deletion".
So now we have another case of Signal's PFS being broken: first through the iOS notification database not being cleared properly, now through MacOS not actually removing the deleted messages from the database.
I think people need to stop trusting Signal's word and start demanding detailed proof that their security promises hold up on every platform.@feld @harrysintonen The bug with notification db was an Apple problem not Signal
-
@feld @harrysintonen The bug with notification db was an Apple problem not Signal
@plaka @harrysintonen no, it's a Signal problem because they exposed the message data to iOS notifications. This is a choice they willingly made and they did not verify how that information was handled.
You can have notifications without exposing this data. That's literally why the workaround was "turn off name and message content in notifications", which should be the only way it works in the first place. -
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
@harrysintonen I’m curious, even when the WAL is synced to the data file (i.e. after restarting the app), is it possible that the deleted row data is still present in the data file as unreclaimed space?
It would be difficult/impossible to reach via SQLite CLI, but the bytes could still be present and available to anyone able to decrypt and read the raw file.
DuckDB on CHECKPOINT will apply the WAL to the data file and delete the WAL (similar to what it sounds like SQLite does on restart). But the newly unused space in the data file isn’t guaranteed to be reclaimed immediately, leaving open the possibility of recovery.
-
R relay@relay.mycrowd.ca shared this topic
-
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
The more I hear about Signal, the worse it gets.
-
Had to look that one up, thanks for the reference.
With notifications and keyboards, one could argue about the span of control (and responsibility). With app native storage, the control and responsibility seems to me to be squarely with Signal in this case.
PS/FS: I haven’t and won’t verify this issue and/or PoC. Those days are long past for me.
@avuko @harrysintonen agreed completely. My point goes more to the Time Machine backup consideration.
-
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
@harrysintonen
Signal team made many choices that are hard to explain convincingly to even apprentice in the secop wizardry.The one that I'd never got answer for (but iirc got a gh ban for buggin on it
is Why Signal Desktop still can not be decoupled from Signal mobile app?.
This restriction [1] apparently is meant to have messages stream from the less reachable desktop machines sent to the low confidence endpoint, i.e. a mobile phone. If enduser tries to "cheat" on whomever demanded this "feature" and keeps their mobile off, desktop endpoint will stop receiving messages until user allows mobile platform to decrypt past messages stream and reauthorize desktop anew.
They are frank abot this I must admit. There is a warning on the desktop urging user to decrypt messages on the mobile or else desktop endpoint will get cut off.
[1] technically it is possible to decouple active client on desktop then remove the mobile OS endpoint. It can be done (for a long time now) but not by an average enduser.
--
@briankrebs (due for boosting),
@signalapp (I'd like to know your current narrative about "why"). -
@harrysintonen
> This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
> TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
But this is the main selling point of Signal's Perfect Forward Secrecy that everyone says is so important and nobody should use a messenger without it...
PFS isn't really about security in the normal sense, it's about the data transmitted being ephemeral and irrecoverable through cryptographic guarantees. That's why DeltaChat's upcoming implementation will not use the PFS terminology but will be called "reliable deletion".
So now we have another case of Signal's PFS being broken: first through the iOS notification database not being cleared properly, now through MacOS not actually removing the deleted messages from the database.
I think people need to stop trusting Signal's word and start demanding detailed proof that their security promises hold up on every platform.@feld @harrysintonen
DeltaChat's decision of renaming PFS to "reliable deletion" was quite dumb, as it led to at least several people I know thinking they are working on message deletion UX/getting rid of bug with messages not deleting visually on recepient's device, as it's unclear from the name that this is a cryptographic feature. -
@feld @harrysintonen
DeltaChat's decision of renaming PFS to "reliable deletion" was quite dumb, as it led to at least several people I know thinking they are working on message deletion UX/getting rid of bug with messages not deleting visually on recepient's device, as it's unclear from the name that this is a cryptographic feature.@tiredbun @harrysintonen it's not worse than the terrible PFS naming convention -
@feld @harrysintonen
DeltaChat's decision of renaming PFS to "reliable deletion" was quite dumb, as it led to at least several people I know thinking they are working on message deletion UX/getting rid of bug with messages not deleting visually on recepient's device, as it's unclear from the name that this is a cryptographic feature.@tiredbun @harrysintonen
> message deletion UX/getting rid of bug with messages not deleting visually on recepient's device
also is this a reported bug? I've never heard of it and never experienced it. Messages always delete successfully when done manually or with the expiration timer set on a chat. -
@tiredbun @harrysintonen it's not worse than the terrible PFS naming convention@feld @harrysintonen PFS at least is recognizable by someone who heard of it, which is why I am critical of changing to another name that still causes confusion but this time to everyone, instead of only people that didn't know what is PFS.
(The bug I only heard in passing by people misunderstanding the announcement, not sure if it's reported) -
@feld @harrysintonen PFS at least is recognizable by someone who heard of it, which is why I am critical of changing to another name that still causes confusion but this time to everyone, instead of only people that didn't know what is PFS.
(The bug I only heard in passing by people misunderstanding the announcement, not sure if it's reported)@tiredbun @harrysintonen but the problem is that nobody actually knows what PFS is except the people who designed it. Everyone uses the terminology wrong. There's so focused on "if someone captures network traffic, they can't decrypt messages with a leaked key" -- but that's only half the story. The entire point is that anything you delete cannot be recovered no matter who captures what. That's why "Reliable Deletion" is a more user-friendly name.
And then there's the problem of sometimes it only being called Forward Secrecy instead of Perfect Forward Secrecy... -
@harrysintonen I'd have a different recommendation for the vendor: Stop trying to pretend disappearing messages are a thing.
Signal has backups. Revocation from old backups is a very hard problem that they don't even try to store.
With the old backup model, each day got a completely new snapshot of all messages and media. If any participant in a chat has backups turned on and doesn't clean out their old backups, disappearing messages are recoverable at an arbitrary point in the future.
The newer backup is similar, each day generates a new snapshot of all messages, it's just that they reference media that are backed up separately.
And that's assuming everyone is using the official client. But any user using a different client may simply choose not to delete them.
I have one chat where I set deleting messages to try to encourage people to write discussions up elsewhere, I wouldn't use it as a security or privacy feature and I think it's quite misleading that Signal pretends that it is either.
@david_chisnall @harrysintonen
Before:
"does it have PFS? I can't trust this software if it doesn't have PFS"
Now:
"well, PFS doesn't actually matter because people can have plaintext backups"
We knew this all along but allowed security thought leaders to gain traction and convince the masses otherwise. It's rather disappointing because this is a pattern of behavior between tech folks and their layman audiences.
We need to find a way to make the rational voices louder -
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
@harrysintonen thanks. thanks especially for making this easy to understand for someone who doesn't program or has studied infosec. this is terrible and i am very disappointed in signal. i may research if a different client like molly is somewhat more trustworthy at this point (even if i'm aware a different client cannot fix server side issues)
-
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
Isn't deleting not truly deleting an unavoidable issue due to stuff like cpu caches?
-
@david_chisnall @harrysintonen while obviously true in the sense of "you cannot control information that leaves your hands", there are other purposes for deleting messages, like "protect myself/others if my hardware is stolen". in that kind of scenario you *do* control the data you care about, and choose the app.
I do wish it was presented differently though. it's practically a fad at this point, with loads of deeply misleading implementations, and misconceptions from one source get carried over to others
@groxx
The other day I sent my sister a view-once picture on Signal and she took a screenshot of it. What's even the point of that feature?
@david_chisnall @harrysintonen -
#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation). The message deletion is written to Write-ahead Log, and the data is only truly deleted once Signal is restarted or threshold of 1000 pages is reached. For macOS Signal application, extra complication arises from the fact that the signal message database can be backed up before the database consolidation occurs. Large amount of the supposedly already deleted messages could be recovered from the device or backups.
This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
Full advisory at: https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt
@harrysintonen interesting. Wondering why @signalapp choose for this approach to delete messages.
Absolutely loved seeing KENSENTME in the explanation. Leasure Suit Larry brought back to live!
-
@harrysintonen
> This concerns use cases where deleting messages actually getting removed in timely manner is of high importance and recovery of the deleted messages could lead to grave consequences.
> TL;DR: If you don't care about deleted messages being actually deleted you don't need to worry.
But this is the main selling point of Signal's Perfect Forward Secrecy that everyone says is so important and nobody should use a messenger without it...
PFS isn't really about security in the normal sense, it's about the data transmitted being ephemeral and irrecoverable through cryptographic guarantees. That's why DeltaChat's upcoming implementation will not use the PFS terminology but will be called "reliable deletion".
So now we have another case of Signal's PFS being broken: first through the iOS notification database not being cleared properly, now through MacOS not actually removing the deleted messages from the database.
I think people need to stop trusting Signal's word and start demanding detailed proof that their security promises hold up on every platform.@feld @harrysintonen Who has been conflating cryptographic guarantees and message deletion?
Genuine question; I haven't been following mass media or social media discourse over secure messengers. Has Signal been saying that their disappearing messages are better than those of other messengers because of how they are encrypted in transit?
-
@feld @harrysintonen Who has been conflating cryptographic guarantees and message deletion?
Genuine question; I haven't been following mass media or social media discourse over secure messengers. Has Signal been saying that their disappearing messages are better than those of other messengers because of how they are encrypted in transit?
@clacke @harrysintonen no, that's just the standard consensus in the security community: PFS is meaningless if you don't also have expiring messages to close the backdoor access to those messages. So it's implied. But nobody wants to look too deeply into how flawed this logic is.
First it was push notifications. "We'll encrypt them so Google/Apple can't see them or hand them to the Feds"
Okay. But what about the other plaintext traces on the device like the iOS notification database because you still opted to display sensitive information outside control of the app anyway? Oops iOS was a leak...
PFS is like protecting a secret you have from spreading. It doesn't work if you involve too many people. Signal's centralization is pretty important for ratcheting to support it in large groups IIRC. But you can't know if someone in the group is breaking the trust through backups or if they're a mole anyway. You have to keep the group as small as possible and it should be people you know and can trust for this to work right. You need careful coordination to manage and guard the secret information properly. This doesn't work for the general public. PFS makes promises it can't deliver if your design allows any leaks. This means:
- no notifications can expose anything about the contents of the messages
- backups should never be allowed
- software needs to do extra work to ensure deletion events are handled carefully and all traces of the original data are scrubbed everywhere
Signal didn't want to do the first two and failed at the third
But security thought leaders have convinced their security-conscious laymen followers that PFS has more importance than those three items, when those are highly likely attack vectors and capture-and-decrypt-later attacks are basically a myth.
If Signal did those three and had no PFS it would be more secure than it is now... -
@groxx
The other day I sent my sister a view-once picture on Signal and she took a screenshot of it. What's even the point of that feature?
@david_chisnall @harrysintonen@nunesgh @groxx @david_chisnall @harrysintonen the argument against screenshot blocking is that it's not hard to overcome and enabling it will create a false sense of security.
most people i know use those pictures as a gentle "this is not for sharing" reminder. for example (real-life one), a friend asking if a new bra looks good on them. it's a matter of trust.
