Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

Hi all,

Each time this type of discussion bubbles up, these kinds of objections 
come to the fore. I believe Melvin, and I, and many others are hoping 
that we can find some compromise or at least a plan to implement that is 
feasible, not put a stop to anything in the works. Specific categories 
of user content and messages need to be treated with a heightened 
security model and the proposed solutions would, ideally, reduce the 
threats of both a malicious host and breaches / seizures as well as the 
growing threat of AI trawling of messages (which is beyond most 
fediverse user expectations in my experience yet also being proposed in 
some FOSS social communities).

I can tell you from plenty of experience that there is a false sense of 
safety permeating the fediverse about so-called "private" conversations 
(direct mentions etc.)

I would give an overview of what is happening in my country and academia 
to drive the point home, but there is too strong a chilling effect, esp. 
over email on a public mailing list - is this the same chilling effect 
we want in the fediverse for all categories of messages?

Client-side key management is one thing, but that should not be an 
essential requirement that blocks all other work on better key 
management and encryption. Well-known threats can be mitigated with a 
variety of methods of generating and managing keys, regardless of the 
trust being placed ultimately with the specific instance (and the 
operator of that instance) utilizing AP for federation. It is of course 
important to consider user expectations with all of this and existing 
software limitations, and that would require significant discussion. So 
I understand the reticence, but please also understand the fediverse 
needs at least a plan for improvement in this area or we will keep 
ping-ponging these conversations.

Cheers,
Sean

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

On 4/12/25 09:53, a wrote:
> from cristiano:
>
>> Summing up, the server sends a message, and this message is not
> necessarily that produced by the client
>
> from emelia:
>
>> For now, for how the keypair is used within ActivityPub for HTTP Message
> Signatures, allowing the server you trust to be custodian of the keys is
> fine
>
> ---
>
> given the current architecture of "the fediverse", and in many ways the
> logical implications of ActivityPub's design, the server is an agent
> delivering messages which can at best be described as "on behalf of" or
> "using the same material as" the actor, where even in C2S the actor's
> messages to the server are consumed and discarded. so client-signed
> activities are currently impossible unless you drop down and do raw Linked
> Data Notifications where the client itself POSTs to the desired inboxes.
>
> in other words, actors are not agents; they are representative resources
> that live on the server. the server is the only real agent.
>
> in RDF terms, any activities submitted to the outbox are necessarily
> different from the activities that get delivered via LDN. they have
> different ids. the activity POSTed to the outbox has a blank node
> identifier. it is used as material to publish and/or deliver an activity
> which may appear very similar but is a fundamentally different activity...
>
> ...in much the same way as two keys sharing the same key material are
> technically distinct. this is also a thing that some implementations do,
> where a single keypair is used for every actor on the server. this is not a
> security issue because the server owns and controls everything, not just
> keys.
>
> if anyone wants to treat clients as agents, then there is a lot more work
> to be done to break away from the instance model. this work would be a
> pre-requisite to any sort of client-side key management.
>
> ~a
>

Received on Saturday, 12 April 2025 17:11:01 UTC