Re: End-to-end Encrypted Messaging in ActivityPub

It seems to me that there has been analysis paralysis around this feature and I think we're likely adding complexity where it's not necessary.

The need is clear, and has been explained many times with the use case of DMs. We can keep dismissing this, or we can start working on it (and it seems a few folks have started, giving others fertile ground to build on).

Users not only deserve but expect privacy of direct messages on platforms that offer that functionality, and folks utilize DMs specifically for conversations they would rather not be viewed by a malicious actor or breached and published publicly.

I would expect a detailed rationale to be at the start of a proposal, as the intro before the technical details, not a separate prerequisite.

Cheers,
- Sean



-- 
Sean O'Brien
Fellow, Information Society Project at Yale Law School
Founder, Privacy Lab at Yale ISP, https://privacylab.yale.edu/


On May 20, 2023 6:18:01 PM UTC, Bob Wyman <bob@wyman.us> wrote:
>It is good that Ben reminds us that the problem of e2ee is much more
>difficult than most expect. Trivially, it seems that once you've got a
>key-pair, you can just start encrypting stuff with a few lines of code and
>a good library. The reality is very different and only now appreciated by a
>very small number of people who are deeply steeped in the obscure realms of
>cryptography and security. Even though I've been working, on and off, with
>cryptographic methods since the late 1980's (i.e. over 30 years), I've
>often found protocols or specs that appeared to me to be well thought out,
>only to later discover that someone much more expert than I has dismissed
>the described methods as dangerous, ineffective, or whatever.
>
>Given that this problem is so hard, I'd like to suggest that an effort be
>made not only to define useful, secure methods, but also to ensure that
>there is a good and easily accessible explanation for why the methods were
>chosen over alternatives. In essence, I'm suggesting that effort be put
>into writing what in some OSI Standards efforts we called a standard's
>"rationale." Yes, I do realize that if the issues are debated on mailing
>lists, one can always dig through those lists to elucidate the history
>behind the standard's dictates, however, I think few are likely to do that
>work. It would be better to attempt to maintain a discipline that requires
>that a detailed rationale be provided before any method is incorporated
>into the standard. In essence, one should explain "why" before documenting
>the specifics of "what" or "how."
>
>bob wyman
>
>
>
>On Fri, May 19, 2023 at 11:31 PM Benjamin Goering <ben@bengo.co> wrote:
>
>> soatak also started writing about this 6 months ago, and I thought it was
>> a great contribution. There is also a repo to contribute to:
>>
>> https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/
>> f
>>
>>
>> On May 19, 2023, at 19:21, a <a@trwnh.com> wrote:
>>
>> 
>> > We need simple PGP-style key exchange for DMs
>>
>> we could honestly jump straight to OMEMO-like schemes and have servers
>> generate pre-keys for their actors. i don't think PGP-style is worth going
>> for unless you want to be able to persistently verify authored activities
>> after-the-fact, and don't mind (or perhaps want?) anyone with the key being
>> able to decrypt your messages.
>>
>> aside from that: i'm personally not convinced that we "need" such
>> complexity. maybe it would be "nice to have" a way to do stuff like this
>> over activitypub, but i think before encrypted messaging there needs to be
>> a way to do plaintext messaging. until then, people will continue to go
>> out-of-band to a dedicated messaging app.
>>
>> my current thoughts/notes on "messaging over activitypub" are as follows:
>>
>> - `Create Note` alone can be confused for a "status" or any of the other
>> myriad things a `Note` gets used for. pleroma / litepub at one point in
>> 2019 developed the ChatMessage as a new type and they sent out `Create
>> ChatMessage`; i think this is not exactly the right approach since it makes
>> more sense to have `Message` as an IntransitiveActivity which represents a
>> "message" instead of a "resource". this also eliminates the need for
>> wrapping in a `Create`. such `Message` activities could be transient if
>> desired, or they could be persistent if given an `id`. (alternatively, if
>> `context` was understood, you could have an explicit "messaging context"
>> representing the room or conversation.)
>>
>> - the other thing we'd want to heavily look into and think about is
>> metadata encryption. if we just encrypt, sign, attest, verify, etc. the
>> content, then that's surely simpler, but it is also surely far less useful
>> in many cases. otherwise, we could have had `content_sig` or something
>> similar years ago to cryptographically work with the `content` and no other
>> properties. i am reminded somewhat of diaspora*'s approach to this, which
>> was to have a "magic envelope"
>> https://diaspora.github.io/diaspora_federation/federation/magicsig.html
>> that would encode the entirety of the "message" and then sign that encoded
>> string. we could do something similar by having some dedicated Envelope
>> activity type serve as this "envelope" which might contain `summary` and
>> `content` as proposed above by Evan's blog post. i haven't fully considered
>> the exact details, but i think at minimum you would have to leak the
>> `actor` if nothing else. (this is because of the requirement to use
>> activities to avoid the wrap-in-Create behavior. addressing could be hidden
>> by use of bto/bcc instead of to/cc.)
>>
>>