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

I am in agreement with Emilia,

Having users the be key-holders/custodians is probably not the safest way to handle this. Especially if it defaults to mobile devices (failure points: loss, damage, changing mobile devices).

There are probably some really great alternatives for this issue, and I'm going to bring it up with my colleagues at Hackers Town to help brainstorm ideas.

---
"We will never know world peace until three people can simultaneously look each other straight in the eye." - Puscifer

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

On Saturday, April 12th, 2025 at 8:43 AM, emelia <emelia@brandedcode.com> wrote:

> Hi Melvin,
>
> One community for which I have some knowledge of is the sex worker community, and having spoken with folks who provide services to extremely marginalized trans sex workers who do street work, it was not uncommon for them to either be robbed and have their only phone taken or to need to sell the device to make ends meet. (And no, they didn't have other devices)
>
> If our social networking apps suddenly require users to securely store private key material and ensure that is not lost, then we're going to be excluding not insignificant portions of society from social networking apps.
>
> That is the downside of making the person using the app the custodian of the key: they likely won't realise only their phone has a specific thing that enables them to access.
>
> This might be fine for technical audiences, but isn't for non-technical ones.
>
> So then you get into authentication via PAKEs plus encrypting a key encryption key with a password derived from the person's login password (like protonmail & iCloud), and these are complicated at best to implement.
>
> 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, and actually provides many benefits to communities often under represented in technical decision making forums.
>
> Yours,
> Emelia
>
>> On 12. Apr 2025, at 12:05, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>> so 12. 4. 2025 v 11:26 odesílatel Nils (aka Nordnick) <w3c@hhmx.de> napsal:[> Hi Emelia, Hi Melvin, Hi all,
>>>
>>> i agree with Emelia here... (see below).
>>>
>>> On 12 Apr 2025 at 10:06, emelia wrote:
>>>
>>> [...]
>>>> That is to say: you'd need to completely change how you think about
>>>> doing anything with the Actor's private keys to make it
>>>> user-custodial, because the private key is used for signing outgoing
>>>> requests that may happen in the background & it would necessarily make
>>>> sense to send the users' active sessions a message going "hey, can you
>>>> sign this HTTP request I need to make?" for HTTP Message Signatures.
>>>
>>> Trying to imagine, how this should work in real life, if the
>>> (non-technical) user should provide a key for each signing of a HTTP
>>> request in the background.
>>>
>>> Also it would it make really hard to use multiple ways to handle an
>>> account... how should a user store a key, if he or she uses multiple
>>> apps and UIs on multiple devices?
>>
>> Show Quoted Content
>>
>>> Hi Emelia, Hi Melvin, Hi all,
>>>
>>> i agree with Emelia here... (see below).
>>>
>>> On 12 Apr 2025 at 10:06, emelia wrote:
>>>
>>> [...]
>>>> That is to say: you'd need to completely change how you think about
>>>> doing anything with the Actor's private keys to make it
>>>> user-custodial, because the private key is used for signing outgoing
>>>> requests that may happen in the background & it would necessarily make
>>>> sense to send the users' active sessions a message going "hey, can you
>>>> sign this HTTP request I need to make?" for HTTP Message Signatures.
>>>
>>> Trying to imagine, how this should work in real life, if the
>>> (non-technical) user should provide a key for each signing of a HTTP
>>> request in the background.
>>>
>>> Also it would it make really hard to use multiple ways to handle an
>>> account... how should a user store a key, if he or she uses multiple
>>> apps and UIs on multiple devices?](#)
>>
>>> Hi Emelia, Hi Melvin, Hi all,
>>>
>>> i agree with Emelia here... (see below).
>>>
>>> On 12 Apr 2025 at 10:06, emelia wrote:
>>>
>>> [...]
>>>> That is to say: you'd need to completely change how you think about
>>>> doing anything with the Actor's private keys to make it
>>>> user-custodial, because the private key is used for signing outgoing
>>>> requests that may happen in the background & it would necessarily make
>>>> sense to send the users' active sessions a message going "hey, can you
>>>> sign this HTTP request I need to make?" for HTTP Message Signatures.
>>>
>>> Trying to imagine, how this should work in real life, if the
>>> (non-technical) user should provide a key for each signing of a HTTP
>>> request in the background.
>>>
>>> Also it would it make really hard to use multiple ways to handle an
>>> account... how should a user store a key, if he or she uses multiple
>>> apps and UIs on multiple devices?
>>
>> Hi Nils, great questions!
>>
>> I’m probably missing something obvious, but I was wondering: What’s the challenge with users holding