✨ Feature Suggestion | Data storage of instant messengers #1134

New Issue

2019-08-11T13:33:13Z

Mikaela commented

2019-08-11 13:33:13 +00:00

(Migrated from github.com)

Description:

From my commentary on The Metadata Trap which @nitrohorse posted on the forum

It’s not enough that these apps encrypt messages. They also need to do better at promptly deleting data that’s no longer needed. End-to-end encryption protects messages as they travel from one phone to another, but each phone still has a copy of the plain text of all these messages, leaving them vulnerable to physical device searches. Disappearing messages features are a great start, but they need to be improved. Users should have the option to automatically have all their chats disappear without having to remember to set disappearing messages each time they start a conversation, and they should be asked if they’d like to enable this when they first set up the app. And when all messages in a conversation disappear, all forensic traces that a conversation with that person happened should disappear too.

I think Keybase may be the best at this. When you are a team admin or in a direct chat with someone, you can set the message expiry time and if you set it to seven days or less, exploding messages are used and they also include forward secrecy. Why I say that Keybase is the best is that the message expiry also applies to older messages and not just the new ones. If you aren't an admin, that is an open issue that I have opened.

https://github.com/keybase/client/issues/18664

Signal while having an option for disappearing messages, doesn't have an option to remove older messages . Wire again does have the option to enforce message expiry time only for groups, with private chats both parties have to enable exploding messages by themselves and there is no message expiry time.

I wonder if there are issues to these clients about this or should I start opening them for others than Keybase too? Should we at PTIO start listing exploding messages and how do they work for apps?

## Description: From [my commentary](https://forum.privacytools.io/t/the-metadata-trap-by-micah-lee/1276/2?u=mikaela) on [The Metadata Trap](https://theintercept.com/2019/08/04/whistleblowers-surveillance-fbi-trump/) which @nitrohorse [posted on the forum](https://forum.privacytools.io/t/the-metadata-trap-by-micah-lee/1276?u=mikaela) >> It’s not enough that these apps encrypt messages. They also need to do better at promptly deleting data that’s no longer needed. End-to-end encryption protects messages as they travel from one phone to another, but each phone still has a copy of the plain text of all these messages, leaving them vulnerable to physical device searches. Disappearing messages features are a great start, but they need to be improved. Users should have the option to automatically have all their chats disappear without having to remember to set disappearing messages each time they start a conversation, and they should be asked if they’d like to enable this when they first set up the app. And when all messages in a conversation disappear, all forensic traces that a conversation with that person happened should disappear too. > > I think **Keybase** may be the best at this. When you are a team admin or in a direct chat with someone, you can set the message expiry time and if you set it to seven days or less, exploding messages are used and they also include forward secrecy. Why I say that **Keybase** is the best is that the message expiry also applies to older messages and not just the new ones. If you aren't an admin, that is an open issue that I have opened. > > https://github.com/keybase/client/issues/18664 > > **Signal** while having an option for disappearing messages, doesn't have an option to remove older messages . **Wire** again does have the option to enforce message expiry time only for groups, with private chats both parties have to enable exploding messages by themselves and there is no message expiry time. > > I wonder if there are issues to these clients about this or should I start opening them for others than Keybase too? Should we at PTIO start listing exploding messages and how do they work for apps?

Mikaela commented

2019-08-11 13:47:57 +00:00

(Migrated from github.com)

On the clients that I didn't name yet and I can comfortably say something about:

I think Prosody (XMPP) server stores history for 6 months by default, but it can be disabled in at least Gajim and Conversations and is probably a feature that all client supporting MAM have (I would need to read the XEP to know for sure, I think). There is no XEP for exploding messages that I know of, but I would need to ask.
Conversations Settings --> Expert settings has Automatic message deletion which I think applies to local messages and is Never by default, but I have set it to 1 week due to storage space concerns. I am not sure if it aplies to media files though.
Gajim doesn't seem to have this feature or I am not finding it within settings nor Advanced Configuration Editor. The option is also missing from Gajim History Logs Manager, I guess exploding messages in general are too new feature while I imagine XMPP has originally competed with IRC where probably all of the clients log by default and log forever.

On the clients that I didn't name yet and I can comfortably say something about: * I think Prosody (XMPP) server stores history for 6 months by default, but it can be disabled in at least Gajim and Conversations and is probably a feature that all client supporting MAM have (I would need to read the XEP to know for sure, I think). There is no XEP for exploding messages that I know of, but I would need to ask. * Conversations *Settings --> Expert* settings has *Automatic message deletion* which I think applies to local messages and is *Never* by default, but I have set it to 1 week due to storage space concerns. I am not sure if it aplies to media files though. * Gajim doesn't seem to have this feature or I am not finding it within settings nor Advanced Configuration Editor. The option is also missing from Gajim History Logs Manager, I guess exploding messages in general are too new feature while I imagine XMPP has originally competed with IRC where probably all of the clients log by default and log forever.

Mikaela commented

2019-08-11 19:57:22 +00:00

(Migrated from github.com)

Wire: it turns out that the message expiry time in private chats doesn't sync across devices and related to this article/issue, I commented on already existing issue: https://github.com/wireapp/wire/issues/282 . I also reported that deleting content causes new-Signal-device style group disappearing until message is read. https://github.com/wireapp/wire/issues/314

I have a few other related issues on my tab pile and I need to read about Signal too.

Wire: it turns out that the message expiry time in private chats doesn't sync across devices and related to this article/issue, I commented on already existing issue: https://github.com/wireapp/wire/issues/282 . I also reported that deleting content causes new-Signal-device style group disappearing until message is read. https://github.com/wireapp/wire/issues/314 I have a few other related issues on my tab pile and I need to read about Signal too.

Mikaela commented

2019-08-11 20:19:16 +00:00

(Migrated from github.com)

On the Signal side the same person has reported similar issue https://github.com/signalapp/Signal-Desktop/issues/2006 and Signal also has an issue where call history doesn't get affected by disappearing messages https://github.com/signalapp/Signal-iOS/issues/3672.

Edit: also Signal forum thread Set disappearing messages by default on all conversations.

On the Signal side the same person has reported similar issue https://github.com/signalapp/Signal-Desktop/issues/2006 and Signal also has an issue where call history doesn't get affected by disappearing messages https://github.com/signalapp/Signal-iOS/issues/3672. Edit: also Signal forum thread [Set disappearing messages by default on all conversations](https://community.signalusers.org/t/set-disappearing-messages-by-default-on-all-new-conversations/5144/7?u=mikaela).

five-c-d commented

2019-08-14 13:44:02 +00:00

(Migrated from github.com)

[signalapp]... call history doesn't get affected by disappearing messages

There is a patch to make the call-logs disappear. https://community.signalusers.org/t/experiment-disappearing-call-logs/8464 I have tried it and it works

Signal... doesn't have an option to remove older messages

This is not 100% correct, there is a message-trimming feature where you can set a maximum size of conversations (e.g. max 500 messages). It applies to media-files and such provided they were not saved outside signalapp's secure perimeter into shared storage. This setting applies in parallel to disappearing messages, and is the usual way to remove "old" messages wholesale, albeit it is count-based rather than timestamp-based.

There is also a delete-option that applies per-conversation, which is useful if you have a short timer like five minutes for disappearing-messages -- in such situations the delete-all-messages option tends to only apply to "old" messages. If you have a long timer set, and a lot of recent messages you don't want to delete, plus some old ones you do, longpress to select and then tap tap tap tap to select all the old ones, is not THAT painful. (I have done it.)

start listing exploding messages and how do they work

Yes, because the details matter. Protonmail has "burn after sending" timers, which means that if you set a short timer and the recipient doesn't immediately read what you sent, they might never see it at all. Signalapp has "burn after reading" timers, which means you avoid THAT problem, but have a different one to replace it: if there is a dormant device (rarely-used laptop with signal4desktop for instance) even a very short timer might not disappear ALL the copies of the message from all devices. Some software offers built in remote-wipe facilities, though this is rare at the app-level (more common at the handset level or as a dedicated app). Some tools have requestEdit and some have requestRemoteDelete -- distinct from requestRemoteWipe because it is per-message rather than per-device.

There is also a philosophical argument about what the purpose of disappearing messages is: software like wickrFreemium has marketing which tries to sell the notion that "the sender is in total control" and copies of messages on remote devices are guaranteed to get magically deleted by their proprietary SecureShredder and ScreenshotNotify voodoo magic. You have to read the fine print buried deep in the helpdocs to learn 'oh btw this is all just best-efforts and we do not really guarantee anything'. Because it is literally impossible for a piece of software to keep a hostile recipient from retaining a copy of something you send them, this kind of marketing engenders a false sense of security.

We don't want people thinking that disappearing messages -- in protonmail, signalapp, wireapp, or any other privacy-tool -- are foolproof ways to talk directly to Eve. They can improve privacy, when Alice and Bob use them properly, and Eve at some later point gets access to a device. But they will never properly protect Alice from Bob, if he decides he wants to keep a copy, it is trivially easy for him to do that.

> [signalapp]... call history doesn't get affected by disappearing messages There is a patch to make the call-logs disappear. https://community.signalusers.org/t/experiment-disappearing-call-logs/8464 I have tried it and it works > Signal... doesn't have an option to remove older messages This is not 100% correct, there is a message-trimming feature where you can set a maximum size of conversations (e.g. max 500 messages). It applies to media-files and such **provided** they were not saved outside signalapp's secure perimeter into shared storage. This setting applies in parallel to disappearing messages, and is the usual way to remove "old" messages wholesale, albeit it is count-based rather than timestamp-based. There is also a delete-option that applies per-conversation, which is useful if you have a short timer like five minutes for disappearing-messages -- in such situations the delete-all-messages option tends to only apply to "old" messages. If you have a long timer set, and a lot of recent messages you don't want to delete, plus some old ones you do, longpress to select and then tap tap tap tap to select all the old ones, is not THAT painful. (I have done it.) > start listing exploding messages and how do they work Yes, because the details matter. Protonmail has "burn after sending" timers, which means that if you set a short timer and the recipient doesn't immediately read what you sent, they might never see it at all. Signalapp has "burn after reading" timers, which means you avoid THAT problem, but have a different one to replace it: if there is a dormant device (rarely-used laptop with signal4desktop for instance) even a very short timer might not disappear ALL the copies of the message from all devices. Some software offers built in remote-wipe facilities, though this is rare at the app-level (more common at the handset level or as a dedicated app). Some tools have requestEdit and some have requestRemoteDelete -- distinct from requestRemoteWipe because it is per-message rather than per-device. There is also a philosophical argument about what the purpose of disappearing messages is: software like wickrFreemium has marketing which tries to sell the notion that "the sender is in total control" and copies of messages on remote devices are **guaranteed** to get magically deleted by their proprietary SecureShredder and ScreenshotNotify voodoo magic. You have to read the fine print buried deep in the helpdocs to learn 'oh btw this is all just best-efforts and we do not really guarantee anything'. Because it is literally impossible for a piece of software to keep a hostile recipient from retaining a copy of something you send them, this kind of marketing engenders a false sense of security. We don't want people thinking that disappearing messages -- in protonmail, signalapp, wireapp, or any other privacy-tool -- are foolproof ways to *talk* directly to *Eve*. They can improve privacy, when Alice and Bob use them properly, and Eve at some **later** point gets access to a device. But they will never properly protect Alice *from Bob*, if he decides he wants to keep a copy, it is trivially easy for him to do that.

This repo is archived. You cannot comment on issues.