@julian @grishka

Here's en example:

It contains an embedded Note that is attributed to another actor. There are many possible ways to embed an object, and malicious embedding could be difficult to detect for the origin server.

grishka@mastodon.social silverpill@mitra.social yes I had the same question.. I assumed this would only occur in a C2S context but even then the server is an intermediary and can verify.

@silverpill @julian @technical-discussion
> The server hosting the malicious actor can't realistically verify every embedded object

How so? It's a responsibility of that server to authenticate its actors, and restrict them from impersonating other actors on the same server, C2S or not. I don't quite understand the threat model here. In mine, clients are always assumed malicious.

@julian How should it be amended? Just add a sentence saying that some collection items might be full objects instead of IDs?

You can trust the objects owned by the server you're requesting data from. (this is fe34)

It's complicated. Those objects are embedded within another object (a collection), and FEP-fe34 currently doesn't recommend trusting embedded objects, except for a few special cases:

An object is the object of a Create activity, and it has the same origin and the same owner as the activity.
An embedded object is identified as a fragment of the wrapping object.
An embedded object is anonymous (doesn't have an ID).

https://codeberg.org/fediverse/fep/src/commit/b7dddd105b23762d4c59b4ffa7e43ca66af0939b/fep/fe34/fep-fe34.md#embedding

This is because ActivityPub Clients can publish arbitrary activities, and a malicious actor may embed an object that is attributed to another actor on the same domain. The server hosting the malicious actor can't realistically verify every embedded object, so if a remote server trusts same-origin embedded objects unconditionally, the malicious actor might succeed in impersonating another actor.

But maybe collection items should be added to the list of exceptions, because collections are almost always server-managed? I need to think about this.

@grishka

In another topic (#Smithereen 0.11 is out!), grishka@mastodon.social says this:

> I have this convention where I return IDs for remote objects (obviously, how else would you authenticate them if not by fetching from the origin servers) but complete objects that are local, to save resources. IIRC I saw Mastodon do it for replies so just copied this behavior

It was in response to a discussion about conversation contexts — a resolvable collection of items that represents a conversation, thread, reply tree, etc.

Most implementors return a collection of object IDs, some return a collection of activities.

What about a mix of object IDs and full objects? That's interesting — it's the first I've heard of it.

My gut reaction is that it's messy... mixing types: strings for some items in the collection and complete objects for others.

... but I think at the end of the day, there are three things we need to acknowledge:

I wonder if an amendment to f228 is needed silverpill@mitra.social to capture this use-case?