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

Thanks Emelia.

These are certainly important issues to think about. It seems to me that they can be solved or mitigated with UI / UX in applications as well as by OPSEC training - for example with pin codes, additional encryption and authentication, backup methods, etc.

In that sense the issues are not fundamentally different than other security issues. Different approaches can be used for different threat models. That's all out of scope for a standard though, which should facilitate many different ways of key management but first make it viable to do this.

I will also add that the current trend, in some cases driven very consciously by powerful network intermediaries, to move toward passkeys makes it quite likely that credentials will be increasingly tied to specific devices, whatever specific projects using AP decide to do.

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 April 12, 2025 12:43:08 PM UTC, 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 <mailto: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

Received on Saturday, 12 April 2025 13:32:25 UTC