@julian @silverpill we did not define this well in ActivityPub.
There's an implicit authorization model (creator can write the object, addressees can read and react) which will probably be more explicit in the next version, but we'd leave open other types of authorization.
I think it's likely in the future we'll have a property for defining additional access control options.
Same-origin is a good guess but it's not as good as explicit properties.
@julian @silverpill we did not define this well in ActivityPub.
There's an implicit authorization model (creator can write the object, addressees can read and react) which will probably be more explicit in the next version, but we'd leave open other types of authorization.
I think it's likely in the future we'll have a property for defining additional access control options.
Same-origin is a good guess but it's not as good as explicit properties.
I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.
Correct. FEP-fe34 is based on the assumption that originating servers enforce boundaries between actors. This is stated in the section "Assumptions":
The origin-based security model is designed for use in a network where a server is resposible for enforcing security boundaries between the hosted actors. Servers that publish objects without validation are not supported.
In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)
Question re: Origin Based Security Model (FEP-fe34)
@silverpill@mitra.social said:
In some cases, FEP-fe34 recommends same-actor policy as an additional protection against implementation bugs and against implementations that don't enforce actor boundaries on purpose. Update/Delete authorization is one of those cases (admittedly, the wording is a bit confusing in that paragraph...)
Does this mean NodeBB is wrong is allowing different actors on the same origin to publish Updates and Deletes? I do not know of a way to reconcile this with the ability to have moderators carry out their actions.
No, it's not wrong.
I think the good of group moderation currently outweighs the theoretical bad of same-origin impersonation.
Is the assumption on which FEP-fe34 is based valid?
Of course, it is primarily a philosophical question. Who should be responsible for enforcing boundaries between actors hosted on the same server, the sender or the recipient? In my opinion, the answer is clear: the sender should be responsible.
As far as I know, the majority of existing implementations do enforce boundaries between actors. I am not aware of any implementation that doesn't do that.
Enforcement of boundaries is challenge for generic ActivityPub servers, but it's not insurmountable.
Is the assumption on which FEP-fe34 is based valid?
Of course, it is primarily a philosophical question. Who should be responsible for enforcing boundaries between actors hosted on the same server, the sender or the recipient? In my opinion, the answer is clear: the sender should be responsible.
As far as I know, the majority of existing implementations do enforce boundaries between actors. I am not aware of any implementation that doesn't do that.
Enforcement of boundaries is challenge for generic ActivityPub servers, but it's not insurmountable.
Question re: Origin Based Security Model (FEP-fe34)
My thoughts:
I don't necessarily think FEP fe34 is strict enough to be a guiding principle for security across federated instances. The reporter said:
"at minimum" means same-origin is the floor, not the ceiling.
... and he's right, there's more you should do to verify that only the owner or a designated moderator can update and delete an object.
However we don't have a widely-used ability to determine who the moderators or admins are for any given instance. Mastodon may have an endpoint (in their API), threadiverse software use their own (as directed by 1b12, and even then it's optional), other software 
?
So we fall back to origin-based security model and hand off the responsibility of determining who can and cannot alter somebody else's objects to the sending server.
That's a risk we take with this model. Not sure if there is more that can be done to tighten this up.
@julian You're making a very strong assumption that the remote server is necessarily checking for things it might not actually be checking for.
Neither the "instance" model nor the "same origin" model are enshrined in ActivityPub. This technically falls under "undefined behavior", because AP doesn't define an authorization model. (It suggests ("may") same origin, but that's about it. A lot of things are "at the receiving server's discretion".)
Question re: Origin Based Security Model (FEP-fe34)
@trwnh@mastodon.social on the flip side, I could argue that if the sending server doesn't enforce boundaries between actors, then there's no need to enforce the boundary on my end.
For example, if the sending server is a federated wiki where anyone™️ can edit, then it would actually be incorrect for me to enforce a boundary.
@julian The sending server might not have boundaries to enforce. Especially not along "same origin" lines. This requires agreement on what the authorization model is.
Say for example everyone gets a subdirectory that they "own" -- /~alice/ and /~bob/ have their spaces on the same origin. One authorization model is "anything within this container is authorized". If you don't recognize this, you can't detect that alice and bob have a boundary between them.
Install bonfire.cafe
Get the full app experience
