[bug] an Akkoma account can still interact with public posts from a Mastodon account blocking it #769
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#769
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello, i've found out that an Akkoma account can still interact (reply to, boost, ecc.) with public posts from a Mastodon account blocking it. I suppose the reason could be that Akkoma, when requesting access to the post, does not tell the server on which the post was posted by which Akkoma user it is making the request - but that's just a guess.
this is the same between all activitypub implementations - server-to-server requests are always done identifying the instance actor and not any specific user, this is because often there is no initiating user.
but to answer your question specifically, it's probably because you can never guarantee state consistency between instances. the remote instance may have no idea that a block ever went out, the request may have been lost, or it may have rejected the activity altogether due to one of any number of reasons
and in general, federating blocks is actually a very bad idea that relies on actually trusting the remote instance to not do anything weird with that information, which we know that we can't from ye olde blockbot shenanigans. I am not au fait with masto config options but it may have an option to turn off federating blocks to prevent misuse.
I've done some tests and i've seen that
if account a@mastodon.a is blocking account b@mastodon.b, b@mastodon.b can't access to or interact with public posts by a@mastodon.a (good)
if a@mastodon is blocking b@pleroma, b@pleroma can't access to or interact with public posts by a@mastodon (good)
if a@mastodon is blocking b@akkoma, b@akkoma can access to and interact with public posts by a@mastodon.a (bad)
if a@mastodon is blocking b@pixelfed, b@pixelfed can access to and interact with public posts by a@mastodon.a (bad)
I guess that in the first and second cases (mastodon-mastodon and mastodon-pleroma) the block works without instances federating blocks, like in: only the instance of the blocking account (A) knows A is blocking a given account (B) on another instance, and when account B tries to access a public post from account A, B's instance communicate this request to A's instance telling A's instance the request was initiated by B; A's instance checks its database and, seeing account A is blocking account B, it denies access to the post and any possible ActivityPub action on it.
I am attempting to parse the above but cannot decipher the core of it. could you clarify what you are trying to say?
are you confirming that instance-level blocks work, but user-level does not? because that is fully expected
Maybe read it again now, i've tried to make it clearer; anyway, no, in my previous post i was only and always writing about user-level blocks, that are working in the mastodon-mastodon and mastodon-pleroma cases, and are not working in the mastodon-akkoma and mastodon-pixelfed cases. Moreover, i've found out that even if a mastodon instance blocks an akkoma user, the akkoma user can still access and interact with public posts on the mastodon instance.
I believe what you're viewing as a difference in behaviour between pleroma and akkoma is actually a difference in settings; pleroma views Block federation to be opt-out, however akkoma views it as being opt-in due to the safety risk to our users that block federation poses. you would have to manually turn on block federation to get akkoma to behave the same way
pixelfed may also not federate blocks
does this explain the behaviour you are seeing?
for further context, akkoma is a fork of pleroma, which means we inherited most, if not all of their federation behaviour - a difference would be highly unusual
(apologies about the close, touchscreen issue)
When you write "block federation" i understand something like "if account a@instance1 blocks account b@instance2, instance1 has to communicate to instance2 that this block exists", which, as you wrote, would very easily cause state inconsistencies between the instances. But i don't see the need to "federate blocks", assuming "block federation" is what i've written in the previous sentence: seems to me it suffices that instance1 knows its account a@instance1 is blocking account b@instance2, and i guess in the mastodon-mastodon case those blocks do work this way: a@instance1 blocks b@instance2; when b@instance2 sends (for example) a "like" activity to a@instance1, instance1 sees the activity comes from b@instance2, sees that its user a@instance1 is blocking b@instance2, and does not execute the action, sending back to instance2 some error (maybe just an http 403 error). I'm not expert of ActivityPub, but its specs seem to confirm what i've just written: the "block" activity is listed only in section "client to server interaction" (https://www.w3.org/TR/activitypub/#block-activity-outbox), while in section "server to server interaction" it is not.
the way it works without block federation:
letters are confusing so I'm going to use names
Alice is on cat.com, and Bob is on dog.net
step 1. Alice blocks bob. Cat.com notes. that Alice blocks bob.
step 2. Bob tries to fetch a status from cat.com. HTTP fetch signatures only identity the request as coming from dog.net, it does not mention Bob in any way. this fetch is successful
step 3. bob tries to like Alice's status. this will be identified by cat.com as being from bob, and rejected. Alice sees nothing. however, this like still exists, and unrelated instance rabbit.social sees it just fine, as it does not know about the block either.
if your issue is with how mastodon handles things, there's not much we can do about it
I'm still unsure about what exactly you believe akkoma to be doing incorrectly, your descriptions have been very general
can you please format your issue as:
what did you do?
what did you expect akkoma to do?
what did it do instead of your expectation?
I have an account on a Mastodon instance (let's say Alice@cat.com) and another one on an Akkoma instance (let's say Bob@dog.net). From Alice@cat.com i've blocked Bob@dog.net, but after i did it, from Bob@dog.net i could still read, like, boost and reply to public posts i posted from Alice@cat.com, by simply pasting their URLs (which are trivial to get from the web) into the search field of the dog.net Akkoma instance.
When i've put the URL of a post by Alice@cat.com into the search box on dog.net and pressed enter, i expected Akkoma to not find and show the post.
It found and showed the post and let me like and boost and reply to it.
(I did these tests because there's a person stalking me on my Mastodon account from an Akkoma instance: i know it's impossible to avoid this person to read my public posts from the web, but i'd like this person to not be able to interact with them).
How is point 3 different with block federation?
ok, as explained, without block federation, this is expected behaviour.
if blocks federate, dog.net will be told about Alice's block and can prevent bob from acting.
I am now satisfied that there is no issue here, and you are merely seeing the effect of not federating blocks