Some high profile instances were added to the blocklist alongside unrelated changes and not mentioned in the git commit message… Also apparently the error you’d get when going to the blocked instance was a generic error…
Yeah, the combination of those two issues are exactly why the hidden blocklist was noticed in the first place. The site admin for db0 noticed that their frontend was broken after they updated their Lemmy stack. But the “incompatible” version of Lemmy they had just updated to was supported. So what was causing the incompatibility? Maybe an API issue? Nope, API is fine.
After some digging, they eventually realized that it was happening due to an instance block at the frontend’s level. But they didn’t have their own instance blocked in the frontend, so why was it being blocked? Turns out, it was because they were previously running an old version of Tesseract from before the blocklist was implemented. When they updated their stack (which also updated Tesseract), the new version suddenly included the hidden blocklist code. So when they tried to start their stack after updating, the new version of Tesseract quietly downloaded the hidden blocklist (which can’t be disabled) and blocked the instance it was currently running on. This effectively broke the frontend for db0, which is what led to the investigation and subsequent hidden blocklist discovery.
And that’s a large part of the issue. The frontend doesn’t actually disclose this blocklist at all. In fact, it actively takes steps to obfuscate things and make it appear as if the blocklist doesn’t exist at all.
For example, attempting to view a blocked instance shows a generic network error, rather than a “this instance is being blocked by your frontend” error. And blocked users aren’t simply flagged and/or collapsed. They’re entirely hidden, as if they don’t exist at all. So someone using this as their primary frontend wouldn’t even know that they’re missing entire posts and/or comment chains, because anything from the blocked users is simply gone.
Additionally, the blocklist is downloaded (in plaintext, over http) when the frontend is booted, so it’s not a file that gets updated with the git version updates. Meaning the dev can silently update it even if users haven’t pulled new versions. Simply rebooting your frontend would be enough to pull an updated blocklist. This gives the dev an extreme amount of censorship power, because they can effectively change users’ configs without any action on the users’ part.
It was only originally discovered because the admin for db0 used the frontend. And notably, db0 is on the block list. They were previously using an old version of the frontend that didn’t include the hidden blocklist yet. They updated their Lemmy stack a little while ago, and suddenly their entire frontend was broken (the entire feed was completely empty) and showing a generic version incompatibility error.
After lots of troubleshooting, the db0 admin eventually discovered that the frontend was downloading a hidden blocklist and automatically blocking the instance that it was running on. Because when they updated their stack, the new version of Tesseract included the secret blocklist. So it downloaded the blocklist when it booted up, found that db0 was on the list, and silently hid every single post because they were all from a blocked instance. This resulted in a completely empty feed.