Follow

Mastodon PSA, mostly for admins 

Mastodon has a thing called AUTHORIZED_FETCH. You should almost definitely enable it.
Some people say "but blocked instances can still see my posts" well not with this thing on. This makes server check who is trying to get your posts and will yeet all the blocked instances. That's what all modern software just assumes but it prevents Scaling (and relays) so it's not on by default.

docs.joinmastodon.org/admin/co

If you are on masto.host you can ask this to be enabled.

It was brought to my attention that it might affect visibility in threads so keep this in mind

@charlag
Authorized_fetch makes it impossible for simple AP implementations to fetch toots; without providing much benefits.
Unless you whitelist instances; any blocked instances can get around the block by pretending to be a new instance.

@val well good luck setting up new keys and domains all the time.
I *hate* techbro-ey take on this. "Without much benefit" and "oh it's not perfect so it's useless". That's why it took years to get any security measures, because people are up their ass and don't understand that non-perfect measures can work very well.

@charlag malicious instances does not need to "set up new keys and domains all the time"; they just need to do it once for a domain that never sends anything.
Mastodon does not have the tools to find which of the thousand domains it federates with is leaking toots.

@val not exactly. When you are fetching something you do in on behalf of an actor which we need to resolve thus find out about the instance it's on (so it must be able to do at least that and will show up). Once they are found out they need new things. It is much easier to block than to set this up.

@val Mastodon has a list of servers it federated with under Moderation

@charlag There are thousands of these; how can you tell which one is leaking toots?

@val well maybe for you, I just meant that it will be there. It is also possible to query who is never sent anything pretty easily (e.g. none of them follow your user) or who uses the same IP as the fash instance.

Even if each fash instance has to set up one more thing to go around the blocks, it's already worth it.

@charlag For example, I just queried one of your toots (birb.site/@charlag/10822337077) from some instance I set up months ago. It uses the same IP addresses as my normal one (oc.todon.fr), because I'm lazy.
How can you tell the domain I just used?

@val I don't have access to PC right now but isn't it pretty easy to query which instances use the same IP as blocked ones?

@charlag as far as I know, no; because Mastodon does not store what IP addresses their backend queries come from (it could technically, but it doesn't do it).
It only works if their backend is on the same IP address as their reverse-proxy (because you can query it via the DNS), but that's useless because all the fash already use Cloudflare as reverse-proxy

@val @charlag nothing is perfect but this takes active harmful effort as opposed to just sharing your post around all the vanilla instances you blocked, which makes a huge difference (no more shadow threads of fash replying to eachother under your posts, unbeknownst to you).

If an instance is actively circumventing stuff like this there's infinite other ways to do so as well.

@charlag @val There is a strategy in information security called Defense in Depth. No mitigation will be perfect. Instead we seek to add security controls that layer on top of each other to add the most benefit while keep us as safe as possible. Which mitigations an individual or org should use depend on the risks those individuals/groups face.

@val @charlag and yet turning authorized_fetch on dropped my moderation load from a few reports a week to basically zero

don't let the perfect be the enemy of the good

@val @charlag 'get around the block by pretending to be a new instance'

The only way they can do that is if they actually really create a new instance at a new domain and register the dns and everything. Or they create the new domain and just have something on it forwarding messages to their old domain 🤔 which is basically the same thing. The expense and pain in the arse of deploying on a new domain makes this impractical imo

Mastodon PSA, mostly for admins 

@charlag
This mode sadly has some pretty annoying problems coming with it...
It for example completely breaks reply-flows (I follow someone on another server, someone from another server with this enabled replies, I can't see the reply unless I already directly federate with the instance of the person replying).
I'd like it to be default but the downsides severely outweigh the upsides as it stands right now and it needs a lot of work until this isn't true anymore

Mastodon PSA, mostly for admins 

@jakob doesn't op instnace just send a Create without Object which you need to dereference with a key?

Mastodon PSA, mostly for admins 

@charlag as far as I know this is not the case. I'm not really into the mastodon codebase but I followed a issue about this a few months ago (which is why the docs have a yellow warning banner for this config option) and I don't think it has been changed since.
It would be nice if this would work and would make conversations way more complete but as far as I can tell, all instances with auth fetch that I don't yet federate with are missing in threads I read :<

Mastodon PSA, mostly for admins 

@charlag also I like to link funny or interesting public toots to people without a mastodon account which does not work with auth fetch enabled (and even with mastodon account this gets annoying as soon as this person is not on the same instance as me)

Mastodon PSA, mostly for admins 

@charlag for thos last point (impossible to create public http links to public toots) it could be that I'm confusing this with the auth fetch equivalent with pleroma but I think this also happens with mastodon auth fetch

Mastodon PSA, mostly for admins 

@jakob if the post if public HTML is still there, same for in-app stuff

Mastodon PSA, mostly for admins 

@charlag ah ok yeah than im confusing this specific thing with the pleroma equivalent of auth fetch

re: Mastodon PSA, mostly for admins 

@charlag Does this exist for pleroma as well ?

re: Mastodon PSA, mostly for admins 

@eragon first of all, I don't give a shit about pleroma for a long time, second, yes

Mastodon PSA, mostly for admins 

@charlag Why does it prevent scaling? Can we authorised fetch from multiple instances of masto? Or? What's the issue? IDK will look myself :P Thanks for the headsup. I'll look about this on our server now since we aren't scaling yet.

Mastodon PSA, mostly for admins 

@ikora @charlag it doesn't necessarily prevent scaling per se, but every new instance that sees a boost of a toot has to contact back to your instance to get the content, resulting in more traffic than without (where the full toot is shared anywhere without involving the original server again).

Either way the security improvements heavily outweigh this, and if your instance is big enough for this to really be a problem you've got other issues too..

But it shows why Gargron won't just enable this by default, since scaling to the max is more important than security

Mastodon PSA, mostly for admins 

@f0x @ikora thanks, I missed the post. Yeah, instead of passing your post around every server will request the post but I think that this is no-issue. The only way around this would be encrypting everything and rotating keys.

Mastodon PSA, mostly for admins 

@charlag I really wouldn't enable this. First, it potentially breaks compatibility with non-Mastodon servers, such as #bookwyrm, #GoToSocial, #WriteFreely, etc.

It increases server load, because the original server has to be contacted when passing around any activitypub message, due to a lack of linked-data signatures.

Even though an instance will stop seeing public toots (which also defeats the point of public toots IMHO), one can still see them through any web browser, e.g. from the same instance where the toot was posted.

Knowing all this, plus the fact that toot visibility is not guaranteed for everyone, which is especially important in a thread where missing out on a toot could be an issue, I really don't think that enabling this is worth it. If anything, it's splitting the whole ecosystem into the fediverse and privileged instances within, who enable this feature.

Please think about this before you enable anything.

Mastodon PSA, mostly for admins 

@erion wtf you talking about, GtS *always* supported it. Kibou (trash server in Rust I was digging in) also did. If we can, anyone can.

Seeing how you say "also defeats the point of public toots" you either don't understand the problem at all or you don't understand how it works.

Also especially spicy to hear how Pleroma user asks to not enable it.

Mastodon PSA, mostly for admins 

@charlag GoToSocial, to my knowledge does not have a config option, nor supports this feature.

Kibou is irrelevant. My point was not about who can or can't add this feature, but how many servers, right now, support it. Everyone is entitled to an informed decision, and so are you to your opinion, which has drawbacks, other than the ones you mentioned, hence my reply. If you wouldn't like to be informed about it, good for you, please move on.

Of course the fact that you seem to put every Pleroma user under one umbrella and needlessly bring it into this discussion shows just how much you care really.

Mastodon PSA, mostly for admins 

@erion this shows how much I care about Pleroma, yes.
Gts always enforces signatures, ask tobi. My point wasn't "oh look how many servers have it" but "this is mot hard to implement". And since you already made mistake about gts I can't trust you on knowing it correctly for other servers. Some servers have it for years and if someone cared they would implemented it. Otherwise sure, let's never add any security.

Mastodon PSA, mostly for admins 

@charlag @erion gts uses authorized fetch / http signatures by default and they can't be turned off (not currently at least): that's why there's no config option for it

Mastodon PSA, mostly for admins 

@dumpsterqueer @charlag This is good to know, thank you!

Mastodon PSA, mostly for admins 

@charlag I personally think that you have a very simplistic view of this, and of people who use Pleroma for that matter, but I'm not here to change your opinion nor am I going to ask you to trust me.

If GTS has it enforced, then even better, I can cross off one server from my unsupported servers list.

You are absolutely right, this feature is not hard to implement, and I bet you anything that if everyone enabled it, lots of servers would end up implementing it, but that doesn't solve the issue that if you enable this feature, the number of people you can reach will be limited for now.

re: Mastodon PSA, mostly for admins 

@charlag i mean this mode is cool, but i had to disable it on my instance, because some apis were broken afterwards

re: Mastodon PSA, mostly for admins 

@koyuchan what APIs were broken?

re: Mastodon PSA, mostly for admins 

@charlag if i remember correctly it were things like fetching public data like profiles, timelines, instance info etc.

re: Mastodon PSA, mostly for admins 

@koyuchan yeah you need to be authenticated to do that, that's kind of the whole point

@charlag but can't I just get your posts from your public feed? or a silent stealth instance? if I'm a motivated asshole?

Aren't you just breaking relays for no gain?

@silverwizard I answered all of it in replies. First of all, I want you to realize that you are not a person who needs protection so you don't see a benefit of it but it doesn't mean there isn't one.
You can't "just get posts from public feed", you need to authenticate. Stealth instance is not a realistic scenario: it needs a lot of effort to set up and it's easy to block.

@charlag I am not sure the effort level to setup, I have setup an instance in 10 minutes during a talk

I want you to understand I don't want people who need protection to be lied to about the safety of a space

@silverwizard and it will take me 5 seconds to block it

What's a lie: "if you block an instance it will not really block it" like it is without auth or "if you block an instance they might set up another instance that you didn't block" which is true regardless?

I am tired of saying the same things to white men under this post. Their position is "if you need safety you should not go online ever" without fault

Sign in to participate in the conversation
birb site

This is a tiny, friendly fedi server!