Deniable messages by default

[ag-eitilt]

"I want to be confident that anything I send to someone can't be used against me if their server is hacked."

(This user story is most relevant to #13 and #27, where the user wants something they wrote previously to now be gone, but it applies across the board since even a simple DM has the assumption they're talking to that person, rather than to any third parties who may gain access to the database.)

In practice it's effectively impossible to enforce any assumptions about the remote server at the protocol level. Anyone can implement ActivityPub, anyone will be able to implement something that looks like AP E2EE, including promising to anything connecting to it that it deleted something/does honour disappearing messages, and then just not actually delete what it receives (whether maliciously/deliberately[^1] or accidentally). A shared protocol like this is based on needing to trust the other side has implemented it correctly, and where for most of ActivityPub a failure to correctly implement something just means that the remote won't receive/display a message correctly or some other fail-safe error, a failure to make messages disappear is inherently fail-risky.

I think the best thing we can do is assume that messages aren't removed on the remote, try to avoid presenting them to users as if they invariably will, set things up so that good-citizen software will remove them, and locally ensure that any remote copies left are as deniable as possible. That places this in inherent conflict with #23, unless #23 is restricted to only apply in the instant of receiving something, so that any data at rest is spoofable (the user knows that everything received was created by whoever it's attributed to, since they know they didn't write it themself, but any third parties can't be sure which of the two it was).

Stepping out of the theoretical realm and into practical implementation, with the caveat that I'm definitely not a security expert, I feel like the best way to do this would be something along the lines of a "show your privates"/OTR (§Revealing MAC keys) publishing of the signing key for a message. That doesn't really work for the fediverse as a whole (something sent publicly can be assumed to be valid because so many remotes accepted it) but if E2EE operates on a more intimate level of one-on-one/small-group DMs then it's more viable. Potentially, after a disappearing message timed out and after deletion in general, the local server deletes the local copy and sends the remote(s) a Delete activity (which has the benefit of backwards compatibility for things that don't know about disappearing messages) which contains the key which originally signed the message as a payload? Maybe the local server should also publish the signing key on its end as well, though unless the same key is used for multiple messages with multiple people that risks proving that they had some connection with the remote even if it doesn't prove the exact contents of any message.

[^1]: I'll be honest, one of the projects I have in the planning stages is a datahoarding tool which would be able to plug into AP so users are able to collect images, informational/helpful posts, things that jog their imagination, etc.; disappearing messages (and even Delete activities) are in conflict with its mandate. The best I've been able to work out is a policy of storing that content in a way where it's indistinguishable from something that the local user is just pretending the remote sent out, or a note they jotted down themself.

[mallory]

Deniability is a property of the cryptographic authentication-- it ensures that anyone able to decrypt a record of the transcript, including message recipients, cannot cryptographically prove to others that a particular participant of a communication authored a specific message. As demonstrated by widely implemented protocols, this optional property must exist in conjunction with the necessary property of authentication, i.e. participants in a communication must be assured that they are communicating with the intended parties but this assurance cannot be transmitted to any other parties. --> I lifted this from my own spec on e2ee and I think it's worth considering the protocol implementation such that deniability is preserved as much as possible, though this is somewhat challenging in practice. Optional feature at best, in other words. https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition-11

[TallTed]

I have not read every word above, but the first few sentences scream, "Abusers welcome!" Such deniability feels to me much more like a problem than a feature. Implementing it, or not, and if so, how, needs very careful consideration.