clarify/extend security consideration B.2 "verification" for attached files

[Johann150]

As a thought after Mastodon's GHSA-jhrq-qvrm-qr36 it might be a good idea to extend the security consideration B.2 with a bit of wording about what kind of user submitted content is meant, and what relevance the Content-Type and perhaps Content Type Negotiation has in that context.

Especially when reading the 2nd paragraph the focus seems to me to be on ActivityPub Content, perhaps not taking into account that attached files/media may be hosted on the same host(-name).

In particular I'm thinking of wording like this:

Servers should not trust client submitted content (both ActivityPub activites and, if hosted by the same host, other resources), ...

And perhaps inserting another paragraph like this at the end of the section:

Federated servers that serve resources completely under the control of users, like for example attached media files, SHOULD make sure that the Content-Type header of such files can never be application/ld+json; profile="https://www.w3.org/ns/activitystreams" or application/activity+json. On paths/directories controlled by users, they SHOULD return the HTTP status code 406 "Not Acceptable" if a client's Accept header is set to application/ld+json; profile="https://www.w3.org/ns/activitystreams" as required of the client in section 3.2.

[evanp]

This is an issue with user-uploaded data. Here are some ways to mitigate:

1. As suggested, No JSON uploads.
2. Remote clients should check the content-type for JSON types when GETting, and don't accept e.g. text/plain as AP, maybe application/json.
3. Use a separate domain for uploaded artifacts. This will prevent naive checks that just accept the same origin as verification.
4. Develop an attribution endpoint FEP to check attribution of objects. Possibly other types of endpoints for other verification, including a server-wide verification.
5. Use digital signatures. Who the signature is from and what it entails is an open question. E.g. is it client side, server side, user owned, server owned, ...

I believe this solution requires at least these fixes:

1. A Primer page on the topic.
2. An Erratum for the security consideration in verification that covers the issue.
3. Potentially pushing the editor's draft to the public document.

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-0391-special-collection-proofs/4165/4

[evanp]

I've been fairly strict in applying errata to ActivityPub and Activity Streams 2.0 Core and Vocabulary, primarily focusing on textual errors and syntax errors in examples. However, in discussing this particular issue, during issue triage, Lisa Dusseault pointed out that the W3C allows three different classes of changes to be marked as errata.

In particular, it does allow changes that don't add new features. I think a security consideration like the one mentioned in this issue would fall into that class of change.

As we move into a period where a Working Group will soon (hopefully) be chartered for a next version, this may be a moot point, but I'd like to have the Social CG make a decision about whether we want to track errata that add information to the spec without adding new features or impacting conformance. I'll put it on the agenda for an upcoming meeting.

[nightpool]

I agree that I think we should strongly consider security considerations and recommendations at the level of Errata—perhaps listed separately from other Errata, but they represent "best practices" that are basically required for a strong and secure deployment of the specification.

…

On Fri, Feb 21, 2025 at 9:41 AM Evan Prodromou ***@***.***> wrote: I've been fairly strict in applying errata to ActivityPub and Activity Streams 2.0 Core and Vocabulary, primarily focusing on textual errors and syntax errors in examples. However, in discussing this particular issue, during issue triage, Lisa Dusseault pointed out that the W3C allows three different classes of changes <https://www.w3.org/policies/process/#errata> to be marked as errata. In particular, it does allow changes that don't add new features <https://www.w3.org/policies/process/#class-3>. I think a security consideration like the one mentioned in this issue would fall into that class of change. As we move into a period where a Working Group will soon (hopefully) be chartered for a next version, this may be a moot point, but I'd like to have the Social CG make a decision about whether we want to track errata that add information to the spec without adding new features or impacting conformance. I'll put it on the agenda for an upcoming meeting. — Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCVZBDVYRMFUUNIQA3VL2Q5QMJAVCNFSM6AAAAABXTYA4DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZVGE3TGOBXGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: evanp]*evanp* left a comment (w3c/activitypub#432) <#432 (comment)> I've been fairly strict in applying errata to ActivityPub and Activity Streams 2.0 Core and Vocabulary, primarily focusing on textual errors and syntax errors in examples. However, in discussing this particular issue, during issue triage, Lisa Dusseault pointed out that the W3C allows three different classes of changes <https://www.w3.org/policies/process/#errata> to be marked as errata. In particular, it does allow changes that don't add new features <https://www.w3.org/policies/process/#class-3>. I think a security consideration like the one mentioned in this issue would fall into that class of change. As we move into a period where a Working Group will soon (hopefully) be chartered for a next version, this may be a moot point, but I'd like to have the Social CG make a decision about whether we want to track errata that add information to the spec without adding new features or impacting conformance. I'll put it on the agenda for an upcoming meeting. — Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCVZBDVYRMFUUNIQA3VL2Q5QMJAVCNFSM6AAAAABXTYA4DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZVGE3TGOBXGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>