I don’t think the “right to be forgotten” works with immutable logging? It seems like the workaround of mapping usernames to a random number and not including that mapping in the transparency log would break the security, because it allows usernames to be changed arbitrarily without logging it.
Maybe someone who knows the GDPR better could say whether there are exceptions for essential services. When looking up a public key by username, securing that mapping by username is clearly essential. Without it, you don’t have a secure service.
It would be like setting up certificate transparency without logging domain names - no point.
The idea is that you can send a message to a complete stranger. How do you know you didn’t send it to the wrong stranger? Suppose the user doing the lookup (by username) gets the wrong public key and sends a message to the wrong person? That’s a man-in-the-middle attack. Redirecting someone’s messages to someone else is pretty bad.
People mostly don’t use real names on Mastodon, so essentially, you are your username. Impersonating a username is like impersonating a domain name for a website.
I'm probably missing some context - I don't really grasp the problem being solved or why it's related to the fediverse. Would an accurate summary be "how to make activitypub based systems end to end encrypted (by default?)" or more along the lines of "verified" identity like keybase?
This is a directory of public keys, which every secure messaging app including Keybase must also have, but federated rather than centralized. That's a necessity for e2ee and it's very cool to implement it as an append-only version of the pub-sub messaging the fediverse already has.
It has nothing to do with the identity verification a la Keybase, unfortunately, as that would be a really good and useful feature for the fediverse, but I think it would be a lot harder to do.
Sending an encrypted message to someone is a problem solved for decades: get their public key, encrypt your message, send it.
The real problem with encrypted communications is: how do you properly distribute public keys, make sure they receive it, they receive the right one, etc ?
- giving them by hand, directly or through web of trust, doesn't scale
- trusting a server involves... trusting it, which you might not be able to do for many reasons
- use the first one you receive from your recipient (TOFU) kinda works, but it's not really enough
The beginning of a solution here is general transparency for everyone: everyone sends their public key to everyone, everyone records everything, and so if someone else changes my key without my consent I can tell everyone "SOMETHING IS WRONG, THIS IS NOT ME". For scalability, of course, keys aren't sent to everyone. The nice thing with this is that by design you don't need to trust anyone, you just have to watch everything by yourself.
Keybase still needs to trust all third-party services, although it's assuming that each one isn't super reliable and the real trust comes from multiple independent third-parties. It's slightly in the middle, with the advantage of reusing existing stuff, but the inconvenient of making said existing stuff more important
What's the relationship with the fediverse ? None, really; the concept is generic for any kind of communication, but ActivityPub is slowly becoming a protocol for generic communication anyway so might as well do it for AP.
> Truthfully, I had been hoping to piggyback off one of those upcoming projects (which is focused more on public key discovery for SAML- and OAuth-like protocols) to build the Federated PKI piece for E2EE for the Fediverse.
It's not public yet. The person I was collaborating with has had a rough year (including some medical stuff) and can't give me an ETA on when they'll finish their part.
Readit News
It would be like setting up certificate transparency without logging domain names - no point.
What am I missing.
People mostly don’t use real names on Mastodon, so essentially, you are your username. Impersonating a username is like impersonating a domain name for a website.
It has nothing to do with the identity verification a la Keybase, unfortunately, as that would be a really good and useful feature for the fediverse, but I think it would be a lot harder to do.
The real problem with encrypted communications is: how do you properly distribute public keys, make sure they receive it, they receive the right one, etc ?
- giving them by hand, directly or through web of trust, doesn't scale
- trusting a server involves... trusting it, which you might not be able to do for many reasons
- use the first one you receive from your recipient (TOFU) kinda works, but it's not really enough
The beginning of a solution here is general transparency for everyone: everyone sends their public key to everyone, everyone records everything, and so if someone else changes my key without my consent I can tell everyone "SOMETHING IS WRONG, THIS IS NOT ME". For scalability, of course, keys aren't sent to everyone. The nice thing with this is that by design you don't need to trust anyone, you just have to watch everything by yourself.
Keybase still needs to trust all third-party services, although it's assuming that each one isn't super reliable and the real trust comes from multiple independent third-parties. It's slightly in the middle, with the advantage of reusing existing stuff, but the inconvenient of making said existing stuff more important
What's the relationship with the fediverse ? None, really; the concept is generic for any kind of communication, but ActivityPub is slowly becoming a protocol for generic communication anyway so might as well do it for AP.
What project/spec is this?