Well, I got my first white supremacist reply from the fediverse after posting an article about Elon from Flipboard.
I reported and blocked the account. I also looked at the instance admin's account and it's clear he's also a white supremacist. So that instance will be blocked on flipboard.com and flipboard.social as well as shared with other instance admins as a problematic instance for them to take action if they also deem appropriate. Took all of 2 minutes to help make the fediverse a bit better for everyone.
And the best thing is that anyone in the fediverse can do this too. Decentralized moderation FTW.
@mike While this is certainly a great thing, I'm not sure whether or not we also need a method to be able to get off those #blocklists in case the blocked instance gets fixed somehow or when there's a misunderstanding in the first place. 🤔
I am currently designing a small toy-language and was considering making all strings proper #Unicode objects and all source files utf-8. Lo and behold, Unicode has recently published some guidance: #TR55http://www.unicode.org/reports/tr55/ I am, however, rather deeply concerned about the general strong preference for #blocklists over #allowlist, e.g. as recommended for identifiers. I get wanting to allow people to use their own language and script wherever possible, and therefore recommending switching from e.g. requiring type names to start with an upper-case character to blocking an initial lower-case character, thereby allowing the use of unicameral (without upper and lower case) scripts. But I have this deep gut-feeling that while the TR certainly solves some existing #vulnerability classes, it also opens up a huge amount of new ones with this general attitude. I haven't yet gone through the TR with a fine-toothed comb to allay that fear, but I'd appreciate input from anyone that has thoughts on the matter.
The Associated Press just served me an ad for fake anti-virus. The entire page was taken over, and forwarded to the malicious site, within seconds of opening the news article, every time.
An ad blocker isn't just something to hide some annoying eyesores, it's a vital layer of security.
If you have friends or family who might fall for fake AV or "windows technical the department" scams, they need an ad blocker. No site they visit can be considered "safe" unless it simply doesn't have ads.
Instead of using an #intransparent#blocklist that is maintained by people more unwilling than unable to accept valid criticism and reflect upon it, consider choosing one that is #tranpsarent and that is actively maintained by people that #DoBetter!
One of the things about scoring algorithms is that they are prone to bias from a lot of sources you don't think about unless you actually work in this space.
For example, with blocklists, let's say you have five trusted sources and you use a majority evaluation.
You use your fancy trusted sources and you have created an evaluation on a particular entity $foo.
But you also chose the criteria and the sources that led you there. You can't pretend that your evaluation is "fair" just because it met some set of arbitrary criteria that you decided.
Similarly, if you are standing by your decision, what happens when your decisions change as the result of your trusted sources changing?
It is, without a doubt, true that the #fediverse is unsafe for a lot of marginalized groups in a variety of ways.
It is unsafe even for groups that are overrepresented here compared to society at large, such as for queers.
It is also true that the fediverse needs a multipronged, multi_layered_ approach to these issues
#Blocklists are necessary and vital, but I'm not convinced that consensus blocklists nor rapidly updating blocklists are the answer, or even have a place.
We also have a feature that's basically unique to the #fediverse with #blocklists that are run here:
The permanent severing of connections without notice for groups of mostly uninvolved people.
This is simply a bad practice and it demands more attention—and criticism—of blocklist patterns than we would have otherwise. Even ones that have historically been safe or might be safe in the future.
If blocklists didn't sever connections then automatic updating would not be nearly as bad.
Puh, a really controversial topic that seems to cause strong emotions by many people on Mastodon.
I am not one of the big fish involved in the discussion. But I think it is important because how our community interacts depends on ourselves.
First, I want to say that shared blockslists can make sense. Basic lists to filter out the really bad shit. And maybe some stricter versions with keywords to facilitate new instances the creation of a safe space for certain groups (ok, here we could discuss why not blocking ALL kinds of harrassment, but in practice -and in the spirit of the fediverse as a community of distinct, but federated instaces- different people have varying levels of tolerance and set the threshold differently).
Currently, I see many posts about TBS, both in favour and against. Here I wanted to share my thoughts about TBS. I see basically the following problems:
The trusted instances are hard-coded and not independent from each other (correct me, if I am wrong). I think that a lot of controversy about TBS comes from concerns about the influence of one of the persons at mastodon.art, both directly because they are used as trusted source but also because of indirect influence on the other instances via their moderation-discord channel. Everywhere are power dynamics. Also informal hierarchies don’t disappear if we don’t call them out.
There is no appealing mechanism (TBS-banned instances would need to go begging on their knees to the “trusted instances” power circle). There is usually no “defederation will last for 6 months” or similar.
There is no mechanism to resolve the issue of binarity of defederation: It is the nuke of moderation tools. However, the problem is that there are no intermediate tools to separate real nazi/pedo shit from “many months ago there was a disagreement regarding moderation style”. TBS was announced to be for the really bad stuff, not for more controversial/personal decisions.
Blocklists are a huge responsibility. It is really easy to fuck things up (on purpose and by accident), especially if the blocklists are widely adopted. It is crucial to have very, very good mechanisms in place to avoid power issues. Therefore it is important to be open to (constructive) criticism.
Just to try out, I looked how kolektiva.social (the lovely anarchist instance I call my home for almost a year now) scores on TBS. Currently, kolektiva.social is suspended by 4 and silenced/limited by 2 of the “trusted instances serving as reference for the The TBS blocklist. If TBS would be widely dopted by the fediverse, this would mean adiós to my beloved instance* 😢
I have to admit that I lost a little bit of track of the multiple blocklist projects:
Pesonally, I see Fediseer as a promising project. It has the optionto select the instances you “trust” and get their blocklists. It is really not necessary (and inefficient) that the mods of every of the 10-20 k Mastodon instances have to dive through all the really, really bad places to block them. There is still the issue of structural power dynamics of the instances that are used by default, but I understand that you have to begin somewhere and with the really, really bad instances, there should be less of a controversy.
However, seeing the current heat of the debate, it is important for me to make also the following statement: The level of harassment and personal attacks that the person most visible behind TBS ( @Are0h ) is receiving from many sides is totally out of place. There are unclear power dynamics that should be addressed. Maybe this person is not the best at taking criticism, but a human being enjoying some privileges while suffering also discrimination. And also yes, Mastodon has definitevely a whiteness problem (and harassing a prominent black person provides exactly their point). Listen to black people when they talk about discrimination. Listen to queer people when they talk about discrimination.
But please, folks. Try to take a few breaths before writing an outrage post. Destructive group dynamics don’t seem to be what we need to resolve our problems. Maybe some of you will hate me for this. My apologies. I don't want to dismissing your experience, but to bring us back to the table to find ways to first keep the really bad shit out while trying to make the fediverse a more welcoming place for all.
sorry for the hippie speech. English is not my first language, s
Of course, a very valid question is also: why is kolektiva.social considered by such a considerable proportion of the set of instances that some people consider “trusted sources” as worth of being defederated because of “Moderation issues, Poor moderation, abusive/harrassment behaviour” (on mastodon.art’s ‘about’ page even “racism”). I recall a complex conflict last year. However, whether kolektiva.social is currently a place for abusers/racists, is not really an assessment that can o should be made by a privileged white person like me, I guess.
Really I think there need to be a set of tools that exist between #blocklists and admins and users, and between admins and users in turn
#Mastodon seems to be somewhere between uninterested in fixing these problems and "it's on the roadmap but with no visible work in progress" on fixing these problems. Yet mastodon is around 80% of the installed base. So that leaves a few possibilities that allow for easy incremental progress, but none that allow for complete solutions without a lot more.
When it comes to #blocklists we should probably at some point talk about soft pressure, conflicts of interest, and why/how "$Foo didn't make the decision [directly]" doesn't mean that $Foo did not, in fact, have a role to play in the decision.
If I want to truly claim third party independence in my hypothetical #blocklist, it means something significantly more than "I am not directly making decisions for the blocklist."
I do not accept the logic of "it appears in <#blocklist $foo> therefore it is a bad instance."
That to me reverses the question: It is treating the blocklist as determinative.
Rather the question should be reversed: an instance is added to the blocklist $foo because someone has made a determination that it is a bad instance for some documented value of bad.
But I'm seeing a lot of "it is in the list, therefore it is presumptive that they did something wrong."
Because it goes to the heart of one of the core failure modes of consensus-based #blocklists.
If services A-E coordinate on a #blocklist and import their own blocklist because the blocklist is determinative then they will propagate the decisions regardless of accuracy. There's nothing to stop bad reports because the decisionmakers are relying on the output to make a determination and then feeding that back into the system.
#Blocklists have a long, long history of being deliberately weaponized against the trans community in the name of "protecting marginalized groups" (including, but not limited to, trans people).
Not listening to that history of harm and refusing to address it after problems are pointed out is, in and of itself, a furtherance of that harm
This doesn't mean that they are automatically bad, nor does it mean you must fix every objection that's brought up. It does mean you need a story, however.
We should probably at some point have a conversation about how fediblock creates false consensus in downstream shared #blocklists and why that's a problem.
This doesn't mean that fediblock is in any way a bad thing or doesn't have its uses, but it means that your decisionmakers aren't independent of each other, and if you are running a consensus-based blocklist for others to consume that's a serious problem.
When a blocklist that didn't list its perspective on the issue upfront gets involved in an intracommunity dispute
Especially but not exclusively when people outside of a community get involved in intracommunity disputes
There's a fine line to walk on these issues generally—a lot of fine lines, actually, and a lot of nuance that I'm not going to get into right now—but the caution is that blocklists are very easy to weaponize here
One common comment is how there are "zero instances blocked by default now."
But it's worth examining why that is and looking again at the use case of that "default blocklist."
If your use case for a "default blocklist" is to block nazi and CSAM instances, do you need it updated every hour, or could you update it once per release?
If the problem is that people aren't uploading a blocklist, how is your tool going to be different?
Finally took some time to set up #piHole and it's fun to watch the number of blocked requests go up. I also put the #raspberryPi on its own UPS (a USB power bank).
@admin It seems that many people blindly trust the people and instances behind/powering these #blocklists too much and even defending/harassing people who criticize the problems of the users/instances behind the #blocklist