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

This was discussed extensively when the HTTP Signature community report was
first being drafted, and I would like to remind everyone that right now,
there is no possible way to limit the scope of the URIs the actor keys are
able to generate, and all actors on a server share the same URI namespace.
So to prevent actor custodial keys from signing activities that have URI
collisions with other actor's activities (leading to at best DOS attacks
and at worst an entire class of confused deputy attacks), those problems
would need to be fixed before any consideration of actor custodial keys
would be able to be considered


Additionally, since a user's server is the root of trust for all of their
activities (through URI resolution and the DNS/HTTPS systems), the security
benefits to actor custodial keys are very minimal—they only help you in the
case of a negligent server (e.g. a server that has shut down or no longer
exists), and do not provide any security benefits in the case of a
malicious server (which could just choose to present whatever activities it
wanted, or selectively delete the actor's profile or activities with no
recourse)


Therefore, I am of the strong belief that considering the HTTP Signature
keys currently stored on the actors profile as "actor" keys is deeply
misguided, since those keys are tied so intimately in the current protocol
to HTTPS URI resolution. Removing the server from the root of trust will
have to start with a useful replacement for HTTPS scheme URIs, and the
downsides of replacing HTTPs URIs are just too significant to be worth it
for most users (no backwards compatibility, much much harder for devs to
get right, significantly increases the barrier to entry for new software)


Instead, ActivityPubs support for federated server trust already allows
actors to put their trust in as small of a server as they wish to—users can
use the network's architecture to make much more granular trust decisions,
either by trusting only themselves by running their own server, trusting a
publicly known infrastructure provider like Hetzner by running an out of
the box server template, trusting an admin they know personally like
Emelia, or trusting a large, reputable non-profit like Mastodon or
Mozilla's servers. All of these decisions have trade-offs, but it's not
clear to me that trusting a large, regulated non-profit is somehow worse
than trusting a centralized, for-profit identity provider like Bluesky or
Twitter, which is what most actual users would end up doing instead of
using ActivityPub

On Sat, Apr 12, 2025, 5:44 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?
>>
>
> <#m_-8422279906306481567_m_-3177165817094636861_m_3004991747035250694_m_-3563660455870067756_>
>>
>> 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
>
>