@mray But now you know why I'm asking. There is lots of energy around encryption but it's a very tricky thing to be done right. My point was simply that we start with some simple UX improvements and not wait for the encryption (given we already have private messages)
Post
@scottjenson I would rather prefer to have a separate messaging app where user’s identity is a public key. Same way as in blockchain space. A great example for it is Session messenger. But, I would like to have an option to create as many public keys as I want so I could share different keys in different platforms or communities. That will help me to manage the messaging traffic and protect my identity from spam. Same way email aliases work (I use them heavily).
@scottjenson when it comes to encryption the first question that arises - who stores the encryption keys. It makes zero sense if the platform does it (same way like Telegram does) because a third party can read messages. End-to-end encryption requires storing the keys on the client that has to be open source. Otherwise there is always a trust factor, which again doesn’t make any sense for a privacy first communication. Mixing two words breaks the mental model and creates confusion.
@scottjenson
> How critical is it that these message are encrypted?
If you're going to do DMs at all, it ought to be in the roadmap from day one. A SocialCG taskforce is actively working on E2EE DMs for ActivityPub, using MLS (cc @evan), so you don't need to do it alone.
> If we were to make some UX changes as a first pass WITHOUT encryption
There's never a bad time to improve UX. Making it harder to confuse public and nonpublic posts, for reading and especially for sending, would be great.
@scottjenson@social.coop Private mentions aren't really private if they're not end-to-end encrypted. On a federated platform, you put a lot of trust on the servers, and it's not just the one you're on but also the one receiving the messages. What if I want to message a friend on Threads for instance? I don't know about you, but I don't trust Meta to just deliver the messages without using them to build a profile on me or improve their AI models, which are things I can't really opt out of since it's not my platform. The only way to avoid these things (to some extent) is to make it impossible for them to read my messages.
The good thing is you don't have to reinvent the wheel here, there are already a few attempts at standardizing encryted messages for ActivityPub: Evan put together the MLS over AP, Hollos also did something similar. Make sure to talk to them so we don't end up with yet another standard.
@Varpie I did just check out Hollo (Hollos?) and it appears to be a server for just 1 account so it's not clear HOW it's handling this. (I'm not going to install it for just kicking the tires)
For me, the biggest issue is setting up/managing the keys. I'm hoping to find any implementation that shows how to do this?
It's not enough to show a technology demo, we have to have something mere mortals can turn on without a multiple step configuration process.
@scottjenson@social.coop True, handling the messages in a standardized way is one thing, but managing keys across multiple clients is the hard part here. The way I see it, there are 2 options:
- each client creates its own key, encrypted messages now need to be encrypted with multiple keys and the new clients don't have chat history (this could be mitigated by having existing clients with the decrypted messages send them to the server with the new key)
- there is some sort of handshake when registering a new client, that passes the private key from a registered client to the new one
The first option allows to handle each client separately, so we don't need the other device to be available and if we want to stop using a specific app, we can deregister it, but it requires senders to encrypt their messages n times, and as mentioned it makes it difficult to handle chat history.
The second option makes chat history trivial, but it puts a lot of trust on new clients, if we want to stop using it the rotation of keys is more complex. Also, each client needs to be able to handle the same type of keys, which isn't a given when using different apps.
I think for user experience, having each client generate its own key and asking older clients to re-encrypt messages with the new key can be better: there is no requirement to have the other clients active at the same time, but we can have the same handshake that would be required for passing PKs, to recover chat history. It also allows to give more granular control over which clients are active, kind of like seeing the active sessions for an account and being able to log off on other devices.
@Varpie I just found https://holos.social/e2ee which explains how keys are generated per message and using the actor in activit Pub allows the sender to know if the recipient is capable of receiving an encrypted message. It seems pretty slick and looks like it's almost ux-free with a few unanswered questions.
imo social media and social networking are different things. mastodon is the former and doesn't need privacy. it's public and about going viral. encryption is needed for the latter. direct messaging and groups. #ActivityPub vs #matrix.
I use Mastodon DMs.
I want encryption, but there is something higher priority for me —
Being able to see ALL the DMs for a single user (that I have talked to) in a single place. Rather than having them scattered all over the place.
I get that these scattered DMs are the result of separate conversational threads, but — I would still like to see them all (from a single user) in one place.
I'm probably just one more vote on a "me too" pile, but it's not critical to me that social timeline 1:1 messaging be *encrypted*. It's important that I (the generic user) *understand* whether it is or isn't and behave accordingly.
If you have to pick a focus, I do strongly prefer that 1:1 or 1:few comms have a distinct workflow apart from regular/public timeline appearances, though. It makes mishaps less likely, like forgetting or mis-clicking "private" in that dropdown.
@scottjenson count me in "use secure messengers for private communication". I know people will keep trying to use social media for it no matter what, but in my mind it's a misuse, and shouldn't be a priority for fixing. (I didn't do any research, just speaking from vibes!)
@scottjenson
Signal is my go-to when I feel there's a need for #Encryption. If it was available in Mastodon for private messages, I'd probably use it.
I don't think the Fediverse is on the radar of the current administration here in the US yet, but they might be someday. What happens when law enforcement types show up at a Masto admin's doorstep? Do they give up all the data willingly? Even without a subpoena or judge's order?
@scottjenson Encription should be an option, not a must.
Not everything should be hidden, and by reducing the cpu time you'll reduce the carbon footprint, too.
(I'm talking about end-to-end encryption here, not about user's AAA or inter-server comms).
Personally, I hate this modern trend of hosting public blogs via HTTPS. Not everything should be encrypted!
@scottjenson I'm not against interface improvements, or even doing that first, but I'm all in on encryption.
Mastodon is all about privacy and putting users first. When I DM someone the whole point is that the message is only for them. I prefer that administrators not be able to see.
@scottjenson Hi Scott, I believe the option is complex, honestly.
Encryption is tricky but I also think it provides layers on top of the communication that might make it feel larger than a quick "dm"? I can't speak to others obviously but Mastodon should consider what solutions you are providing and if they make sense for the platform.
Encryption is useful, but does it make sense for Mastodon? Is that the direction the social media tool is moving? Encryption-focused 1:1 communication?
@jackryder all fair questions! All I can say is that there are many within the community that are quite adamant that DMs must be encrypted. The most common reason is that they don't want admins to spy on their posts.
My concern is just that setting up E2EE is rarely a simple process. I expect it to be a ux challenge to make it easy.
@scottjenson I appreciate the response and transparency.
I believe I understand the fear for concern and secrecy. I don't believe there will be a simple & straight forward solution. As you said, "just setting up..." is often a lot trickier than we anticipate.
I'm not familiar enough with the stack to know what would need to change. I imagine there are quite a few underlying systems that would need at least partial rework and that alone would cause for a trickle down effect on literally everything. Ouch. I wouldn't envy sitting in on those prioritization calls.
Personally, though I don't mean to sound diminishing to the population I would do exactly what it looks like you guys are doing. Checking the temperature and prioritizing the needs. Kind of glad to see people actually asking.
@scottjenson For it's the expectation of privacy for private messages that makes encryption a requirement, not an option. Depending on the jurisdiction of the instance, authorities might be trivially able to get all content, including private messages. Also, instance admins might snoop around for whatever reason they think is valid. Encryption by default is the only way to guarantee privacy expectations. 1/2
@scottjenson I think that every message not meant as a public broadcast should be end-to-end encrypted, regardless of the app or service that people use to send it. People shouldn’t have to worry if the information they’re exchanging is private and secure or not. It should be table-stakes these days, just like HTTPS is for websites. When you create a website, you don’t ask yourself if it’s sensitive enough to need it, it’s just common practice to generate an HTTPS certificate for everything.
@scottjenson I believe that as long as we are transparent about encryption status, it's not a problem.
