PIG: End-to-end Encryption in ActivityPub

  1. End-to-end Encryption in ActivityPub
  2. Evan Prodromou, Tom Coates
  3. Inviting collaborators, especially those experienced in E2EE in other fields.
  4. Define a protocol for end-to-end encryption of ActivityPub direct messages

What is the existing target protocol you are hoping to improve or enhance? Eg: hand-washing, traffic system, connector standards, carbon trading.

The target protocol is ActivityPub, the federated social networking standards supported by Mastodon, Meta Threads, and dozens of other platforms.

What is the core idea or insight about potential improvement you want to pursue?

ActivityPub is a federated social networking protocol. It lets people on different social networks connect to each other – follow their text and image posts, like and share and comment, and establish social relationships.

ActivityPub packets – activities – are delivered via REST calls over HTTPS, so they are encrypted on the wire. However, as with Internet email, they are typically not encrypted at rest, when stored in a database on either the sending or receiving side. If I don’t know or trust the administrator of my or my correspondent’s server, I might want our private conversations to be encrypted so the admin can’t view them – only my correspondent.

This will be implemented as an extension to ActivityPub. ActivityPub activities are JSON objects with a prescribed vocabulary. This extension will add an additional vocabulary, but try to re-use as much as possible the standard terms.

What is your discovery methodology for investigating the current state of the target protocol? Eg: field observation, expert interviews, historical data analysis, failure event analysis

I am one of the credited authors of ActivityPub. I’ve written a book for O’Reilly Media on the protocol. I have a good idea of how this process can be done in ActivityPub – by using encrypted text media types in the content properties of an ActivityPub object.

What’s more important for me, in this discovery, is finding out more about how other protocols achieve E2EE without overburdening the end user. I’ll need to explore chat, messaging, and other E2EE protocols, and try to identify patterns to apply to ActivityPub. This will require reading documentation, reviewing code, and testing running software.

In what form will you prototype your improvement idea? Eg: Code, reference design implementation, draft proposal shared with experts for feedback, A/B test of ideas with a test audience, prototype hardware, etc.

I will prototype the idea with a messaging-only Web app built on top of the ActivityPub API. This will ignore most social networking interactions, like broadcast messages, and concentrate only on the one-to-one messaging that ActivityPub enables.

I will also document the ActivityPub extension for E2EE as a Report of the W3C’s SocialCG community group.

How will you field-test your improvement idea? Eg: run a restricted pilot at an event, simulation, workshop, etc.

I’ll run a restricted pilot on the Web, to test the interactions.

Who will be able to judge the quality of your output? Ideally name a few suitable judges.

Ideally, people experienced with E2EE will be able to judge the quality of the output – especially identifying theoretical or practical weaknesses in the security of the interactions.

How will you publish and evangelize your improvement idea? Eg: Submit proposal to a standards body, publish open-source code, produce and release a software development kit etc.

I will also document the ActivityPub extension for E2EE as a Report of the W3C’s SocialCG community group. Also, the test code will be Open Source.

What is the success vision for your idea?

The Report is published by the SocialCG. The leading ActivityPub implementers, like Mastodon and Threads, implement the new standard. People on the Fediverse, the network of ActivityPub implementations, can feel safe sharing private information in their direct messages, without worrying about who else can see them.

10 Likes

I sketched out an architecture for this use case on my blog previously:

4 Likes

I very much agree with this idea, I think e2ee is ideal for fedi. Many people who choose to be on fedi are privacy-conscious, and many activists/anticapitalists also need secure communication, and currently mostly use Signal. But a chat feature -and especially a secure chat feature- ideally should be part of a social network. I mean, if I want to chat with someone online, chances are we are close enough that I would like to also follow their social feed. And if I’m following someone on social media, there is a chance I’ll want to chat with them at some point. This has worked great on facebook. Signal seems to understand this and has added Stories, in an attempt to engage users more and become more of a social network than just a chat app. There is also an attempt to build a decentralized social network on the Matrix protocol. And I’m talking about chat because DMs are not always practical enough for this. E2EE DMs would be welcome, but far less useful than a signal/matrix style chat.

Anyway, I was talking about activists because while Signal is great, many people don’t feel great using a centralized, US-based company for this. Most alternatives leave a lot to be desired - for example Matrix sometimes fails to decrypt messages, and reveals more metadata than Signal. But if fedi provided something as private as Signal, then it could be a reason for more people to use it as social media/antireport tool as well. Not to mention that it would be useful for people already on fedi, obviously, but I think it can make it more attractive to more people who aren’t here yet.

Some notes on what would be important IMO:

  1. Group chats. I’ve seen chat apps with e2ee struggle with encrypted group chats. It’s one of the (many) things Signal got right, supporting group chats with up to 1000 members! Having them all on the same server probably helps though, to be fair.
  2. Multi-device support. I use signal from my phone when I’m out, from my desktop when I’m at home. So there needs to be some verification among devices. For example Facebook (which recently added e2ee in Messenger) asks you to set a 6-digit PIN in order to make sure you’re the same person from a different device.
  3. As less metadata available as possible.
  4. I know fedi is built on servers, but P2P might be good to at least consider for something like that. You might want to check out Briar chat, which seems to be doing this the best so far.
  5. This is not directly about E2EE, but if this is designed like a chat in the vein of Matrix, it would be great if there was technically room for public (unencrypted) chatrooms as well. You might think this is out of scope for the #Fediverse but I don’t think that’s true - practically all fedi projects keep public chatrooms on matrix/irc/discord (or self-hosted) for support, dev coordination etc. I only use Matrix to talk with people from fedi. Ideally, we should be able to do it all on fedi.

I’m not a dev so I can’t help more with the technical aspect of things, but I’m very interested in this and I’m more than willing to discuss more about possible design choices on this, or/and for testing. You don’t need to reinvent the wheel here, there are many similar tools already out there and many are open source. I’d recommend checking out Signal and Briar first.

One last thought, ideally there should also be some standard for voice and video calls. Perhaps P2P would be more suitable for something like that (to avoid load on the servers too). Again, this might seem out of scope for some, but it’s an actual communication need, and it’s bound to be implemented by some projects. Having a proposed standard way to do all of this would really help to not (further) fragment fedi.

2 Likes

You don’t need to reinvent the wheel here, there are many similar tools already out there and many are open source. I’d recommend checking out Signal and Briar first.

Cf. also MIMI, aka “signal protocol v2.0” as some person call it, which tries to generalize a superset of Signal that handles better use-cases that Signal (qua product) specifically chose not to support, like cross-device sync and group-chat backhistory for late joiners, etc:
https://datatracker.ietf.org/group/mimi/about/

What’s more important for me, in this discovery, is finding out more about how other protocols achieve E2EE without overburdening the end user. I’ll need to explore chat, messaging, and other E2EE protocols, and try to identify patterns to apply to ActivityPub. This will require reading documentation, reviewing code, and testing running software.

I am forwarding this to a friend who is a UX designer with tons of experience validating user stories and doing targeted user research for FOSS to see if they have recommendations for the “seeking-teammate” tag. I think the timeline and budget would make the most sense if half the budget/one of the two teammates was focused on assessing demand/urgency of various featuresets or targets, and the other (presumably you!) was doing prototyping and tech research on the lift/breakage/pain involved in getting each to prod on a selection of target implementations (say, Masto, Lemmy, Misskey/fish, and Discourse, for example). FEP and validated reqs/user story as primary deliverables, ref impl as stretch goal, maybe?

3 Likes

oh, and in case it doesn’t go without saying, i endorse this app and can vouch for evan’s professionalism and devotion and expertise, to any jurors reading this :sweat_smile:

2 Likes

This is a wonderful proposal. I am a UX designer who is connected to @bumblefudge I have worked with both decentralized protocols that became ActivityPub as well as done extensive UI/UX work on encrypted messaging apps. I have participated in un-conference style events with @evanp over a decade ago and he is wonderful. I would love to to see this proposal accepted and contribute to it.

4 Likes

Is there a second team member for this yet?

1 Like

https://x.com/bravojohnson5/status/1600994439425536000?s=46&t=uxFF0u_0ecJVW04Kh-xZdg

Is this simpatico with your proposal?

Fantastic! Can you reach out to me by email – evan at prodromou dot name – and let’s coordinate?

1 Like

Not yet, still working on it.

2 Likes

There are quite a few interesting directions to go with e2e, one of which is Nomadic Identities

3 Likes

Hey! I’m super excited about this, it is such an interesting challenge. I’ve had a few ideas about the implementation for this project since I read your post on your blog.

If you’re interested I can send you an email. My implementation idea is predicated on GPG keys: the public one associated to the user profile, and the private one periodically loaded into the IndexedDB of the browser.

When the user tries to use the cryptographic messages for ActivityPub he will promoted to 1. (re)generate a keypair and load it/associate it to his account, 2. use his saved backup to reload the private key inside the IndexedDB.

It allows to safely store the key because the IndexedDB can only be queried by JavaScript complying with the origin policy of the browser+it will be encrypted using a password only known to the user using AES.

GPG is a good idea overall because you can encrypt/sign a message for a group of user including the signer (so he can later re-read the message he wrote). The only thing I’ve not covered are images, I have a beginning of concept where you represent the images as Blob and encrypt/decrypt it using GPG, but will this be efficient enough?

In short, see my idea as the ActivityPub instance serving as the host for public GPG keys associated to a user account. The private key is stored on the user’s computer and loaded until he cleans the cache of his browser.

I really think this solution is feasible so let me know if you’re interested! Thanks for reading!

1 Like

Hey Evan!

Super exciting to see one of the co-authors of ActivityPub on here pitching an improvement!

I also pitched a proposal, it’s not about e2ee but it is about how to make sure only people who should access to certain content gets access to it. My specific use case was RSS and adding OAuth endpoints to the RSS feed so that you can unlock exclusive content: [PIG] Enhancing RSS podcast feeds by using OAuth to access exclusive content

Would love to hear your thoughts on it if you get a moment!