#Signalapp doesn't actually delete messages when they're deleted (either manually or by automation).

[hoare_spitall@mastodon.world]

@harrysintonen This is one of the primary reasons I use Threema, despite so many people who claim to know better recommending Signal.

[ajn142@infosec.exchange]

@avuko @harrysintonen this sounds to me like the issue Naomi Wu brought up ages ago about Signal and keyboard leakage, where Signal’s approach may be secure in the vacuum of their intended app behavior, but isn’t in the context of everything going on around the app.

[avuko@infosec.exchange]

@ajn142 @harrysintonen

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.

[david_chisnall@infosec.exchange]

@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.

[groxx@hachyderm.io]

@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

[tychotithonus@infosec.exchange]

@harrysintonen To confirm ... only validated affected setup so far is Signal Desktop on macOS?

[ohmu@social.seattle.wa.us]

@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.

[feld@friedcheese.us]

@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.

[plaka@infosec.exchange]

@feld @harrysintonen The bug with notification db was an Apple problem not Signal

[feld@friedcheese.us]

@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.

[rckenned@hachyderm.io]

@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.