so I've started seeing Mastodon apps fetch posts in threads from other servers directly, bypassing server blocks.

This is ... this is deeply concerning to me.

@aurynn Can't this be prevented by enabling authorized fetch on the server?
@kuna RSS feeds still exist
@aurynn oh? Can you point out which ones?
@doofus_canadensis I saw tooot doing it, at the very least
@aurynn I'm annoyed that the ones I'm trying out don't honour my filters.
@doofus_canadensis @aurynn people been really nagging Tusky to add some because Mastolab has it. Mastolab respects blocks somehow but it's still a shitshow
@charlag @doofus_canadensis @aurynn Frankly, the fact that apps are able to do this kind of thing at all is deeply concerning.
@XanIndigo @doofus_canadensis @aurynn I think it was actually pretending to be an AP Actor (basically like another server) so I guess it doesn't work when AUTHORIZED_FETCH is enabled (or with any GtS server). Still.
@aurynn @charlag @doofus_canadensis I’m not a software person, so I can’t form any valid opinion on the technical details. All I know is that if there’s a way to evade a block that’s so easy that these apps seemingly did it by mistake, that’s a pretty big problem.

@XanIndigo @aurynn @doofus_canadensis yeah it is and a lot of people (even Pleroma people back then) been saying it pretty loudly and I keep saying it. Mastodon makes it worse by
- not enabling the option I mentioned before by default (which is like a baseline to prevent this)
- using API access (another method) for unauthenticated web UI since 4.0

And there are more ways stuff gets leaked too which sucks majorly

@aurynn @doofus_canadensis yeah it got enabled in tooot a few weeks ago i think — i wouldn’t mind a ‘fetch whole thread’ button honestly (assuming it respected blocks, etc) bc sometimes the extra context is helpful (trying to figure out if that question has been answered 100 times already, etc) but on average its made my fedi experience less pleasant

@aurynn ugh…

this was bound to happen because mastodon doesn't keep its local posts up to date 🦋

@traumaphoenix Distributed consistency is hard. But this isn't the right approach.

@aurynn no, I agree, the right approach would be to have the server fetch it like some other fedi servers…

but something tells me this has been flagged to website boy and he's responded by doing nothing

@traumaphoenix the server won't fetch it if it's a defederated server

@aurynn yeah but that's not the problem here

the apps' developers didn't put it in to bypass defederation, they put it in because mastodon does a piss-poor job of keeping posts up to date

this is entirely on Mastodon

@traumaphoenix distributed consistency is a hard problem
@aurynn if only it didn't bypass server blocks and instead had some method of checking for them, this would actually be quite helpful if you're on a small server with absolute piss visibility like mine

but extra visibility of remote posts is not worth it for unnecessary overstepping of boundaries!!
@aurynn
Server blocks? Don't know what that means.
@cecilbothwell your instance can (and should) block other instances directly
@aurynn @doot how would the client app have seen the first post at the top of the thread if the logged in users instance was blocked?

@aurynn given how much Mastodon thread context fetch fails at actually providing context, i'm not surprised that client devs are doing this. hell, i've considered implementing it too. but this should be the server's job: so posts only have to be fetched once and so the client doesn't have to talk to foreign servers directly ☹️

another reason to turn on AUTHORIZED_FETCH and DISALLOW_UNAUTHENTICATED_API_ACCESS

…and then field ninety questions a day from users who don't understand why they can't see posts in their browser. if the Mastodon web GUIs were smarter about running clicked links through the search/resolve API, this would be a lot less of an issue.

Configuring your environment - Mastodon documentation

Setting environment variables for your Mastodon installation.

@vyr I had to disable authorised fetch because it was blocking access to some, in the current crisis in Auckland, rather necessary twitter bot mirrors.

@aurynn

@jerry Would there be a way to block this or would that just end up in an arms race? 🫤🤷‍♂️

@simonzerafa @jerry Server admins could block apps that do this in their webserver, by checking for the useragent? beyond that, telling app devs to not do this

@aurynn @jerry

Blocking based on User Agent isn't likely to end well? 🤔🤷‍♂️

@simonzerafa @jerry I didn't say it's a good idea, it's just the only one I can think of

@aurynn @jerry

It was might first thought also and would be shot down if an app or client pretended to be Google Chrome.

Really unpleasant behaviour if clients are doing this type of bypassing though.

@simonzerafa @jerry tooot is, and Mastolab, and I'm told the Tusky dev is being pressured to add it

@aurynn @jerry

It's needs to be stopped sooner rather than later. Something the Mastodon Devs to look into perhaps?

Greetings to Aotearoa 🙂🖖

@simonzerafa @aurynn I believe this is symptomatic of the big misunderstanding of blocks and defederation.

@jerry @aurynn

Very likely a deliberate strategy to bypass blocks and de-federation.

@simonzerafa @aurynn I’m less convinced this is the result of an attempt to circumvent blocks and more of a side effect of how the apps are collecting posts, combined with the reality that blocking an instance doesn’t actually block the instance (by default, at least)

@jerry @simonzerafa I agree that it's not meant for block circumvention, it just has that effect and will expose users to hate speech and other garbage and I won't have the ability to suppress that for my users.

Which is *bad*.

@aurynn @jerry @simonzerafa Unauthenticated apps can only fetch the same posts that are visible on the public web interface via the API. Doing that removes some work for the app user (opening a post in a browser to see the thread).

If the home instance of the user is blocked, they shouldn't be able to make their instance pull the post in order to interact with it, but as others have said, blocks are leaky, and while secure mode / AUTHORIZED_FETCH should make it better, that has some additional drawbacks...

I'm not saying this is good, or the way it should be. But the public API functionality has been there all the time, just with very few apps actually using it. Mastodon itself doing such a bad job at completing threads drives development of alternative solutions.

@galaxis @jerry @simonzerafa I had to go and disable authorized_fetch since it was breaking bird.makeup, which is where the civil defence are mirrored, for the current state of emergency in Auckland.

I agree, this is a place where Mastodon core should have a gossip protocol feature, and communicate more of this stuff.

@aurynn @galaxis @simonzerafa I expect it’s a bit of a support nightmare even in times of calm.
@jerry @galaxis @simonzerafa No one said running an instance would be easy or fun 😉

@aurynn I see no replies to this post, because I'm on a small instance and it doesn't receive replies along with boosted posts.

Therefore, my normal flow when I think I might want to reply to a post is to open it on the original server, so I can see the rest of the conversation first.

I understand the block concern, but the normal usage of many users bypasses that anyway because they are trained to open the original page, so does this really change much?

@aurynn Obviously it would be better if the user's own server was able to provide the context that they should actually see, blocks included.

I'm not sure, but I assume https://github.com/mastodon/mastodon/issues/18150 should do this? But given that issue #34 is pretty similar, it seems unlikely that's going to get a huge amount of priority :(

UI button to "see all conversation" using context API · Issue #18150 · mastodon/mastodon

Pitch I think this has been talked about before in threads like #14017 and #3794 Essentially when viewing a toot on a small instance you are often missing replies because your instance never saw th...

GitHub

@aurynn Ah - I see that in fact it is the solution described in the issue linked above which is causing the concerning app behaviour.

I've added a note to the bottom of that issue mentioning the concern and suggesting a way this could potentially be fixed without stopping clients from being able trigger fetching of context (which for me at least, would be a really useful feature!)

@mike The solution is a gossip protocol being added to AP
@mike you may want to ask your admin to join some relays

@aurynn I've been trying to understand what relays do and whether they might help with this (I am the admin). Info seems sparse, but from what I understand relays would indiscriminately push publicly available toots to my server, even though no-one follows them.

As far as I can see, unless I subscribe to some firehose relay that would cost many TBs of storage and bandwidth, it wouldn't actually help with this context problem - because it would need to find the replies purely by luck.

@aurynn I don't see anything wrong with people being able to access content from servers that have been blocked by their own server, as long as they are made aware of this happening.

I don't think people should be forcefully blocked from viewing content on their own devices just because the administrator of the server they happen to be on wants to block that content.

It's fine for one server to block another, but it's also fine for people to decide on their to unblock it for just themselves.

@mostly_harmless tell me you're a privileged asshole without telling me you're a privileged asshole
@aurynn Uncalled for. But that's ok. I bear no animosity towards you.
@mostly_harmless (Untagging Aurynn because you’ve blocked her, oh, the irony) If you find yourself on an instance where the people you want to read have been instance-blocked by your admin, that should be a very strong signal to you that you are on the wrong server and that you should move. Any client feature that hides this signal from you by working around a block is acting counter to the concept of federated communities.

@futzle But it's not happening on the server. It's happening on the individual user's device, and everything that happens on their own device is their own business and no one else's.

What's next, if the server admin doesn't like me playing solitaire on my computer now I have to uninstall it because I can only do things on my computer that the server administrator allows?

I blocked her for hurling obscenities at me with no justification.

@futzle Also, I don't care if she uses an app to see my posts even though I blocked her. I don't block people to stop them seeing my posts. I block people so that I won't see their posts.

I guess we just approach this from totally different directions.

@mostly_harmless That would be the privilege that you were accused of having. Some of us need to block to prevent others seeing our posts. You don’t need to do that. Recognize that your position is a privileged one.
@mostly_harmless You have missed my point, but that’s ok, because you probably wouldn’t agree with it anyway. If you need this client feature, it’s because you disagree with the decisions of your admin. So get a different admin, or become your own admin. On the Fediverse moving is so easy! And that’s where your solitaire analogy breaks down: there are thousands of server administrators for you to choose from, or you can become your own.

@futzle But why would you care if people on the same server as you can see content from other servers that you don't see?

It doesn't actually affect you.

This all seems like an ego-trip to me. It seems like you're not sufficiently satisfied by having undesirable content blocked from your view and require that everyone in your vicinity also have that content blocked from their view.

I have a mormon coworker that throws fits when people drink coffee. This reminds me of that.

@mostly_harmless I think you and the OP are having a community/individualism impedance mismatch.

Instance blocks (and server rules and timely moderation) are tools to define the culture and community of an instance. Not every instance has a strong sense of community (I’m guessing yours doesn’t) but on the ones that do, it’s important to set boundaries and enforce them. No one’s a hostage; as I’ve said twice, it’s easy to move servers on the Fedi.

Your Mormon analogy would be more apt if they were your CEO and instigated a company-wide coffee ban. As you tell it, your coworker is the hostage in a hostile culture but can’t leave (because employment market ≠ Fediverse).