Conversation

Notices

1. Embed this notice
   Dave ✨ (davidgarywood@social.davidgarywood.com)'s status on Saturday, 07-Jan-2023 00:25:32 JST Dave ✨

   Wondering out loud: given we don’t have E2E encryption with DMs, what are the steps needed to get there?

   Another layer on top of things that uses user identities on instances to connect things up?

   An extension to the ActivityPub protocol itself?

   • Embed this notice
     Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:25:21 JST Evan Prodromou

     in reply to

     @davidgarywood

     The basics are pretty easy. Activity Streams 2.0 supports custom MIME types on content, so using a MIME type like `application/encrypted` (OpenPGP) or `application/pkcs7-mime` (S/MIME) would just pass through the ActivityPub system.

     For users experienced with exchanging keys out of band, this is probably enough to get started.

   • Embed this notice
     Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:30:32 JST Evan Prodromou

     in reply to

     @davidgarywood so, let's talk about the hard parts.

     1. To be E2E, encryption has to be implemented in the client software. That software has to be able to access keys, use them, and keep them safe. This includes Web clients and mobile clients.
     2. To be worth all this trouble, there should really only be one way to do it.
     3. Most people are bad at managing keys. So, key management should be automatic.
     4. Many people use multiple clients, so there must be a way to share keys between them.

   • Embed this notice
     Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:31:40 JST Evan Prodromou

     in reply to

     @davidgarywood I think there's a lot of prior art on these last parts that is both secure and usable. Signal is a good example.

   • Embed this notice
     Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:33:14 JST Evan Prodromou

     in reply to

     @davidgarywood there are some very smart people working on this. I look forward to seeing this develop over time.

   • Embed this notice
     silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:14:27 JST silverwizard

     in reply to

     • Evan Prodromou
     • 64 Islands Airship Cooperative
     @davidgarywood @evan @airshipper Ok, but, out of curiosity, what is stopping your admin from modifying the code to intercept your password?
   • Embed this notice
     64 Islands Airship Cooperative (airshipper@cloudisland.nz)'s status on Saturday, 07-Jan-2023 06:14:29 JST 64 Islands Airship Cooperative

     in reply to

     • Evan Prodromou

     @evan @davidgarywood you could start with a less audacious goal, which would be for all posts to be signed, and dms encrypted, but your home instance is entrusted with an (optionally) password-protected keypair.

     so your local admin might have a shot at brute-forcing your key, but everything else just works.

     actually just having a standard for publishing a public key on your profile for clients to pick up and use for signature verification and encryption could get us pretty far.

   • Embed this notice
     silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:22:12 JST silverwizard

     in reply to

     • silverwizard
     • Evan Prodromou
     • 64 Islands Airship Cooperative
     @davidgarywood @evan @airshipper Which brings us back to the audacious goal
   • Embed this notice
     64 Islands Airship Cooperative (airshipper@cloudisland.nz)'s status on Saturday, 07-Jan-2023 06:22:13 JST 64 Islands Airship Cooperative

     in reply to

     • silverwizard
     • Evan Prodromou

     @silverwizard @davidgarywood @evan nothing, of course. but if it’s done in the client, you can trust your app rather than the admin.

   • Embed this notice
     silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:41:02 JST silverwizard

     in reply to

     • silverwizard
     • Evan Prodromou
     • 64 Islands Airship Cooperative
     @davidgarywood @evan @airshipper Sure, yes, continuous audit of all jS would become necessary - it would be messy and horrible.
     
     This is definitely not an impossible task - just a monumental beyond imagining one.
   • Embed this notice
     64 Islands Airship Cooperative (airshipper@cloudisland.nz)'s status on Saturday, 07-Jan-2023 06:41:04 JST 64 Islands Airship Cooperative

     in reply to

     • silverwizard
     • Evan Prodromou

     @silverwizard @davidgarywood @evan well, you get to decide, right?

     just so we’re clear, i wasn’t suggesting that your private key be protected by your account password, which your admin can easily capture. all signing and decryption should happen in the client, where they could get caught serving patched javascript