Re: Threat models and data portability and ActivityPub

These are great! Looking forward to digging into the posts. Thank you for
writing them!

A few quick thoughts inline:

On Tue, Mar 12, 2024 at 4:04 PM Lisa Dusseault <lisa@dtinit.org> wrote:

>
> *Disclosure and Indirect disclosure* -  ActivityPub doesn’t seem to
> require HTTPS/TLS.  Is it assumed? Should it be required for data
> portability use cases?
>
> *Tampering* again should this require TLS?
>
> *Non-repudiation* To the extent that the destination server trusts the
> source server, repudiation shouldn’t be a big problem.  Should source
> server certificates be required?
>

Yes, SSL is only a SHOULD in AP <https://www.w3.org/TR/activitypub/#obj-id>,
not a MUST, but in practice on the fediverse, yes, it's assumed. Afaik many
fediverse projects require that they serve over SSL, and some also require
it for remote federated servers.


> *Spoofing* This needs careful protocol design for the S2S part - to
> define how an ActivityPub server makes sure that another ActivityPub server
> is who they say they are when they ask for user-approved access to
> non-public data.  I’m assuming *user* anti-spoofing is through existing
> authentication mechanisms.
>

Traditional per-activity authentication in AP is HTTP Sigs (common) and/or
LD Sigs (less common, primarily sent by Mastodon during inbox forwarding
<https://www.w3.org/TR/activitypub/#inbox-forwarding>). Practically
speaking, AP's authn security model collapses to custodial keys held by
instances, so if you're using SSL to authenticate the source (sending)
instance, that's generally good enough.

As for *authorization*, that's also limited and largely unspecified, but
some bits do exist, and would probably be good hygiene to (re-)check on
bulk imported objects/activities. Details in
https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization



> *Permissions and access controls* - Part of this is unilateral on each
> side.  On the source side, the source server should allow the user to
> confirm that it is granting access to private information when a data
> portability request is made.  On the destination side, the destination
> server should confirm whether the imported data is going to be public or
> not.    However, we do need to make sure that silent and private activities
> are transferred as such.
>
> What have I overlooked in this analysis?  What bad assumptions have I
> made?
>
> Lisa
>
>

-- 
https://snarfed.org/