DMs can currently be viewed by admins. This is well known and instance admins are encouraged to mention this in their privacy settings. But for some instances it's better to disable DMs all together cause of some critical privacy situations, like switter.at.
master
(If you're a user, don't worry about this).As a new instance admin, I think there's value in this. I realize the priority is low on this, but if I were to surface this, would there be a merge potential?
Disabling DMs doesn't solve the problem and a nefarious admin would not use the option anyway.
What we would need is some kind of client side OTR since anything server side requires trusting the admin. Which is the issue here. This is why i tell my users to use wire/signal for private messaging. Perhaps a notice when you select a direct toot that its insecure? A simple warning that if you want real privacy to use a third party encrypted system would probably be good enough imho
I agree with @Laurelai and @zcdunn DMs are not really the issue and optionally disabling them would cause a buch of problems.
How do we treat a DM to an instance that has disabled the feature for example ? How could users know when they write the DM that their recipients may not receive it ?
There are similar issues with Private Toots that are exactly like a DM to all your followers.
What I think needs to be done first is to reduce the exposure of the DMs so that only sysadmins can be able to see them. (And it's an easy patch : Aldarone/mastodon@1dce88cbdf2bdc6cc1d159a63a32d4b1f480b4c7)
Then display a blue notice when the privacy is set to private or direct saying something like « Toots are not encrypted and are not securely private. Consider it as having a private conversation in a public place. Use encrypted means of communication if you need real privacy. » (If you don't like the wording it's ok but it should be something clear and not alarming)
With that, there time to think on if and how an encryption system should be integrated.
@Aldarone What you propose is indeed a good thing to do. But I still think that an admin option for disabling DM's would be a good thing in certain situations.
How do we treat a DM to an instance that has disabled the feature for example ? How could users know when they write the DM that their recipients may not receive it ?
There is very simple solution for that, called bounce messages. Like "Your toot could not be delivered, because the recipients Mastodon instance doesn't allow direct messages. Please use another way of communication."
@Laurelai What you propose is also something I support. To have OTR on the client side doesn't affect server performance, one of the main reasons (I think) these messages aren't encrypted.
There is very simple solution for that, called bounce messages. Like "Your toot could not be delivered, because the recipients Mastodon instance doesn't allow direct messages. Please use another way of communication."
Where and when would it be displayed? Message distribution is asynchronous so there is no way of displaying that when the toot is sent. Should it appear in the notification column? Then there is the risk to miss it if you have many notifications.
I still think it's too confusing.
It is just a toot that is send back to the sender and therefore indeed shown in the notifications.
How do we treat a DM to an instance that has disabled the feature for example ? How could users know when they write the DM that their recipients may not receive it ?
DMs already fail silently in a bunch of situations that are not really publicised.
If we're going to have messages telling folks that DMs aren't getting through for this one reason, maybe this could be extended to other reasons too?
Even just a generic "This user won't receive your DM" for situations where they're on an OStatus version of Mastodon or they're on a non-Mastodon instance or their instance doesn't do DMs, etc.
This issue of non private "direct" messages is a dealbreaker for some. As an example I just watched a reasonably influential Australian cartoonist go from ardent new supporter of mastodon to 'this in no way works for me' upon learning of the core complaint of this very issue in the span of 24 hours.
While some appreciate the nuance of "only admins get access in some conditions, and as admins we're too tootin' busy to read your dms" - but this doesn't account for malicious instance actors for not if but when they do come (if they're not already here 👮) or instances get hacked.
I believe the conditions of which admins being able to 'see' them if they really wanted to (they dont) are the admin of the host instance if they and the target instance(s) if I understand correctly? this is between 1 and checks listing 5649 instance admins depending on the number of targeted users.
The "are direct messages really direct with federation" problem is roughly covered in the standard "terms" page - it's long and nuanced in a way that not all will appreciate - disabling DMs is more of a KISS principle approach imo.
But I think what is proposed is not taking it far enough. Why don't we disable "direct messages" by default on all mastodon instances? the admin setting as written by OP makes it a more maternal/paternalistic decision - whereas off by default lets someone understand the risks before turning it on. if we really want to go down the super safe "admin knows best" path you can have a message "enforced disabled by instance rules (link)"
"but how do you propose to deal with failures and settings between users?" I rhetorically hear you ask?
Close to the same way that the birdsite deals with the concept of "open DMs" but we can change the meaning a little. we can just have a simple metadata text on everyones user profile "Open DMs" or "Accept's DMs" if they accept the risk, and "DMs unavailable" if they don't.
What would this functionally do? basically just turn off displaying the DM tab entirely - so it's not really a destructive setting but achieves the same effect and can be easily reversed.
Mastodon is sort of an alternative to twitter but it is not twitter by design and not everyone will get the concept by default, but if we communicate what we are already doing better (which I believe my proposal does) it's more likely to be accepted.
The only annoyance this introduces is app developers changing things to get with the program and a click of 1 or two links for the web clients.
Considering a feature of Mastodon is content warnings, I think a couple of clicks and more choice would be a welcome addition.
thoughts?
the bedrock principle of mastodon's security and privacy is that you trust your admin. If you don't know who your admin is and trust them, then you should migrate to an instance for which that's true.
this affects tons more things then DMs—sure, admins can see your DMs. they can also impersonate you, potentially dox you, throw you off their site for no reason, etc. most people are well-served by their current instance admins. people with 10th-percentile security/privacy needs should make sure to find an admin that they trust with those needs.
This is hard because I've pretty much laid all these concerns out before DMs were first implemented and the community said they want them anyway. However it's not that I did it against my own will, I found their reasons compelling: This situation is no different to PMs on every single forum out there, it's the same for Discord chats and Twitter DMs.
By hiding DMs from admins in the interface (unless the DM is reported) you eliminate 100% of accidental violations of privacy, and limit the potential to only the admins with direct database access and SQL skills to extract them.
Most importantly, DMs are useful regardless of e2ee guarantees. For example, for sharing an e-mail address with someone without exposing it to a lot of people or the internet as a whole. Giving a compliment that doesn't concern other people. Etc.
I think the point is that you are welcome trust your instance admin - it's why I chose gargron's instance myself. But what of every instance that you interact with and send a 'direct' message to? do you audit the instance before interacting? Years and years of the established model of twitter has fostered defacto norm behaviour which on mastodon if you're really concerned about privacy that much it is not well recommended.
the "direct" in direct is not so direct - the term I bet is likely used in a legacy of twitter. On that site "direct" makes sense - because functionally you're going from you > the birdsite > the other person(s).
here it goes you > the instance you're using > your intended recipient(s) and their instances- and that involves a chain of trust.
It's about beginning to use a platform with your eyes wide open from the start and not just blindly copying behaviour from other sites because this kind of looks similar to tweetdeck. :)
In fact I think when it's off by default - the current "direct messages" should change it's text to "where are my direct messages?" 😂
I'm not disputing the usefulness of DMs - I agree they're great and i personally would check the box immediately.
But there are those that are essentially frightened that this doesnt work exactly like twitter.
I work in customer support - I don't share the concerns but I understand them.
It's about being more welcoming for all.
There's a reason they're called "direct" and not "private" -- you are publishing posts on an online platform, i.e. making public and available (even with a limited audience)
Anything that can be reported is inherently not private.
In conclusion,
But there are those that are essentially frightened that this doesn't work exactly like Twitter
It DOES work exactly like Twitter. People have just been desensitized to it in the last decade. Concerns of this nature are disingenuous. You are always trusting two parties: the user and the admin. If you're on the same platform, then there's only one admin. If the user IS the admin, then that's one less person. This isn't new.
I'm not sure if I'm making myself clear here.
Nobody said this was 'new'.
Nothing is 'new' under the sun.
I get that inside the same instance, yes - direct messages DO work "exactly like twitter" in that it stays within the confines of the instance.
But the minute you @ someone in another instance - that trust that the message you're sending now extends to not only to the user you're @ 'ing but also technically any admin of an instance that is possibly either
a) compromised or
b) malicious (noting, the DM'd user on the instance may not be)
the situation is different to all other sites.
All the other sites that you mention have people of various technical knowledge who use them and some have a mental model that's easy to understand - you sign up to the site - you trust that site and its associated admins to keep that direct message or whatever the platform specific name for it "somewhat private".
"Somewhat private" can be "good enough" for a lot of people (hell, it's good enough for me 90% of the time) and they can just get mad at the site if they screw up - depending on how bad it is whether they go back to the site.
This is precisely why I think people were like "don't care, give us DMs" as gargron said (I'd love to read the issue post for DM creation - can't find it on closed issues). that's the deal with centralised sites.
but a an imprecise but illustrative comparison with mastodon would be like Discord users DMing Twitter users, DMing Slack users also... DM'ing the next non-obvious stormfront.net users or other undesirable-but-not-overtly-obvious platform and "every single forum out there". You may not know or trust every single point in the chain.
having DM's "off" by default- essentially hidden but easily configurable to be turned on makes this a choice to engage in "not technically secure, but pretty good enough" messaging.
Adding to this dm choice will facilitate the original request to cater for "the 10th percentile" security/privacy need community (as nightpool says) of instances so they can recommend something else on their rules page.
also:
Concerns of this nature are disingenuous.
I think you're forgetting that people can be very sincere and completely wrong at the same time.
People have just been desensitized to it in the last decade.
Because "all the other sites doing it" and are desensitising people to security/privacy issues doesn't sound like a good argument to me to follow suit.
This is an opportunity to sensitise people again.
In case you haven't guessed - I'm a privacy advocate :).
But yeah, I think I've made myself as clear as I can be.
I'm not the only person who thinks this way.
edit: I'd like to add that yes - I agree and understand that as this is already flagged as a low priority an should be treated as such. I'm still passionate about it - I'm really digging what has been created here. :)
Most helpful comment
I agree with @Laurelai and @zcdunn DMs are not really the issue and optionally disabling them would cause a buch of problems.
How do we treat a DM to an instance that has disabled the feature for example ? How could users know when they write the DM that their recipients may not receive it ?
There are similar issues with Private Toots that are exactly like a DM to all your followers.
What I think needs to be done first is to reduce the exposure of the DMs so that only sysadmins can be able to see them. (And it's an easy patch : Aldarone/mastodon@1dce88cbdf2bdc6cc1d159a63a32d4b1f480b4c7)
Then display a blue notice when the privacy is set to private or direct saying something like « Toots are not encrypted and are not securely private. Consider it as having a private conversation in a public place. Use encrypted means of communication if you need real privacy. » (If you don't like the wording it's ok but it should be something clear and not alarming)
With that, there time to think on if and how an encryption system should be integrated.