Skip to content
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

Open
evanp opened this issue May 29, 2024 · 3 comments
Open

Abusive clients #21

evanp opened this issue May 29, 2024 · 3 comments
Labels
user story For user stories

Comments

@evanp
Copy link
Collaborator

evanp commented May 29, 2024

"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)

@evanp evanp added the user story For user stories label May 29, 2024
@Openmedianetwork
Copy link

As you say, this is likely impossible. So we move responsibility from the instance to the app and phone operating syteam?

@nightpool
Copy link

nightpool commented Jun 3, 2024

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:

  • They are cosigned and distributed by a third party, like Google or Apple, who users judge as unlikely to cooperate in coordinated targeted spearphishing campaigns against individual users. That is, users can trust that they are getting the exact same client code / binary as everybody else in the world, which is impossible in a web-based deployment.
  • They are audited by security professionals, who are both paid for their services and gain reputation and fame through their public disclosure of security vulnerabilities. This relies on external security professionals having the client code available to decompile, which is reinforced by the previous bullet.
  • They are widely used by others who have serious security concerns, and have done their own research and perhaps paid for their own audits of the codebase. They're promulgated by high-reputation organizations that are easy for users to trust (ones with a strong ideological bent and no significant government affiliations, like the Tor Project or the Signal Foundations, or large multinational corporations with a significant amount of reputation on the line that users judge would be compromised if the corporations provided access to third parties or weakened their implementation, like Whatsapp's or Apple's e2ee deployments).

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.

@evanp
Copy link
Collaborator Author

evanp commented Jun 15, 2024

In existing, trusted e2ee deployments, clients are verified through several defense in depth mechanisms, many of which are non-technical.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
user story For user stories
Projects
None yet
Development

No branches or pull requests

3 participants