Returning objects in a collection vs. IDs
Technical Discussion
27
Posts
6
Posters
190
Views
-
@grishka I am developing a client application where this is a real concern.
But I agree that in general, originating servers are responsible for verification of client data. This part of FEP-fe34 will likely be revised in the future.@silverpill do you mean that the "malicious" attachment is not a facsimile of an actual note produced by that actor, but a forgery?
In these cases, I'll agree with
@grishka that some validation based on the ID should be necessary.For embedded object attachments on the other hand (like mastodon produces), probably the validation needs to check that attributedTo corresponds to the one of the parent object or missing.
Interesting corner case.
-
@silverpill do you mean that the "malicious" attachment is not a facsimile of an actual note produced by that actor, but a forgery?
In these cases, I'll agree with
@grishka that some validation based on the ID should be necessary.For embedded object attachments on the other hand (like mastodon produces), probably the validation needs to check that attributedTo corresponds to the one of the parent object or missing.
Interesting corner case.
@mariusor Yes, a forged note. I've come up with a more realistic example:
{ "type": "Create", "id": "https://social.example/activity/345", "actor": "https://social.example/alice" "object": { "type": "Note", "id": "https://social.example/note/123", "attributedTo": "https://social.example/alice", "content": "This is just a note, nothing to see here", "replies": { "type": "Collection", "id": "https://social.example/note/123/replies", "items": [{ "type": Note", "id": "https://social.example/note/987", "attributedTo": "https://social.example/bob", "inReplyTo": "https://social.example/note/123", "content": "Ha ha ha... Yes!" }] } } }If the originating server doesn't check the embedded
repliescollection, a recipient that processesrepliesand trusts same-origin embeddings unconditionally may end up trusting the forged note.What we can do?
- Sender: find all embedded objects with local
idand reject activity if they are not known.
- Recipient: trust embedded object only if the wrapping object has the same owner.I think the second solution is much easier to implement. It reduces the utility of embedding in the use case described by @julian, but to be honest I doubt that embedding significantly reduces the number of required HTTP requests in that case.
-
@mariusor Yes, a forged note. I've come up with a more realistic example:
{ "type": "Create", "id": "https://social.example/activity/345", "actor": "https://social.example/alice" "object": { "type": "Note", "id": "https://social.example/note/123", "attributedTo": "https://social.example/alice", "content": "This is just a note, nothing to see here", "replies": { "type": "Collection", "id": "https://social.example/note/123/replies", "items": [{ "type": Note", "id": "https://social.example/note/987", "attributedTo": "https://social.example/bob", "inReplyTo": "https://social.example/note/123", "content": "Ha ha ha... Yes!" }] } } }If the originating server doesn't check the embedded
repliescollection, a recipient that processesrepliesand trusts same-origin embeddings unconditionally may end up trusting the forged note.What we can do?
- Sender: find all embedded objects with local
idand reject activity if they are not known.
- Recipient: trust embedded object only if the wrapping object has the same owner.I think the second solution is much easier to implement. It reduces the utility of embedding in the use case described by @julian, but to be honest I doubt that embedding significantly reduces the number of required HTTP requests in that case.
> - Recipient: trust embedded object only if the wrapping object has the same owner.
@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.
Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.
-
> - Recipient: trust embedded object only if the wrapping object has the same owner.
@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.
Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.
mariusor@metalhead.club silverpill@mitra.social C2S brings with it a whole other rat's nest of security concerns.
In an S2S context same origin content ought to be trusted as having been verified. I'd argue a server blindly reflecting received AP content is a vulnerability.
-
@julian I'm not sure what "blindly reflecting" means, but it's at most as vulnerable as using iframes and way less than trusting CDN scripts.
The way GoActivityPub uses C2S is through clients that validate and sanitize content that they serve back to users, or store in a persistence layer.
Personally I don't understand why it would make it different than S2S?
Are you thinking about C2S from a JavaScript client perspective only?
-
> - Recipient: trust embedded object only if the wrapping object has the same owner.
@silverpill no, dereference object and use that instead. The canonical version of an object is the one retrieved from the originating service.
Mastodon has popularised this behaviour where embedding collections (like your replies) is done by servers in the name of "optimizing" for request counts. But this introduces issues and personally I think it's a "code smell" for ActivityPub. Embedding should be restricted to anonymous objects. When an ID exists it should be used most of the time.
@mariusor This is basically what my FEP currently recommends: you can trust embedded anonymous objects, fragments and
objectofCreate. Everything else should be authenticated using a different method (e.g. fetched from origin). -
@silverpill oh, I see. I must have missed the context for the discussion, sorry. :)
@technical-discussion @julian @grishka
Gli ultimi otto messaggi ricevuti dalla Federazione
-
-
I think the wrapping in <p> is just plain good practice because otherwise rendered content could be injected somewhere resulting in invalid HTML.
Not that browsers ever reject bad HTML anyway heh</p>
-
>Can you explain what goes on in mitra?
When mediaType is text/markdown, the entire content is wrapped in a <p> tag. This was done for compatibility with PeerTube. I think <p> was needed to create a space between the title (name) and the content, since title is prepended to content in Mitra (also a compatibility hack -- for Mastodon API clients).
-
I'd generally discourage RFC7591 in decentralized systems due to the fact that it creates client sprawl (this is currently a problem with Mastodon's client registration mechanism, which is why we created CIMDs) — every client in RFC7591 is a distinct client, with its own client_id and client_secret, which can make client management interfaces difficult to implement (e.g., every time you login on a mobile device or SPA, you'll get a brand new client_id). CIMDs solve this by anchoring client metadata to a URI, and using that URI as the client_id.
If you need to test clients using CIMDs in development, there is cimd-service however, it's currently targeting the AT Protocol ecosystem (so has a few specifics that at present there that would not necessarily make sense of ActivityPub)
-
Speaking of handling markdown. I created funfedi.dev Media Types a while ago (and just added it to the navigation). I lost interest when I saw that nobody properly handled the mediaType attribute of a note. Not that I know what I expected.
Can you explain what goes on in mitra? When mediaType is text/markdown. It changes __bold__ to <p>__bold__</p>, otherwise no paragraph tags. I'm pretty sure, I was once told to use __ for bold and * for emphasize. So my markdown should be good.
Full example ... input activity -> mitra api response
Final note: I am not sure what I would want a proper data format to do. I find the solution of W3C ActivityPub (not W3C ActivityStreams) proposes of putting HTML in content and adding source with the original, from which the HTML was generated ok. Of course, this leaves the existence of the summary and name field superfluous.
-
@reiver@mastodon.social add in NodeBB as well. Markdown first, and probably HTML too, although it will probably be sanitized to death on the way out.
-
@mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
-
@reiver #WriteFreely uses Markdown by default too, but of course sends out HTML to the fediverse
