Email or username:

Password:

Forgot your password?
Top-level
Neil Brown

That said, I have changed my view on whether fedi software should implement #e2ee for DMs.

Originally, I thought “yes”.

Now, I’m less sure. Doing e2ee well is hard, and is perhaps best left to the myriad existing alternatives, rather than being Yet Another Thing for overworked fedi developers to get right, particularly given the consequences for getting it wrong.

22 comments
nadja

@neil I would personally have loved a fediverse in which *everything* is e2e encrypted.
Alas, cryptography isn't easy, and it is scary enough to programmers that it would have seriously impacted adoption and development of new fedi-related software.

Maybe the next generation of federated protocol will work that way ^^

Neil Brown

@dequbed

> I would personally have loved a fediverse in which *everything* is e2e encrypted.

I am interested in how you’d see that working:

- I presume it would mean eliminating “open follow” accounts (like mine), and requiring people to approve follow requests, as otherwise any adversary could follow and obtain access to (future) posts. But…

- if A posts something and B boosts it, C, who follows B but not A, could see it? Does e2ee add anything?

nadja

@neil I don't think open follow accounts like your have the threat model of trying to prevent randos from seeing your posts. To you it would mostly add enforced encryption at rest.

For public/unlisted it would mostly add enforced encryption at rest, but follower-only posts can't be boosted. And it protects those against bad actor servers that e.g. index or publicize them.

Neil Brown

@dequbed

I can see how it would work in the context of follower-only posts from restricted follow accounts. Absolutely.

And, just in case, I didn’t mean to be dismissive of those who choose or need to engage in that way - not at all.

In other, more public, contexts, I am less sure it would work at all!

nadja

@neil oh no worries, I didn't read you as dismissive. Just as honestly curious about a topic that's outside of your domain of expertise, and I can apprechiate that :blobcatcomfy:

Neil Brown

@dequbed Thank you! I love how I can engage with actual experts on so many things :)

Dragon

@neil @dequbed I can’t see how it would work for public posts.

Or why you’d even need to encrypt those as given they’re meant to be public.

Joël de Bruijn
@neil @dequbed
Just an adjacent thought:
With CryptPad I see the irony of being e2ee without identification/authentication users.
Super encrypted meanwhile anyone with a link can collaborate.
Lien Rag

@dequbed

I believe that's exactly what Spritely/Goblin is trying to do with Ocaps (but I'm just lurking at their work, I don't really understand it).

@neil

nadja

@lienrag @neil AIUI Spritely is more about establishing a capability-based platform/network than building an e2ee social network. Caps are not necessarily cryptography-based and skimming spritely.institute/static/pape don't seem to be in this case either. Spritely appears to be more about classical network security.

But my experience with capabilities is at this point good many years old back with E and experiments in Erlang. Maybe @cwebber wants to chime in, she obviously knows this problem domain ^^

@lienrag @neil AIUI Spritely is more about establishing a capability-based platform/network than building an e2ee social network. Caps are not necessarily cryptography-based and skimming spritely.institute/static/pape don't seem to be in this case either. Spritely appears to be more about classical network security.

EdenDestroyer (He/Him)

@dequbed @neil there was one matrix project in work that did this. i dont remember the name sadly. i suppose it could be found on the matrix.org page

Sören

@dequbed @neil

> in which *everything* is e2e encrypted.

You would have to exchange keys between every combination of author/reader, and probably per-device or even per-app. The computational impact and restrictions (no guests, for example) would trump the benefits. And at that scale, can you really trust everyone in the first place?

E2EE makes sense for private conversations and small group chats.

Kelly & Roger :18_plus:

@neil there is something to say about staying out of that game. Not having an expectation that DMs are private is a form of protection for those organising things to not get exposed. Adding the tech adds the expectation and as you say, getting it wrong could be catastrophic.

Talya (she/her) 🏳️‍⚧️

@neil honestly, Fedi isn't built for E2EE and that's fine. "do one thing and do it well" has some truth, and here it is very true.
Fedi DMs are for subtle nudges, for things that may be unlisted posts but you don't want to spam people, stuff like that. if you don't want people to read your messages, move to an actual messaging service.

Nanode

@neil@mastodon.neilzone.co.uk @Yuvalne@433.world

"do one thing and do it well"

Yep, 100% agree with both of you on this.

Adjacent related but I'm slowly ditching my phone and moving back to a dedicated music player, camera and using bank cards again.

(The only thing holding me back 100% are car parking apps, so, maybe I should get the bus more.)

fruitbat

@neil yeah honestly agree
i think clients that label private posts with only one person tagged as dms should tell you that it's not the most secure method

it always seemed like a weird choice to me to display them as dms tho, cuz thats not at all what they actually are

maswan

@neil
My argument for e2ee of fedi DMs implementation has been to bundle an xmpp server to do all the heavy lifting, and only worry about the presentation layer.
@liw

rigrig

@neil It's also much easier to explain: "Nothing is encrypted: never post anything sensitive on here".

Tokyo Outsider (337ppm)

@neil If limited to "recipient+sender" messages only it would be more straightforward, wouldn't it? Wonder if it's worth someone writing something that adds it only for those. 🤔

(Using some kind of external, proven library, I mean, to minimise the burden on fedi devs to start from scratch and get it right)

Neil Brown

@tokyo_0 I think I'm still erring on the side of "leave that too a security-focussed messaging system", rather than creating another one here.

Tokyo Outsider (337ppm)

@neil That's fair enough. It probably would be more dangerous to give people a false sense of security.

Go Up