[00:43:57] that too :p [00:44:05] I'm bringing up the 32-bit thing because of https://phabricator.wikimedia.org/T324489 [00:44:31] https://pingback.wmflabs.org/#server-machine-architecture/server-machine-architecture-32-bit-or-64-bit-timeseries [00:46:01] less than 3% if I'm doing the math right [00:48:09] heh, there are more 32-bit users than postgres users [00:48:58] yeah, 2.69% [00:49:35] nice [00:50:08] (I can only assume going to 3 sig figs was for purposes of the obligatory comment) [00:59:31] and here I typed out "less than" to avoid a literal <3 :p [12:49:00] Does someone have a better idea for forwarding PROXY_USER through an apache reverse proxy? [12:49:02] https://serverfault.com/questions/180726/remote-user-through-apache-reverse-proxy [12:49:26] With this rule Special:RecentChanges fails to load for some reason :( [14:18:37] uhhh... some russkii botnet is really demonstrating that passing ReCAPTCHA is no problem for it these days. Time to switch to hCaptcha, right? [14:34:31] Anyone have any idea why editing a page and hitting preview suddenly thinks that the links to the article itself are redlinks? Exhibits here: https://stop-synthetic-filth.org/wiki/Synthetic_human-like_fakes [14:41:48] usual behavior is to boldface the links to self [16:08:56] I edited the page and now the links to self are redlinks in the saved version. Clicking on them renders the same page as it should be, but just the page thinks itself is nonexistent. Any advice please? [16:11:39] Something is broken there. However, playing with the action=parse api I'm unable to reproduce the issue on your wiki [16:47:02] some cache issue perhaps? [16:56:23] Vulpix: could you please try to edit the page and then preview and save it without changing anything, this seems to change the situation in a tick-tock manner for me [17:10:09] Iamthehuman1: ConfirmEdit + QuestyCaptcha is the general recommendation, I think [17:10:34] with the challenge question picked from your wiki's content/topic area [17:11:18] Dinoguy10003726[: Ohh? I would not trust that in a post-GPT-3-world [17:11:53] I agree in principle [17:12:16] in practice, we've been using it on our million-views-a-month wiki since 2017 and haven't had trouble once [17:12:17] But then again passing ReCAPTCHA is probably available as a service if someone's botnet can't hack it by themselves [17:12:54] I'm sure that won't last forever, of course, but all the general-purpose captchas are going to be broken long before any concerted effort to break the domain-specific ones in general [17:13:39] you have a point... the ones having most use cases are going to receive the most attention to crack 'em [17:13:49] yes [17:17:17] hCaptcha is much tougher, at least for a human, at the default medium-strength/difficulty setting, plus I can donate the "proceeds", which is half a penny per millenium, to the Foundation [17:20:05] I'm thinking I could just try banning the botnet's IP's and see if it runs out, but priority is to figure out why the Stop Synthetic Filth! wiki is being slightly broken-ish [17:20:40] QuestyCaptcha is the strongest one for now, until bot authors decide to feed questions to an AI to resolve them :P [17:23:12] yeah, you'll probably want to track effectiveness of QuestyCaptcha so that you can rotate questions if they get stored somewhere [17:23:54] This spamposting botnet probably just letting me know it is there and could theoretically shitpost tons and tons. Probably just a bit of poking on the ice, if I will panic and close the wiki so that any human with a device and an internet connection can edit it [17:24:49] QuestyCaptcha is also the best CAPTCHA for accessability [17:25:46] AntiComposite: hCaptcha has a bypass token/cookie for people with disabilities. I hope no-one tries to abuse that system [17:26:01] it is very abusable, and also not very accessable [17:26:25] sorry to hear that [17:54:18] hCaptcha on ConfirmEdit was already bypassed a year ago. I have 10+ spam bot account creation per day at least [18:06:50] AntiComposite: we need the xkcd captcha [18:10:17] Talking about Captcha, would anyone with Jenkins bot permission mind to run the test? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/539679/ [18:10:37] The failure log was so ancient that I couldn't locate the issue [19:52:20] atxatx4928[m]: done, that list is fairly open. You should be able to create a PS to add yourself [19:52:34] And someone will review fairly quick [20:20:10] hi [20:21:07] hi [20:42:28] Thanks for running it and the pointers! I'll check it [20:46:17] Ah I'm actually on the list my bad [21:54:32] Vulpix: the nature of QuestyCaptcha means spammers would need access to a much stronger/more sophisticated/more general AI than any currently available to automatically break [21:55:24] its vulnerability is spammers breaking the question by hand and adding it to their spam bot/script, and that's always gonna be a much harder sell than just sticking to wikis using a general-purpose, already broken captcha [21:56:32] basically, unless someone figures out a way to bypass QuestyCaptcha completely, attacks are realistically going to be limited to wikis being specifically chosen and targeted for some reason (and that reason probably will be pure disruption far more than spamming) [22:06:46] ofc it's completely vulnerable to the human-as-a-service services, but all captchas are [22:26:21] We use FlexForm and it's Google recaptcha for our main websites. It's set to a score of .5. even if a legate person tries to contact us they get a message that we presume their email is malicious by Google recaptcha. They usually the contact us by phone or email directly. [22:26:21] But spam mails are this way very limited [22:26:53] s/the/then/ [22:27:26] you probably lose a lot of legitimate editors that way, tbh [22:27:57] but I'm sure you've done that value calculation and decided it's acceptable versus the alternative