-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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 request: Ability to set default message expiry time #2006
Comments
I read The Metadata Trap on the Intercept and started wondering about disappearing messages more. The article makes recommendation:
There is also a problem that currently enabling disappearing messages doesn't seem to affect previous messages and I don't know if a non-technical user would think of that and that they have to long touch all their chats and press the 🗑️ / remove selected button. It also took me some thinking as at first I just used the settings for maximum message retention and set it to 5 to have less messages to remove, but I still had 5 messages in every chat until I thought of the long touch method. In Keybase selecting message expiry also affects existing messages and there is a warning about that before the feature is enabled. Could Signal implement similar behaviour? I do like how Signal's message expiry gets synced to both/all parties without having to do that together. |
The current “disappearing messages” should be enough already. If we were to add a feature such as “Ability to set default message expiry time” users would be less prone to use “disappearing messages”. That would work against the goal. Disappearing messages should be encouraged over message expiration because disappearing messages are deleted from the recipients device as well. Many users would prefer to switch of a global default message expiry setting. The combinations of users turning the expiring off, and less messages being set as disappearing, would work against the goal. Users should set the disappearing message timer on any conversation they think might contain information which could be used against them.
I agree there is a security concern in messages exchanged before the time was set. However, default message expiry is not a good solution to that problem.
What is needed and what is not needed, is for the user himself to determine. A default expiration means that the developer made the decision if he hasn't done so yet. That is not the role of developers, it could cause users to unexpectedly lose messages which were important to them. |
This is a feature that is incredibly important for journalists. As Signal has become more widely used, journalist sources often use Signal as a way to contact reporters securely. But the lack of ability for journalists to set a default expiry time means that there will always be a trace of that first contact on the reporters phone -- even if they set an expiration after the first contact. This "First contact" problem is a well-known journalist risk -- see articles such as this one for background https://freedom.press/training/blog/first-time-they-reach-out-protect-sources-themselves/ -- and is the reason that SecureDrop exists to allow sources to send documents to journalists without leaving a trace. However, SecureDrop not designed to enable communications - which is why it sources often use Signal for first contact. This is why I strongly urge Signal to allow users to set a default expiry time for all of their conversations as a default. There is no downside that I can see to allowing users to set their own default expiration for all conversations. There is no reason that the global expirations need to be turned on by default. But allowing users to do it would be a huge advantage for newsrooms, particularly in an era where the press and their sources are increasingly under attack. |
What if you enabled an option to auto-reject new contacts with disappearing messages not enabled or with an expiration period > t. This functions as a global expiration. The initial message is rejected so no traces on the journalists device. This handles both the sender and the receiver. |
Another idea: What if, whenever a user turns on disappearing messages for a particular conversation, the user is then prompted whether they want to delete all the previous messages in that conversation? Or the slightly more complex prompt of: "Would you like all previous messages in this conversation to disappear after [X amount of time]?" That said, I would use a default/global message expiry time setting if it was an option! |
I'd just like to second Julia's comment. And I would add: This is not only an issue with sources, but also with everyone with whom a journalist might discuss a story, including colleagues at their news outlet, lawyers, etc. Every conversation about the original source/story on Signal becomes an opportunity to fail to properly set disappearing messages, or to have an inbound contact fail to set them, and thus a possible accidental retention of sensitive information. Because Signal is a strong and growing platform (certainly at my publication), used more and more, this becomes a greater concern. (Just to acknowledge a strength - One reason we use Signal so much is that it at least offers this feature when others do not -- and kudos and thanks for that.) |
One thing that journalists definitely do NOT want to do is REJECT incoming requests from sources. The risk is too high that they wouldn't try again and wouldn't know why they were rejected. So I do not think this would work. |
Just to chime in here. I help run training sessions around Signal usage with journalists and others. In the past few years of doing that, very very few, maybe less than 10% of trainees using Signal have ever heard of disappearing messages. It's close to 0% outside the Acela corridor. The lack of awareness about the existence of the feature already means users are not using it. A global default setting for having disappearing messages enabled and set to a given timeframe would be super helpful to, at the very least, introduce the concept to people and give them the option to keep or remove it. Right now the anecdotal observations I have for its usage inform me that it is not being used, and as they say, when you're at the bottom, the only place to go is up. |
I am also a new Signal user, and wish I'd known about disappearing messages, sooner. If there were a global "Disappear" option with a per-conversation option to override that on a per-message basis, I would adore that... but would also comfortably default to all messages expiring after a set time. |
Let's do it a different way lets presume you have the setting set and any message sent from a new peep gets "blah blah has requested to upgrade this conversation to disappearing messages with t expiration. Do you agree?" If both sides agree Signal handles both of initial messages like all other disappearing messages and of course all subsequent messages. If that's not too annoying on the coding side. This does leave you in that half deleted state I think Metriod was trying to avoid. |
@Julia-Angwin said:
From the article Mikaela quoted:
So both devices are a risk. So this is not about "Conversation length limit", but this is about "Disappearing messages". Just wanted to make sure we are all on the same page there. There is a security concern in messages exchanged before the time was set. So what you guys want is to offer the user of the app an option to set a default value for the disappearing message timer on all new conversation.
On installation of the app the default is "off" but the user can change his own default for new conversations, before those conversations even take place. Disappearing messages will still work the same way, both sides of the conversation can change the timer at any time. I propose we continue this feature request in one single place, which covers not only the desktop app but also the Android and iOS apps: |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
[ X] I have searched open and closed issues for duplicates
it would be great to be able to set a default expiring time
so that all new conversations start out with the default expiry time
rather than being default not-expiring.
The text was updated successfully, but these errors were encountered: