-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abusive clients #21
Comments
As you say, this is likely impossible. So we move responsibility from the instance to the app and phone operating syteam? |
In existing, trusted e2ee deployments, clients are verified through several defense in depth mechanisms, many of which are non-technical. We should make sure to understand the constraints and limits of those deployments when designing recommendations for e2ee ActivityPub, since they'll affect the space of possible user stories. Current e2ee security clients gain trust through several different mechanisms:
Overall, this means that the baseline for creating a strong, trustable e2ee clients is much, much higher than many organizations in the fediverse today are able to surmount. So we will have to think carefully about what sorts of expectations we'll have for our reference implementations and how we'll find implementors willing to meet those goals. |
I think we can include non-normative language about choosing client apps, and give a non-exhaustive list of the ways client apps can be treacherous. |
"As an ActivityPub user, I want to be confident that the client I’m using is not simply recording the plaintext of my DMs and pushing them online or leaking them in some way, so I can feel safe."
(this may be impossible and we may just have to assume that people choose good, trustworthy clients - this would be a strong area for an SDK to be developed that people can mostly drop into their apps)
The text was updated successfully, but these errors were encountered: