trwnh:where software A supports the Accept flow and/or stamps, and software B does not, then a “quote post” coming from B is subject to the policies of A on how it wants to handle the authorization/validation aspectMy concern is more about the other wa...

[ilja@socialhub.activitypub.rocks]

trwnh:

where software A supports the Accept flow and/or stamps, and software B does not, then a “quote post” coming from B is subject to the policies of A on how it wants to handle the authorization/validation aspect

My concern is more about the other way around, but maybe I should make the scenario more explicit;

Let's say we have A@quote-controls.example.com whose instance implements quote policies and controls as described in this proposal. And we have B@social.example.org who does understand FEP-e232 quote posts, but not the controls and policies as described here.

• A@quote-controls.example.com posts a nice drawing they made, but don't want people quoting it, so they set "acceptsQuotesFrom": "https://quote-controls.example.com/users/A".
• The post is then send out to followers, including B@social.example.org
• social.example.org receives the post, doesn't understand the acceptsQuotesFrom property, and therefor ignores it as it is required by Activity Streams 2.0; "In Activity Streams 2.0, an "extension" is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions must not stop processing or signal an error and must continue processing the items as if those properties were not present."
• B@social.example.org really likes the drawing and wants to bring attention to it, quoting the post "Look what awesome drawing, this is so cool! :blobfoxaww: "
• A@quote-controls.example.org, expecting that other are not allowed to quote post, somehow learns that B@social.example.org did quote the post.
• A@quote-controls.example.org is now very angry at B@social.example.org even though B@social.example.org did nothing wrong.

trwnh:

The question then is about whether any given servers share the same policy. If they do, great! If not, then there might be social issues that arise because of that.

Yes! That social issue is what I am concerned about. To me, this is basically what the first paragraph of the Security considerations is also about.

trwnh:

that kind of disparity in functionality is also quite normal on the network.

I agree that it is quite normal in current fedi, but that doesn't make it OK. To use the DM example; AP makes an explicit distinction between public or not. Wildebeest leaking dm's was completely in the wrong of them and people were 100% in their right to tell Wildebeest to fix their implementation. But here we have the opposite scenario. Here the controls are not made explicit by AP. On the contrary even, AP makes it explicit that they are purely optional. As far as I still remember correctly, this is more like how current dm's were originally implemented in ostatus. (It's a very long time ago, and I was very new to the network myself, so I could be wrong on things, but from what I still remember how I understood the situation;) They were first implemented in public posts in a similar optional way by adding some property which would be ignored by instances not understanding it, so dm's started to "leak" through implementations who didn't understand this optional extension. Contrary to the Wildebeest situation, the problem here was with the sender sending dm's as basically public posts, not the receiver naively forgetting some check. And the provided fix was to not send these dm's any more to implementations who didn't understand it.

Basically what I'm saying is that we can do something about the first security consideration in a similar way;

Claire:

Servers not implementing this FEP will still be able to quote the post and provide no dogpiling-reducing friction. There is unfortunately nothing we can do about that.

I agree that A@quote-controls.example.com can't send the post to B@social.example.org and expect the controls to work. But a trade-off can be considered between wider spread, or more control. More precisely:

• Wider spread means that A@quote-controls.example.com sends out the note as currently happens, even if it means that B@social.example.org is still fully in the right to quote the post.
  • In this scenario the property "acceptsQuotesFrom": "https://quote-controls.example.com/users/A" basically means "I prefer to not be quoted, but if you don't understand this property, don't worry about it, you're still free to quote post anyhow, I'll just ignore it myself and others may as well".
  • Afaict, this is how the current proposal works.
• More control could be done by only sending to actors who indicate they understand and will enforce these controls properly.
  • In this scenario the property "acceptsQuotesFrom": "https://quote-controls.example.com/users/A" basically means "I do not want you to quote this post, and you have already told me you will respect that wish".

The second is as strong as dm's currently work, which could be a worthwhile trade-of to have. Also note that having a way for the second option, does not exclude the first option to still be available for those who prefer that.

Practical

The question for the second scenario then becomes, how to indicate someone understands and will enforce these controls. You send to actors, and when an instance fetches a post, authorized fetch uses an actor as well. So one option is to check the actor. Afaict, the current proposal doesn't have a specific property set on the actor, but maybe capability discovery can be used. E.g. (I'm using a random fep-888d-like namespace as an example, but another could be used)

{ "@context": [ "https://www.w3.org/ns/activitystreams", { "litepub": "http://litepub.social/ns#", "capabilities": "litepub:capabilities", "CompliesWithQuoteAuthorization": "https://w3id.org/fep/XXXX#CompliesWithQuoteAuthorization" } ] "type": "Person", "id": "https://quote-controls.example.com/users/A", "capabilities": { "CompliesWithQuoteAuthorization": true },}

There may be other, maybe better, ways to do this as well. But this is at least one example how something can be done about the first security concern. It could of course be considered if this is really worth having or not, but yes, at the very least communication should be clear so that no wrong expectations are set if we are to avoid such "social issues" as much as possible .