Conversation

Notices

1. Embed this notice
   Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:53 JST Tim W (admin (and human))

   in reply to

   • Hrefna (DHC)

   @hrefna And this is a way that shared blocklists with auto-updating are problematic even with "true positives" - if I as a server admin am going to block a server with which my users have meaningful connections, I want to think about it, and do it deliberately, and probably be extra transparent about it - not have an automatic update do it for me.

   • feld likes this.
   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:54 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna one reason for blocking entire servers with bad moderation policies is to influence change, and/or to cause the "good" users to go elsewhere.

     I think you're absolutely correct that it's a HORRIBLE tool for this right now with the way Fedi software currently exists and doesn't really make this visible, but it's the tool we have.

     And that's only a secondary purpose; the primary one is to prevent more harm. Who's to say there won't be 200 users tomorrow, with 105 of them being bad?

   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:55 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna to me, your example (100 user server, bad/no moderation, 5 bad users, 95 good ones) is not a false positive (or a 95% FP) on a shared blocklist with the intent of "keeping out poorly moderated servers".

     Those 95 good users are not false positives there. The server is the entity being listed, and it meets the criteria of the list.

     A false positive is if the blocklist includes a server that does not meet its published listing criteria. (cont)

   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:56 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna maybe I'm just arguing pointless semantics, I certainly don't INTEND to be doing so, but maybe I am. I just think the false positives vs collateral damage language difference is, in fact, important in this particular conversation.

   • Embed this notice
     Hrefna (DHC) (hrefna@hachyderm.io)'s status on Thursday, 14-Sep-2023 10:14:56 JST Hrefna (DHC)

     in reply to

     @tim I don't think they are _pointless_ semantics, rather that there may be shades of meaning, but let me flip the question a bit:

     What do you see as the core difference in this context?

   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:57 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna I feel like this thread of this discussion boils down to "there are, in fact, instances that are too big to block", and I feel like that's a distinct point / discussion from the original one that I'd prefer to see separated from the language of false positives.

   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:58 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna right, but you're changing the stakes here. We're not talking about classifying harassers. We're talking about classifying poorly moderated servers. Those are completely different problem domains.

   • Embed this notice
     Tim W (admin (and human)) (tim@union.place)'s status on Thursday, 14-Sep-2023 10:14:59 JST Tim W (admin (and human))

     in reply to

     • Hrefna (DHC)

     @hrefna I actually pretty strongly disagree with your characterization here (after agreeing with the first post on this thread).

     My users expect me to protect them from badly-run servers. Those 95 "good users" on the poorly / unmoderated server aren't false positives. They're collateral damage, but they're not false positives - they're people on a bad server.

   • Embed this notice
     Hrefna (DHC) (hrefna@hachyderm.io)'s status on Thursday, 14-Sep-2023 10:14:59 JST Hrefna (DHC)

     in reply to

     @tim If I write a classifier to detect harassers and it decides to block 100 people and 95 of them are not harassers, those 95 people are false positives because you _also_ have the option of blocking exactly five people.

     I'd view whether to call them "collateral damage" or "false positives" as more of a semantic debate: it's important, but it depends on how you define your classifier more than on the meat of the problem, if that makes sense.

   • Embed this notice
     Hrefna (DHC) (hrefna@hachyderm.io)'s status on Thursday, 14-Sep-2023 10:15:00 JST Hrefna (DHC)

     in reply to

     Now you are doing something on behalf of others.

     If an individual used a tool like, say, blocktogether and they were already following 3 people on the list, blocktogether would recognize the _follow_ (not just an approval) and not block them _for you_ while leaving them on the list.

     This sort of thing makes for a powerful mitigation tool. You can mitigate the harm to your social networks of false positives.

     But when your server admin makes that call for you your only recourse is to move.

   • Embed this notice
     Hrefna (DHC) (hrefna@hachyderm.io)'s status on Thursday, 14-Sep-2023 10:15:01 JST Hrefna (DHC)

     in reply to

     Two major points on this.

     First:

     If you block a server of 100 people because you are experiencing harassment from five people they won't moderate, that's really 95 failures, 95% false positives in terms of your blocking when looked at as a whole.

     That is the sort of calculus that as an individual you do every day and it is _very_ worth it on an individual level. Especially if you know 0/95 people. Block away! Block together! Share the #blocklists!

     But when you are talking about a server?

   • Embed this notice
     Hrefna (DHC) (hrefna@hachyderm.io)'s status on Thursday, 14-Sep-2023 10:15:02 JST Hrefna (DHC)

     The thing about #blocklists with false positives versus negatives:

     I'm generally for optimizing for the false negative rate _but_ with a few caveats.

     1. False positives should be bounded.
     2. There needs to be a way to get off the list
     3. When mistakes happen there needs to be a revocation process that is propagated automatically
     4. This is for _individual_ blocklists. If you are blocking on behalf of _others_ or sharing your blocklist the calculus here changes and false positives _matter_