- From: Evan Prodromou <evan@prodromou.name>
- Date: Wed, 13 Mar 2024 09:30:17 -0400
- To: Emelia Smith <emelia@brandedcode.com>, Social Group <public-swicg@w3.org>
- Message-ID: <ec0216ff-5b87-4796-8b2e-8952fabe8e71@prodromou.name>
Make an issue in GitHub. It's a normative change, not backwards compatible, so it would need to wait until a Working Group is chartered to publish a future version of ActivityPub. Evan On 2024-03-13 6:43 a.m., Emelia Smith wrote: > Splitting this out from the recent Data Portability thread, currently > the ActivityPub spec only has HTTPS as a SHOULD not a MUST, in 2024 > that seems like an unwise decision given: > > - Most AP software mandates HTTPS connections when sending > > - Most browsers enforce HTTPS now and warn on insecure connections > > - It is very straightforward to get a free SSL certificate provisioned > via LetsEncrypt > > Would it be an idea to change this to a SHOULD when deployed publicly > on the web? (i.e., localhost & private testing networks don't need > HTTPS, but servers that are publicly federating do) > > Yours, > Emelia > >> On 13. Mar 2024, at 03:10, Evan Prodromou <evan@prodromou.name> wrote: >> >> >> Lots to unpack here. Main things: ActivityPub does require HTTPS. >> Also, the standard way to do server to server authentication is with >> HTTP Signature, which one of our groups is documenting now. >> >> On Mar 12, 2024 19:03, Lisa Dusseault <lisa@dtinit.org> wrote: >> >> >> I recently finished a series of blog >> <https://dtinit.org/blog/2024/03/12/access-content-spoofing-threats> >> posts <https://dtinit.org/blog/2024/01/16/threat-model-pt-one> to >> catalogue threat models for data portability. I expect it's a >> little bit of heavy reading, so maybe don't read it! It's over >> general! But I hoped it would be useful as a list and explainer >> of things to consider. >> >> So here's the list of general threats, applied specifically to >> the use case of moving a user's account and activity from one >> ActivityPub server to another via server-to-server pull. >> >> *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? >> >> *Denial of Service* >> * It must be possible for a data transfer activity itself to be >> halted or throttled on either side. One proposal: the >> destination initiates transfer and requests content items — it >> can stop any time it reaches quotas or other limits. Meanwhile, >> the source server can throttle request handling. This is often >> done at lower layers than the transfer protocol, so it may not >> need any solving at the ActivityPub layer. >> >> * Could bulk activity transfer be used to aid DOS attacks >> elsewhere? E.g. When bulk transferring activities, the >> destination service should NOT process each new item in the >> outbox and target and deliver those activities to the to, bto, >> cc, bcc or audience fields. >> >> *Elevation of privilege* Servers accepting new data in bulk >> transfer must do the same checks for buffer overflow or similar >> attacks that they would for any new data. This doesn’t need >> protocol work, just a note. >> >> *Non-compliance*. Servers accepting new data must review that >> data for their own compliance requirements such as meeting CSAM >> regulations. >> >> *Harmful content* servers accepting new data must review that >> data for their own harmful content policies. >> >> *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. >> >> *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 >> >>
Received on Wednesday, 13 March 2024 13:30:29 UTC