In T303774#7775964, @MZMcBride wrote:

Likely related: https://meta.wikimedia.org/wiki/Grants:Project/Rapid/GeneralNotability/Bullseye.

Confirming that it's inconsistent - I've done CreateLocalAccount several times today and it's only triggered once.

Confirmed, just got a wave of emails.

If you all need a CU to test/provide feedback, I would be happy to volunteer!

Thanks @Legoktm, I wasn't aware of that, will give it a try. I don't think it'll solve all the problems without a major overhaul of my code to do what bd808 suggested earlier with the queue + bulk write, but it should improve things a bit.

This isn't a time-critical issue, so I would be happy to be a guinea pig for working with WMCS to figure this out. And from what I've read online, the "right" approach here generally would involve memcached, but as far as I can tell that isn't available to toolforge projects.

Thanks @bd808 - I didn't see that, so I was following the "request a memory increase" template. The page you linked me to says that only requests for changes to wiki replica connections are being considered, and this request is about an increase in connections to toolsdb; should I just close this ticket as "not going to happen"?

Thank you @Jrogers-WMF, the prompt response is much appreciated!

Thank you @sguebo_WMF. The specific question from the ticket was about UAs, but I ask that Legal also account for IPs, since those are covered under the same privacy policy and there is a much greater need to query external data on those. And as a caveat, none of these checks would link a username to the IPs - we're doing things like checking whois (https://whois-referral.toolforge.org/gateway.py?lookup=true&ip=8.8.8.8) or parsing a useragent (https://www.whatsmyua.info/api/v1/ua?ua=Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64;%20rv:93.0)%20Gecko/20100101%20Firefox/93.0), but nothing in these checks ties the private data to a specific user or users.

I won't argue the close, but I ask that security makes answering the broader question of "does this violate the privacy policy" this a high priority. It is a routine and ongoing practice for checkusers to consult external services for information on IPs, which are also protected as private information by the privacy policy and calling that unacceptable (which this closure somewhat implies) would have significant repercussions on checkusers' ability to combat harassment.

After talking with Martin, I've redeployed my script without the external call (directly using one of the libraries the external service used). There is still a big question to be answered here, though, since feeding IPs (mentioned in the same line as UA in "personal information") into external services (for proxy checks, geolocation, even just WHOIS to get their range) is a routine part of the checkuser process and we do not have on-wiki tools that can provide those services. I'm not saying that as in "that's how I personally do it" - I've talked with checkusers before about their workflow and they have frequently mentioned those as part of their process. Again, my opinion is that _as long as those data points are not tied to a named account_ there is no privacy concern here, and it would be impractical to use the timing to connect these lookups to specific checks.

I spoke briefly with Martin on IRC about this to voice my concerns, but I will repeat them here: while I recognize that I am a newly-minted checkuser and am not the one making or interpreting the rules, I cannot see this as any different from how checkusers use routinely use WHOIS, geolocation tools, proxy detectors, and the like when investigating IP addresses (and I note that IP addresses are mentioned in the same section of the privacy policy as useragents). Yes, it is sending the UA to an external service, and it obviously ties the request to my IP, but as far as I know there is nothing coming out of MediaWiki that would also leak my username to the external website and so it would be a non-trivial task to match up checkuser actions with queries to this site.

A couple tools that do cross-wiki IP contribution searches, might be helpful:

• https://meta.wikimedia.org/wiki/User:DannyS712/FindIPActivity.js
• https://guc.toolforge.org/

Comment from enwiki - we routinely hardblock open proxies, including CDNs being used as proxies, which is why @Maryana was blocked from editing. Cloudflare already has Cloudflare WARP, and earlier data indicated that Cloudflare, Fastly, and Akamai were all possible exit points for Private Relay traffic, they are all on our block-open-ranges-on-sight list. We have made a specific block template for these services, but we haven't gone through and reblocked all of the known Private Relay exits using that template yet. Related discussion on enwiki from a few months ago can be found at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive334#Upcoming_Apple%27s_iCloud_Private_Relay_(sort-of_VPN). If it helps anyone, a list of current egress points can be found at https://mask-api.icloud.com/egress-ip-ranges.csv (credit to @Urbanecm for showing that to me)

@jrbs the problem, as I see it, is that this is being presented as a fait accompli - the decision has been made, but if you want to complain, you may submit your concerns, to partially quote Douglas Adams, "in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" (in all seriousness - I think we all know that there exist no "questions or concerns" someone could raise that would actually change the outcome here). There have been discussions with the steward team, yes but not with the people who previously granted the right. It's too late now, but next time this sort of thing happens, I suggest at least talking to the impacted parties before the change is submitted for merge rather than blindsiding them such that they find out at the same time as everyone else.

In T278838#6972791, @Valereee wrote:

I tried to fix a typo and a notice came up that said I had been blocked from editing. There was no explanation why, nor any indication of how I could find out why. How can I find out? This has happened before, and I think it happens when I'm not using WiFi.

How about a simpler option - just add a "don't append a signature" button to the advanced panel?

Commenting as an admin + Twinkle user (pretty sure @Amorymeltzer has TW in mind here) that this functionality would be very useful - I routinely use Twinkle and I make rangeblocks fairly often, but when making rangeblocks my workflow is disrupted since Twinkle can't block from Special:Contribs/(IP)/(mask) so I have to use the normal block interface.

Now that we've upgraded to OTRS 6, I'm happy to be a volunteer to test this.

Sure - there are changes to edit summary wording in my version so the current regex probably won't match it but I have no problem with the two being lumped together. Adding

\(using \[\[:w:en:User:GeneralNotability\/spihelper

to that regex would probably be enough to always match my version.

@Aklapper thank you!