GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Dave ✨ (davidgarywood@social.davidgarywood.com)'s status on Saturday, 07-Jan-2023 00:25:32 JST Dave ✨ 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?

    In conversation Saturday, 07-Jan-2023 00:25:32 JST from social.davidgarywood.com permalink
    • Embed this notice
      Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:25:21 JST Evan Prodromou 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.

      In conversation Saturday, 07-Jan-2023 00:25:21 JST permalink
    • Embed this notice
      Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:30:32 JST Evan Prodromou 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.

      In conversation Saturday, 07-Jan-2023 00:30:32 JST permalink
    • Embed this notice
      Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:31:40 JST Evan Prodromou 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.

      In conversation Saturday, 07-Jan-2023 00:31:40 JST permalink
    • Embed this notice
      Evan Prodromou (evan@prodromou.pub)'s status on Saturday, 07-Jan-2023 00:33:14 JST Evan Prodromou Evan Prodromou
      in reply to

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

      In conversation Saturday, 07-Jan-2023 00:33:14 JST permalink
    • Embed this notice
      silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:14:27 JST silverwizard 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?
      In conversation Saturday, 07-Jan-2023 06:14:27 JST permalink
    • 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 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.

      In conversation Saturday, 07-Jan-2023 06:14:29 JST permalink
    • Embed this notice
      silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:22:12 JST silverwizard silverwizard
      in reply to
      • silverwizard
      • Evan Prodromou
      • 64 Islands Airship Cooperative
      @davidgarywood @evan @airshipper Which brings us back to the audacious goal
      In conversation Saturday, 07-Jan-2023 06:22:12 JST permalink
    • 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 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.

      In conversation Saturday, 07-Jan-2023 06:22:13 JST permalink
    • Embed this notice
      silverwizard (silverwizard@convenient.email)'s status on Saturday, 07-Jan-2023 06:41:02 JST silverwizard 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.
      In conversation Saturday, 07-Jan-2023 06:41:02 JST permalink
    • 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 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

      In conversation Saturday, 07-Jan-2023 06:41:04 JST permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.