[00:22:50] I keep forgetting that [09:04:26] guys guys [09:04:55] community portal page on meta [09:04:59] blocked the IP already [09:05:52] and also the Steward requests pages [09:07:44] the user was https://meta.miraheze.org/wiki/Special:Contributions/94.231.180.28 [09:08:02] looks very similar to this one PB blocked a little bit ago [09:08:03] https://meta.miraheze.org/wiki/Special:Contributions/178.137.91.228 [09:18:01] its 2 am im going to sleep, but if anybody could ping stewards to global lock the 94.231 IP that'd be nice [09:22:16] i'll ping @CVT for ya [09:22:21] thank you [11:24:46] @crystalite13 IPs (as far as I know) cannot be globally locked, unless you meant to say globally block. [11:30:08] [This IP editor](https://meta.miraheze.org/wiki/Special:Contributions/94.231.178.69) has also just vandalized, but I've taken care of it. [11:53:34] issued block should stall relevant vandalism until another range is found anyway [12:40:29] Alright then. Thanks for handling that as well. [13:07:07] [1/8] cc @justanotherdarkmodeuser for educational interest and for any other, in this case a toolforge check did not offer an immediately useful cidr in the space it is usually expected, and the immediate assignment appears to be more narrow /24. But there was an IP outside of that, so that must not have been it, especially when both resolve to the same provider. Yet on the third octet, th [13:07:07] [2/8] e range was only off by 2, and viewing the ip contributions with /16 applied to the end confirmed this, so /16 is certainly too broad. In CU in order to minimize collateral however, its not usually wise to check the CU to confirm this because it is private information. [13:07:07] [3/8] So instead further down in toolforge is a more plain cidr field. Usually this is too broad but in this case it was a /20. This is a more reasonable range to hit and collateral is likely low. While the problem has come from multiple russian providers, you might observe there have been vandals from completely different ranges a /16, our most reasonably blockable/checkable range, cannot [13:07:08] [4/8] cover. At this point unless you can get a full provider's range you are kind of out of luck. [13:07:08] [5/8] But in fact there is one tool that can help. It's not perfectly accurate but can provide insight: [13:07:08] [6/8] https://isprangefinder.toolforge.org/hint.php?type=asn&range=49183 [13:07:08] [7/8] This tool will take the ASN, whch you can find on the lookup link as well, and give you what it figures are associated IP ranges. For IP vandalism, simply looking up those directly in contributions could be useful to find corroboration. For CU purposes this is sometimes useful and can be a cross refernece in case someone bounces around a lot. [13:07:09] [8/8] There are many more considerations of course (CGNAT, providers like T-Mobile mucking things up) but so far they've been fed chunk at a time and I haven't fed you one in a while, so [17:08:52] hmm, can tech block vandals that use ranges that /16 can't cover [17:09:14] it would be annoying if they were able to come back again and again [17:09:58] unless it also mixes in regular users..which wouldn't be ideal, but if worst comes to worst then they could be able to apply for ip exemption no? [17:12:15] [1/2] huh, this is interesting [17:12:16] [2/2] https://cdn.discordapp.com/attachments/443926951292567562/1531710896236265654/FF48375E-9CED-4168-83FF-D4B18EEE1B3E.png?ex=6a6a346f&is=6a68e2ef&hm=d87fb3e0990d7e78c9a59e57ab87d2f0d730b0b2f599c58feb561de4c0623ad2& [17:13:09] @justanotherdarkmodeuser: how do you mean? `/16` is the largest range that can be blocked on-wiki [17:13:40] Tech should not be making blocks for counter vandalism [17:13:47] Exactly. [17:13:55] yeah i know but is it technically possible... [17:14:13] There's no reason fro them to have the rights [17:14:28] There are very rare cases where Tech should be taking action against users [17:14:34] where do i get library of babel mod😨 [17:14:41] wrong server [17:14:48] oh [17:14:48] ok [17:14:48] google the mod [17:15:00] i cant find it for some reason [17:15:06] i am [17:15:25] should be in steam workshop i assume, please go to #offtopic if you wish to discuss [17:17:46] There are also cache proxy server-level 'bans' that can be enforced by the Technology Team ([[Tech:Varnish#One-off purges (bans)]], but these are used in extremely limited, technical circumstances (i.e., not counter-vandalism as PixlDev) said above [17:17:46] https://meta.miraheze.org/wiki/Tech:Varnish#One-off_purges_(bans) [17:19:23] :Sippy: [17:19:38] Need me a CheckUser 121 clas [17:28:46] the fact is once you go larger than /16 the collateral range that is possible becomes so large that ip really is no longer a tool of deterrence and you are better off with other options, chiefly what can be done with abuse filters to strike the problem [17:29:14] reminds me of the gap tali used to fill... [17:33:07] [1/2] as far as what tech can or will do, this is a point that massively diverges from oasis; zippy, also being a steward, has access to out of wiki information unavailable to stewards in general. The informality there makes it more plausible for him to then use that access for investigating and addressing abuse, while the separation as well as policies on privacy are much stricter on mira [17:33:07] [2/2] heze. However once in a while a tech-steward or even collaboration between a steward and a member of tech has been used to explore unusual options (doug suggested one example), and these reservations would not exist in the event we forward illegal activities for further action. Tech also has some leeway in taking actions to immediately halt things that compromise the platform [17:36:52] That’s what I mean, [17:39:18] Yep. It's essential to have good cross-team coordination between Stewards, Tech Team, and Trust and Safety [17:39:27] dmehus: varnish bans have nothing to do with individuals [17:39:36] A varnish ban is just deleting a page from the cache [17:39:44] RhinosF1: I don't think I said that? [17:39:53] We can block users at the edge (we'd normally do it through Cloudflare) and will if needed [17:39:59] But generally not for on wiki issues [17:40:23] More for excessive traffic or trying to break into our servers [17:40:29] dmehus: just for clarity [17:40:33] your link referred to the varnish page which is not something that really applies to individual abuse [17:40:40] Sorry if I linked the wrong section of the page. The latter was what I was referring to. Thank you for the clarity [17:40:57] What you linked has nothing to do with individual abuse [17:41:12] And we use not all the time but fairly often [17:41:18] Yeah, sorry I wasn't trying to say it's for individual abuse [17:41:30] We can and do block people for abuse from the tech side [17:41:35] it seems to me more for select technical circumstances and the rhinos example of a cloudflare-routed block would be more likely in context of unusual action for cvt [17:41:49] I was thinking specifically to cases like a DDoS attack or an excessive amount of traffic [17:42:00] and then tech separately also has its tricks for server abuse, attempted penetration and such [17:42:11] When did we add Cloudflare to our teck stack? [17:42:19] its been part for a while [17:42:21] That might be a change since my previous time [17:42:26] I want to say 2023? [17:42:29] and part of my confusion [17:42:33] maybe 22? [17:42:36] We blocked about 70% of traffic in the last 24 hours [17:42:42] So ye we absolutely do block people [17:42:55] yeah that's a whole game itself, majority of internet traffic is just bots [17:43:03] yep, exactly [17:43:15] did you see that recent Cloudflare report on that? [17:43:22] (assuming you probably did) [17:43:52] dmehus: I've read lots of Cloudflare things [17:43:58] Going to have to be more specific [17:44:21] https://blog.cloudflare.com/agentic-internet-bot-report/ [17:45:13] not looking forward to the age of ai enhanced ltas [17:45:29] On a normal day it's about 18% of traffic we block [17:45:34] But today has not been normal [17:46:44] wow [17:46:50] dmehus: we've had Cloudflare for a while, it became the only way to deal with abuse / AI scrapers [17:47:05] RhinosF1: makes sense [17:47:40] I have not read that specific article, no [17:48:10] Some publishers are starting to even consider disallowing Google's search crawler from indexing their websites, to negotiate a licensing deal. That may be the new model. Google pays for access to content, since publishers no longer see traffic they once did from Google [17:49:14] Google are not blocked [17:49:23] Some search engines and AI tools have been blocked [17:49:52] Oh, you mean on Miraheze, yeah. That's a good point. I just meant like The New York Times and other content publishers [18:15:52] We've already had one or two. 😭 I am equally concerned about this stupid, stupid future [18:16:29] yeah... [18:17:36] Contemporary luddite groups are starting to emerge on college and university campuses, https://theconversation.com/digital-luddites-are-rising-they-want-to-democratise-tech-not-destroy-it-251155 [18:19:27] this is probably better suited for offtoppic at this point [18:25:19] definitely [18:39:52] ✅ [19:26:46] Also not too far afield from the goals of the original Luddite movement once you peel back the caricature. [22:23:28] `On metawiki Abuse filter blocked [[User:Imperadorbraulio]] with an expiration time of 3 months (account creation disabled, cannot edit own talk page): Automatically blocked by abuse filter. Description of matched rule: Anti-LTA filter #2 (Nonciclopedia LTA); https://meta.miraheze.org/wiki/Special:Log/block` [22:23:28] https://meta.miraheze.org/wiki/User:Imperadorbraulio [22:23:28] @orduin if you're around, that abuse filter hit seems to be a false positive based on the cross-wiki activity of that user. Filter may need some tweaking [22:37:03] hmm [22:37:46] I wont unblock as their crosswiki activity and the edit that triggered the filter is suspect [22:37:59] seems like they are spamming xwiki [22:41:39] So... seems legitimate then [22:47:37] I disagree, I don't see 'spam' on the other wiki. [22:48:02] but I'm not sure what the abusefilter on Meta looked like [22:49:30] edit triggering abusefilter on Meta* rather [22:49:42] [1/2] its quite clearly spam [22:49:42] [2/2] https://cdn.discordapp.com/attachments/443926951292567562/1531795816400949529/image.png?ex=6a6a8386&is=6a693206&hm=3d0505c256a1fc1223b1211336e706db9b935385c86f56c81e611cab2c980eb5& [22:50:01] Given the emails to cvt/stewards by this same individual, this is a legitimate block that should remain in place [22:51:42] Disagree on the 'spam' (perhaps my definition is looser than yours). But in regards to @notaracham's comment, sounds good then. :)