I've created an NDA-protected paste with the explanation (h/t @AntiCompositeNumber for the suggestion) at P48918.

I hypothesize that this may be related to autoblock - I can explain further, but the information is protected by ANPDP, so I'll have to share it privately somehow. Didn't want to turn this into a security-restricted ticket and share it here right off the bat in case I'm wrong, since it really is just a guess.

Hey y'all, I was pointed to this task by @stjn. These changes unexpectedly broke my toolforge project at bullseye.toolforge.org - it was serving wikimedia maps but in the past week it started serving gray tiles and I was getting 403s in the browser console from the tile queries. I hacked around it by adding <meta name="referrer" content="strict-origin-when-cross-origin" /> to the source of my tool (h/t @AntiCompositeNumber for figuring that out), but this was an unexpected breakage and it would have been nice if it had been communicated more widely.

+1 to everything Blablubbs has said here. Speaking as a fellow functionary, this reduction in available information is going to have a significant impact on our anti-abuse capabilities. I'm all for finding a solution that works better cross-platform, or that gets better information, or that minimizes the data collected from users while still remaining useful for anti-abuse - but we need some kind of fix very soon, and while this deprecation should not have caught us off guard (seeing as the ticket's been open for almost three years)...here we are.

See also T298912, which is a broader request for similar data (but less aggregated)

++ from me, these historical oversize checks make the CU log less useful since there's a lot of random old /1 and /2 checks in there. I would support either of Dreamy_Jazz's proposed solutions.

Huh. I had not seen that particular document, would have been nice if it had been mentioned in the privacy policy. Thanks @SCP-2000.

You're arguing that this information is security-relevant. That is not the same thing as "non-public personal information". I'm absolutely being an armchair lawyer here, but the privacy policy is pretty clear that it applies to information which could be used to identify you. There is no PII contained in the one-bit "2FA enabled" / "2FA disabled" setting, and that's a significant part of my objection.

The ruling that 2FA status is "non-public personal information" doesn't make sense to me. How is it any more non-public than than "has an email address set"? For reference, the email address status is exposed to anyone with an account and verified email address via Special:EmailUser (attempting to email a user without an email set will get the error This user has not specified a valid email address.). Further, the 2FA group requests take place on a public noticeboard (https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions), a steward confirms that they have added the oauth-tester group, and the group membership is public. As possible attack vectors go, one can have a fairly good chance at identifying 2fa users by membership in said group or lack thereof. Or if someone requests intadmin but doesn't have 2FA set...the stewards will most likely say something to the effect of "sorry, we can't grant this until you turn on 2FA," won't they? Or will they have to give vague decline reasons if someone refuses to enable it?

Certainly. The answer to why it was chosen is, well, it was the first service we found that did the job we needed (at the time, that was identification of certain peer-to-peer proxy networks, related to T265845). I believe it came from email discussions with Spur about our problem which ended up with several free access keys being issued to Wikipedia checkusers. I cannot speak to any other paid services, since I haven't used any others, but it is much, much better than several free services that checkusers have worked with before; IP Quality Score and proxycheck.io in particular have been used before and have a poor reputation for accuracy. If you all have suggestions for other services to trial...well, I'd be happy to add integrations to Bullseye for them so that CUs can test them out!

I've worked with Spur data a fair amount - it's a data source in the bullseye tool (bullseye.toolforge.org) and I've been in contact with the developers before. Happy to share a copy of the API documentation (probably via email - I don't think this documentation is publicly available so I'd rather not put it in public on phab) or share my experience if anyone wants.

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!