#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation).
-
@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.
-
@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.
@dirtside @Yuvalne @nunesgh @david_chisnall @harrysintonen yea, the fact I can't force it to allow screenshots bothers me a lot. I don't mind it as a "you should think twice before bypassing this" soft block, but hard blocks you can still bypass with a second phone are sheer user-hostility.
-
@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.first through the iOS notification database not being cleared properly,
That was an IOS bug and affected every application.
-
first through the iOS notification database not being cleared properly,
That was an IOS bug and affected every application.
@voxel @harrysintonen every application isnt promising to protect your communications from attackers. Signal does promote itself as the best and still willingly hands your message data to another application on your phone it has no control over, can't audit, can't delete/retract.
This is not a requirement for applications to work. Every Signal notification message could just be "New Message" and expose nothing, but they don't want to do this. -
@mathew @harrysintonen sure, though that’s much harder to take advantage of than regions of a live file that you can just grab, decrypt, and read via something like hexdump. Those are going to appear in backups, too.
-
R relay@relay.infosec.exchange shared this topic
