Hacker News new | ask | show | jobs
by icelancer 1315 days ago
Normal users do not understand what federation is, much less how messages are stored.
1 comments

This has nothing to do with federation. It's just a fact of life on any hosted internet service.
Chances of a centralized Twitter stealing your sensitive information is quite a bit lower than N number of federated Mastodon instances run by any number and types of actors.
Not if end-to-end encryption is available.
If you don't own the key exchange (and you don't, even on the services most people consider secure), you're still, on some level or another, just relying on trust that this is the case.

At any rate, mastodon is a web app, not an IM client. No one who's ever raised this has even begun to explain how you could work e2e into something like it. Certainly no other microblogging platform has e2e anything, because that's not actually a thing that makes sense.

> because that's not actually a thing that makes sense.

No for micro-blogging, but Mastodon supports direct messaging, and if you support direct messaging, you should support end-to-end.

> If you don't own the key exchange ...

Sure, but I trust https://letsencrypt.org/ more than I trust some random running a server.

> No for micro-blogging, but Mastodon supports direct messaging, and if you support direct messaging, you should support end-to-end.

No other microblogging service with DM support has e2e anything. Because they're websites. To have meaningful e2e you need to have key exchange and device keys, and if you have a website you can look at your DMs on then the website has to have a key. If the website has a key the owner of the website can look at your DMs. This is just fundamental to hosted web services, and it's why if you use icloud messaging with imessage you're no longer guaranteed e2e, and why signal just doesn't even have a website for you to use.

> Sure, but I trust https://letsencrypt.org/ more than I trust some random running a server.

LE has nothing to do with this? The key exchange I'm talking about is the end keys. User keys. LE doesn't provide those. For e2e IM systems a server has to manage user/device:key mappings, and are a central point of trust. They can potentially inject a "listening key" into your recipient list without you knowing and tap you or even impersonate you (but only in a forward way).

E2E is not a panacea, but it's also largely irrelevant to websites.

That's wrong. A "website" can do e2ee. You just need to do the encryption/decryption on the client side. Protonmail does that, Mega, etc.
> LE has nothing to do with this?

You probably want a CA signing the public keys that you store on the site.

> They can potentially inject a "listening key"

You mean a MITM attack? Isn't that the reason for certificate authorities?

The foundations for E2EE were merged into Mastodon, there's a merged pull request for it elsewhere in this thread.
Go look at that PR and read the details and ask yourself who you have to trust with a list of device keys you're encrypting your dm for.

You might be surprised to discover that you're still trusting an instance admin.

It does improve some things, potentially, in terms of intermediaries being able to read things, but there are a lot of things that are still reliant on trusting your admin, or are outright unclear how they'll work in practice.

That said, I take back that "no one has begun to explain..." - they've begun. But so far they've kinda just thrown some well established protocols at it but not done much to explain how it really helps the "trust your admin" problem.