Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ Feature Suggestion | Data storage of instant messengers #1134

Open
Mikaela opened this issue Aug 11, 2019 · 4 comments

Comments

@Mikaela
Copy link
Member

commented Aug 11, 2019

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.

keybase/client#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

This comment has been minimized.

Copy link
Member Author

commented Aug 11, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 11, 2019

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: wireapp/wire#282 . I also reported that deleting content causes new-Signal-device style group disappearing until message is read. wireapp/wire#314

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

@Mikaela

This comment has been minimized.

Copy link
Member Author

commented Aug 11, 2019

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

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

@Mikaela Mikaela referenced this issue Aug 11, 2019
1 of 3 tasks complete
@five-c-d

This comment has been minimized.

Copy link

commented Aug 14, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.