As far as I can see the disappearing messages feature is ‘burn on read’, the time start to count after reading the message as it does on Signal. I’m not sure this is the best approach, especially for high-risk users.
A group of activists being in risk will shorten the disappearing messages time, but a seized device or any device off / not checked will compromise the group by storing messages in the server. If the user is forced to open the device, the messages will be downloaded and sensible info could be revealed despite the burn on read feature.
If I had to choose between burn on read and expiring disappearing messages, I would choose expire (the type the time starts to count at sending). If forced to reveal the password no message would be retrieved after the expiring time. Expiring messages with the current delete old messages Delta feature would be much safer, IMHO. Even better with a temporal, burner account.
Wickr me, for example, with both burn on read and expiring features has a much better approach on the issue than signal. Not to say the info revealed by signal would be linked to phone numbers, which are like ID cards in many countries.
1 Like
Disappearing messages are designed for day-to-day use, to keep the history short so you don’t store months of message history on a device by the time it is lost or stolen. We have considered both options when designing the feature. Wickr me users told me expiration timer is hardly usable because people miss messages, so they use burn-on-read. Disappearing messages is a feature for low-risk users, it should not degrade user experience for the sake of security, because otherwise less users will enable it and eventually more messages are lost/leaked/stolen.
For high-risk situations symmetric timer synchronized across all members makes less sense, because other members of a group may be in a safer place. High-risk users don’t want to force all their contacts to delete messages: they just want to delete all messages from their device. For this usecase there are two asymmetric options to delete old messages (from the server and from the device). Currently they use timestamp (time of message reception) instead of sent_timestamp to determine if the message is old. Maybe it makes sense to switch these options to use the sender timestamp, so old messages are not downloaded and are deleted from the server immediately when the device goes online?
2 Likes
Delta options to delete old messages are great but they apply to all existing groups and 1:1 conversations. I don’t think any activist would want all groups behaving the same way because the nature of those groups is very different. From political theory to groups managing social networks, long term actions, groups working the next week protests, one day missions. Every group has different needs and the risks associated if messages leaked / phones sized are very different too. Of course this could be mitigated by creating different user identities.
You may also have that chat or where more sensible items are discussed so the risk is higher. Main concern should be the safety of the whole group when things go wrong. A system able to leave no trace of what has been said in that group would be helpful. Otherwise you let the responsibility to each group member with their different skills and dedications which likely will lead to mistakes. If your phone is sized is good to know there will be no trace of what has been said in an hour because of the expiring messages. With burn-on-read the phone sizers will have an hour to copy everything if they get to open the device, which is a much worse scenario.
In my humble opinion low-risk users would use the expire feature anyway. Only they will set considerable longer expiring times. High-risk ones will set shorter times and miss an occasional message or two, which is nothing when your life or freedom are at stake.
As I said above, maybe the best option with burn-on-read and the two asymmetric options to delete old messages will be creating a second identity with its own set of rules to use in high risk groups and missions. Apologies for my rant.
1 Like
Never mind, everyone has a story to tell. “The Right Honourable gentleman must be heard, and he will be heard!” (John Bercow, former Speaker of the British House of Commons) 
1 Like
Of course this could be mitigated by creating different user identities.
As I said above, maybe the best option with burn-on-read and the two asymmetric options to delete old messages will be creating a second identity with its own set of rules to use in high risk groups and missions.
That is how it is expected to be used. For high-risk usage a separate “burner account” should be created, which is disposed after use: Security goals of Delta Chat - #2 by hpk
If regular account is used, there are other unexpected problems like backups, forward secrecy etc.
Maybe it makes sense to:
- Suggest enabling automatic deletion of old messages for burner accounts when they are created.
- Changing the timestamp used to determine if the message is old to sender timestamp.
2 Likes