#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 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. -
@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 to be fair, if you read what Signal writes about disappearing messages, they're presented as a cleanup tool, and deliberately not as a security tool.
https://support.signal.org/hc/en-us/articles/360007320771-Set-and-manage-disappearing-messages -
@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.@nunesgh @groxx @david_chisnall @harrysintonen to be clear, if there were a good way to do screenshot blocking i'd be in favour of such a feature. i'm just not convinced that such a way exists.
-
@nunesgh @groxx @david_chisnall @harrysintonen to be clear, if there were a good way to do screenshot blocking i'd be in favour of such a feature. i'm just not convinced that such a way exists.
@Yuvalne @nunesgh @groxx @david_chisnall @harrysintonen Yeah, Signal's screenshot-blocking has always struck me as dangerous. If I only used it on desktop on Windows (where it does block screenshots), I'd assume everyone else was blocked from screenshotting lik eme. Yet on my Android phone or on the Linux VM on my Chromebook, I can screenshot things just fine. It's also just inconsistent UX, for no clear reason, given that at least on Android you *can* block screenshots.
-
@Yuvalne @nunesgh @groxx @david_chisnall @harrysintonen Yeah, Signal's screenshot-blocking has always struck me as dangerous. If I only used it on desktop on Windows (where it does block screenshots), I'd assume everyone else was blocked from screenshotting lik eme. Yet on my Android phone or on the Linux VM on my Chromebook, I can screenshot things just fine. It's also just inconsistent UX, for no clear reason, given that at least on Android you *can* block screenshots.
@tamzin @nunesgh @groxx @david_chisnall @harrysintonen Signal offers screenshot blocking *on your device*, the same way it offers incognito keyboard mode on your device. the assumption for those two is that you aren't trying to overcome privacy measures put there by yourself, not that you can force them on anyone else.
-
@tamzin @nunesgh @groxx @david_chisnall @harrysintonen Signal offers screenshot blocking *on your device*, the same way it offers incognito keyboard mode on your device. the assumption for those two is that you aren't trying to overcome privacy measures put there by yourself, not that you can force them on anyone else.
@tamzin @nunesgh @groxx @david_chisnall @harrysintonen and the reason it blocks screenshot on Windows by default is that's the only way to guarantee Recall is also blocked. Windows is the only platform where screenshot blocking on your own end is enabled by default.
-
@tychotithonus @harrysintonen
Seconded. This sort of thing is not surprising to me given Apple's and MS's design philosophy. Is this also the case on Android and Linux?And it occurs to me a feature I wish Signal already had was something reporting whether the other person I am corresponding with is using actual Signal and whether they are backing up messages.
It's been hard to miss that many prosecutions mention Signal messages recovered from the other end of the person's conversations.
@ohmu @tychotithonus @harrysintonen
> is this also the case on Android and Linux?i suspect it's a desktop thing in general, and that Android by doing a lot more committing should be safer on that front, but i'm not an expert on the matter so i may be wrong. desktop in general is more open than the mobile apps, like the time it was discovered possible to locally change attachments on the desktop app if, well, you have full local over said desktop... (was solved since btw)
-
@ohmu @tychotithonus @harrysintonen
> is this also the case on Android and Linux?i suspect it's a desktop thing in general, and that Android by doing a lot more committing should be safer on that front, but i'm not an expert on the matter so i may be wrong. desktop in general is more open than the mobile apps, like the time it was discovered possible to locally change attachments on the desktop app if, well, you have full local over said desktop... (was solved since btw)
@ohmu @tychotithonus @harrysintonen
also desktop does have better encryption at rest nowadays so it's not like every process on your device can read deleted messages.
https://community.signalusers.org/t/signal-stores-encryption-key-in-plain-text-on-desktop-client-s/61675/53
Android doesn't have encryption at rest and relies on the containerisation Android naturally does (if you also want encryption at rest you should use Molly) but as mentioned should not have this deletion issue.
i'm even less familiar with iOS but it should be similar to Android i think. -
@david_chisnall @harrysintonen to be fair, if you read what Signal writes about disappearing messages, they're presented as a cleanup tool, and deliberately not as a security tool.
https://support.signal.org/hc/en-us/articles/360007320771-Set-and-manage-disappearing-messages@Yuvalne @david_chisnall @harrysintonen I actually feel like disappearing messages *do* make sense to describe as a security tool, but just not for the part of the threat model that most people are thinking of. They do not make you meaningfully more secure from your conversational partner showing your messages to others. They *do* make you significantly more secure from bad actors being able to read your past messages if your or your conversational partner's device is compromised or seized.
-
@ohmu @tychotithonus @harrysintonen
also desktop does have better encryption at rest nowadays so it's not like every process on your device can read deleted messages.
https://community.signalusers.org/t/signal-stores-encryption-key-in-plain-text-on-desktop-client-s/61675/53
Android doesn't have encryption at rest and relies on the containerisation Android naturally does (if you also want encryption at rest you should use Molly) but as mentioned should not have this deletion issue.
i'm even less familiar with iOS but it should be similar to Android i think.@ohmu @tychotithonus @harrysintonen
> I wish Signal already had was something reporting whether the other person I am corresponding with is using actual Signal and whether they are backing up messages.the real question is how would you do that. do you broadcast with every single message your client details, OS version and backup status, similar to phone number when sharing is turned on? and what do you do about any fork that spoofs that "for privacy reasons"? it's self defeating.
-
@Yuvalne @david_chisnall @harrysintonen I actually feel like disappearing messages *do* make sense to describe as a security tool, but just not for the part of the threat model that most people are thinking of. They do not make you meaningfully more secure from your conversational partner showing your messages to others. They *do* make you significantly more secure from bad actors being able to read your past messages if your or your conversational partner's device is compromised or seized.
@tamzin @david_chisnall @harrysintonen maybe. certainly many people use it that way, but i'll be honest, if a conversation partner's device gets captured in AFU or otherwise unlocked, there's many ways to compromise me that don't involve past messages. i'd put a lot more stake in whether the phone was in BFU/AFU when it was grabbed.
-
@nunesgh @groxx @david_chisnall @harrysintonen to be clear, if there were a good way to do screenshot blocking i'd be in favour of such a feature. i'm just not convinced that such a way exists.
@Yuvalne
I agree with you, and I think the naming is also misleading. It should be something like "open-once" instead of "view-once".
@groxx @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 I think the use case has to be considered where your device may be seized in a hostile political environment where your password can be compelled either legally or potentially through torture. And you have to worry about deletion not only on your own device but on the device of any recipients. This seems almost as bad of an issue as the recent Revelation that notification contents get backed up by Apple, and thus reveal a significant amount of information about Signal messages.
-
@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!
I am guessing they chose SQLite for storage simply because they found it easy to use and offered the functionality they needed. The Signal developers may never have investigated the inner workings of SQLite.
-
#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
@signalapp avoided implementing disappearing messages, as it provides a false sense of security that can easily worked around by a client. They specifically didn't announce this feature as a security feature, but as a space saving feature. While I agree that deletion should mean deletion and not "delete at some point probably", this feature was provided due to customer demand, but no secure way exists to actually enforce it. -
@ohmu @tychotithonus @harrysintonen
> I wish Signal already had was something reporting whether the other person I am corresponding with is using actual Signal and whether they are backing up messages.the real question is how would you do that. do you broadcast with every single message your client details, OS version and backup status, similar to phone number when sharing is turned on? and what do you do about any fork that spoofs that "for privacy reasons"? it's self defeating.
@Yuvalne @tychotithonus @harrysintonen
That makes sense.
I guess it's back to be careful what you say and who you say it to. -
@nunesgh @groxx @david_chisnall @harrysintonen to be clear, if there were a good way to do screenshot blocking i'd be in favour of such a feature. i'm just not convinced that such a way exists.
@Yuvalne @nunesgh @groxx @david_chisnall @harrysintonen screenshot-blocking not only offers a false sense of security (since you don't know whether your correspondent has a way to work around it), but it is user-hostile, because how *dare* a program tell me what I can and can't do with data on my device.
