Month: October 2022

tevruden:

toskarin:

toskarin:

every time tumblr or twitter is shit, recommendations for mastodon instances start going around. my criticism of mastodon hasn’t changed for years now, and it’s a variation on “imagine if tumblr drama could result in a website being deleted and your worst ex getting access to every dm you’ve ever sent”

did you know that mastodon admins can read your dms as long as either you or the recepient are on an instance they host, because they’re not encrypted

proponents argue it’s not a problem when it’s actually extremely a problem considering that mastodon (by design) encourages small friend groups to run instances together and have personal relationships with admins

like it’s just not fit for purpose

This isn’t an issue that is specific to mastodon, your email provider can do this as well, along with Facebook Messenger by default, along with anything using SMS and everything using RCS that doesn’t support google’s extensions for encryption. Only telegrams’ secret chats are only visible to the end recipients.

ANYTHING that doesn’t support end to end encryption means that the administrator can read your direct message. And this can mean one of SEVERAL administrators:

1) The person who runs the server application.
2) The person who administers the virtual server, if applicable.  (If its run in a VPS or in the cloud)
3) The person who runs the PHYSICAL server.  (encryption of the virtual disk does not help you here because as the server is running it needs the the ability to decrypt it and that key usually sits unencrypted in memory)

Now  I’m not saying this isn’t a problem, it very much is, but styling this as a specific mastodon problem as opposed to overall issue with messaging systems seems wrong to me.

So yes, you have to trust your admin doesn’t read your DMs, but also for anything that supports end to end encrypted messaging, you’re going to have to trust that the person running the messaging application isn’t shipping your private key back to their infrastructure and the using it for later decryption.

This all falls back figuring out what threat model you want to protect against and what level of trust you’re willing to have.

I feel like also I need to mention: Yes there’s the tradeoff between  “disinterested administrators from a corporation that has policies against this” verses “some guy who knows of you and likes to keep receipts”

BUT I feel like there’s a counter tradeoff of “knowing exactly who’s to blame in a breach” versus “corporations are built to diffuse liability and end up also diffusing responsibility and the very ability to effect change in the face of an incident.”

If Brian, my friend who is running mastodon/phpbb/matrix/etc starts reading my DMs, I can call him up and ask “Hey what the actual fuck my dude?”  I know who did this, and I’ve got social and (worst case) legal options for recourse.

When Twitter employees are using their privileged access to access private info to spy for the Saudi Arabian government (Or any other government, this is just an example we know happened.) What recourse does a single person have? Sue Twitter, a company worth 44 billion USD?

(I realize that the nation state example is WAY more involved then my friend being shitty, but it’s there as a very visible example that this thing does happen.  There’s other data breaches like being able to associate twitter usernames with phone numbers, etc. My point stands.)

I know this basically goes back around to my first point about trust and threat models, but I think there’s a third thing that needs to be introduced: Perfect is the enemy of good. All of these things are bad in their own way, yes but if we hold on to them as they are because we’re dismissing alternatives because  anything else doesn’t solve every problem forever, we’re not going to be able to fix anything.