The API they most probably used to collect public toots can be disabled since 3.0 by unchecking “Allow unauthenticated access to public timeline” in your instance's Site settings
@Thib remember when Eugen and a bunch of other ppl were adamant that this was absolutely impossible and those of us who wanted it were just hysterical bitches? Good times
@SelfsameSynonym that is absolutely not what I remember you were requesting (but this API should have been restricted way earlier anyway)
@SelfsameSynonym what I remember you requesting was that blocked instances should be unable to access your public toots
To deal with that, a mode called AUTHORIZED_FETCH has been implemented, which requires remote servers to identify themselves to fetch toots. This has many drawbacks and can be easily bypassed, but it prevents unmodified fediverse software from seeing those toots. It is also the basis for the whitelist mode (which is unfortunately broken in the current release)
@Thib fetch authentication is what people were adamant was impossible. I was hardly the only one asking for it and the specific use case is irrelevant.
This was an “impossible” feature until a large university asked Eugen for it and it suddenly became doable and was released without documentation on how to use it. You can pretend the API is a separate issue, but it’s related and is just another example of how the implementation of basic security features was ignored or broken because, as has been repeatedly demonstrated, no one with the time and ability to develop features for Mastodon actually cares about whether they’re done right if at all.
Similarly irrelevant is that it can be bypassed since the point has never to be 100% secure, but to make it harder for bad actors to access timelines they’ve been blocked from. It’s also wasn’t surprising to find out a while ago that the implementation is broken because the implementation of almost everything in Mastodon is broken. If developing a perfect feature that always works in 100% of cases was an actual dev concern, nothing would ever be built. It’s just an excuse that’s given for work that people don’t want to do
@SelfsameSynonym I implemented most of fetch authentication and I stand by what I say when I say it's very easily bypassable, and so doesn't fully solve the impossible problem of preventing some instances from seeing your toots
What I was wrong about though, is that I overestimated the performance cost of such a feature (there are significant performance implications to this, but I thought they were prohibitive, when they are not)
@Thib if you implemented it, then maybe you can answer a question I’ve had on it, which is why the authentication requirement doesn’t extend to an instance’s “public” timeline
Does plugging that hole on the API fix this as well?
@SelfsameSynonym hm, I'd have to check the code to answer that, as my plan for AUTHORIZED_FETCH mode was to only affect ActivityPub endpoints and not the client API, but Gargron has tied a few client API restrictions to AUTHORIZED_FETCH mode (or only whitelist mode?). I'll tell you tomorrow.
In any case, the public timeline API is part of the client API, and required to display the public timeline when not logged in, as offered on the about page. Both the API and the offer to “see what's happening” are controlled by the same setting. That wasn't always the case, though, it used to be available without authentication even when not offered on the about page. Some people thought it was valuable. And for a time we thought about having two different settings, but we decided to just tie the two things together.
AUTHORIZED_FETCH mode and client API
@SelfsameSynonym yeah, that wasn't my original idea (but in the absence of a way to require authentication for the API, it's a good thing) but the authorized_fetch mode also disable unauthenticated use of the client API except for:
- showing instance info, activity and peers (if otherwise enabled)
- registering client applications
- creating accounts from the API
- showing keybase proofs
@Thib won't that also prevent sharing public toots with people who aren't on mastodon, such as dropping a link in a chat? I mean, should be done even if so, but that's really unfortunate.
@polyplacophora no, that's for disabling the public timeline preview, not for disallowing access to public toots
@Thib ah, that's good. No reason not to, then.
@polyplacophora well, you lose the public timeline preview, if you think that's useful
@Thib true, but I think it's less important at least
@Thib and there’s the killer app for v3
@Thib Why isn't that auto set to ON?
@maverynthia because the default is to offer a preview of the public timeline offered on the landing page, and that obviously can't work if the API require authentication
@Thib That was something that shouldn't have been a thing in the first place.
This is a small personal instance running on a couple small ARM servers at home.