Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives/2023-06

What about cross-wiki investigations?

Hi,

On fr-wp, some use cases have been shared during a poll about temporary accounts deployment. One of them made me wonder regarding cross-wiki abuse fighting.

Currently, using IP adresses, we can autonomously check for cross-wiki abuses, including cross-wiki spam and cross-wiki LTA. With IP Masking, even if we have the IP reveal right on our home wiki (e.g. fr-wp), we will not be able to follow tracks of abuses beyond fr-wp if the abuser cleans its cookies, which is really easy and likely (cross-wiki abusers are generally a bit more experienced than common vandals). And it will not be possible to ask for IP reveal right on each of the wikis.

I fear that it is a flaw in the current IP Masking plan. What could be done regarding this point? Is a cross-wiki IP reveal right possible? And/or a cross-wiki tool, such as CentralAuth, but showing temporary accounts linked to an IP adress?

Best, — Jules* ^talk 10:45, 6 June 2023 (UTC)

I believe the team is considering what kind of cross-wiki tools would be both technologically and legally feasible. In the meantime, having a larger number of Global sysops would help. Global sysops have the IP reveal user right everywhere. Whatamidoing (WMF) (talk) 05:10, 7 June 2023 (UTC)

Everywhere including the wikis where they can't use their sysop tools? (I don't know well this status tbh, but I read that global sysops can only use their sysops rights on wikis with fewer than ten administrators exist or fewer than three administrators who have made a logged action within the past two months.) — Jules* ^talk 11:10, 7 June 2023 (UTC)

I believe that's a policy ("social") limitation rather than a technical one. Whatamidoing (WMF) (talk) 19:17, 7 June 2023 (UTC)

Oh, OK, thanks! — Jules* ^talk 21:09, 7 June 2023 (UTC)

Autoblock?

Currently, when blocking an account, the underlying IP adress is subject to an autoblock and an "autoblock cookie" is created on the device, so if the user tries to use another account from the same device but with another IP adress, it will be "autoblocked". (If I'm right.)

Is something a bit similar planned for temporary accounts? Not the part with the cookie, as temporary accounts are already linked to a cookie, but the part autoblocking the IP adress. Put another way: when blocking a temporary accounts, will there be, by default, an autoblock (say for 24 hours) of the underlying IP adress?

Best, — Jules* ^talk 11:01, 6 June 2023 (UTC)

I'm not very familiar with this process, but I believe that an autoblock is separate from a cookie block. They both happen at the same time (=cookie blocks are automatically added to autoblocks), but I believe that the autoblock itself is not stored in a cookie and cannot be affected by clearing cookies. That means that if you are autoblocked, then:

• your account is blocked,
• your IP is autoblocked (for everyone using that IP address),
• your browser/device is cookie blocked, and
• any attempt to use your blocked account for editing (e.g., by taking your device to school or work) during the autoblock period would automatically block your new IP (for everyone using that IP address).

If you clear all the cookies, then:

• your account is still blocked,
• your IP is still blocked, but
• if you were (e.g.,) to take your device to school or work and use the network there, you could create a new account (but if you tried to log in to your still-blocked account, then the autoblock will find you again).

@MusikAnimal (WMF), is this a subject you're familiar with? I found your name in phab:T5233. Am I correct that autoblocks are still in force even when cookies are cleared? Whatamidoing (WMF) (talk) 05:06, 7 June 2023 (UTC)

Thanks for your reply. Yes, it is also how I understand it, with IP autoblocks separated from cookie blocks (but I'm not familiar with the technical side of it). I was wondering if the IP autoblock would also exist for temporary accounts. — Jules* ^talk 11:06, 7 June 2023 (UTC)

That all sounds correct to me. I do not think there's any special handling with respect to cookie blocks and temporary accounts (that would be a question for the Anti-Harassment Tools team), but it wouldn't seem to matter anyway because the account itself is tied to a cookie. So in effect, blocking a temporary account (with the autoblock option checked) is the same as cookie blocking an IP, in that it's active so long as the cookies remain there or you use the same IP. LTAs and such will of course easily evade this, but that's no different than the status quo sans IP masking. MusikAnimal (WMF) (talk) 15:45, 7 June 2023 (UTC)

Thanks. But will the block of a temporary account generate an IP [i.e. not cookie] autoblock? (without considerations for cookie autoblock) Sorry to insist, it's not clear to me ;-). — Jules* ^talk 15:52, 7 June 2023 (UTC)

Autoblocks have both IP autoblocks and cookie blocks. It is active if the IP is the same; it is active if the cookie is present. The presence of either the IP or the cookie is enough to prevent editing. Both the IP and the cookie must be fixed to be able to edit again. That means, e.g., that if you block with the autoblock setting, the blocked user must clear cookies and use a different IP address to be able to edit again. Merely using a different IP address is not enough, because the cookie will block editing; merely clearing the cookie is not enough, because the IP address will block editing.

The AHT team intends for this to work the same way for temporary accounts as it works for IPs and for logged-in accounts now. Whatamidoing (WMF) (talk) 19:24, 7 June 2023 (UTC)

The history might make this clearer: Autoblock was originally IP autoblocks. The idea is that a blocked registered editor might try to switch IPs (mistakenly thinking this would get around the account block), and we'd use autoblock to detect and block the new IP. Now the editor is account-blocked on the old registered account, everyone is autoblocked on the old IP used by the old registered account, and now everyone is also autoblocked on the new IP the blocked user switched to in an effort to evade the first autoblocked IP.

Cookie blocks were added later. The cookie blocks add an additional way to detect block evasion and stop malicious actors, but they're not inherent to the autoblocking system. The original IP autoblocking still works even if there is no cookie. Whatamidoing (WMF) (talk) 19:31, 7 June 2023 (UTC)

The AHT team intends for this to work the same way for temporary accounts as it works for IPs and for logged-in accounts now.

Perfect! That is what I wanted to know. — Jules* ^talk 21:09, 7 June 2023 (UTC)

Refusing all cookies

According to Phabricator T335084, it is necessary to check whether an unregistered editor has received the warning notice prior to editing. It would therefore be highly illegal under the GDPR to implement the system because no exceptions are allowed. Assuming the putative editor does see a notice and rejects the implementation of a cookie on his device, are you then going to prevent him from editing? If you are, you might just as well take the entire wiki private for registered editors and be done with it. People can reset their browser to refuse all cookies. If they do, will the putative editor be prevented from editing and have no way of finding out why? If this is not the case, will the editor be threatened that if he doesn't cancel the preference he won't be able to edit? Many people experiment with IP edits before registering. I can think of no better way of decimating the editor base. Wouldn't it be better to leave things as they are, rather than opening this can of worms?

Another serious privacy breach - it is not possible to tell from a temporary account number whether it attached to a particular device in one of a borough's public libraries which provides access to "the people's network." If that number was attached as a result of a vandalistic edit and the IP is blocked as a result then all the good faith editors in the borough are frozen out. The system allows a particular device to be tracked wherever it is used. So a vandal can utilise the wifi of different organisations as he moves around. If the IP addresses are going to be blocked as a result even more good faith potential editors are going to be frozen out. 156.61.250.251 10:29, 6 June 2023 (UTC)

Referring to the as-yet unanswered enquiry at "Privacy concern of accessing temporary account all used IP addresses", if the user has set his browser to "refuse all cookies" and the Wikimedia software discovers this on attempting to implant a cookie when he presses "publish" on an unregistered edit, what is it going to do about it? 80.5.88.70 06:39, 7 June 2023 (UTC)

I have moved these comments to a separate section, as they are related to each other and are not really related to the comments they were posted after.

As a point of clarification, phab:T335084 refers to "warnings", such as Template:Uw-delete2, that are posted on a user's talk page to express concern about the edits they have already made. Whatamidoing (WMF) (talk) 20:36, 7 June 2023 (UTC)

Ban parameters

Just some questions:

• Does an IP ban with no checkmarks checked ban temp accounts?
  • Do we need to check "ban accounts" in an IP ban for it to affect temp accounts?
• Are temp account names ever re-used?

Snævar (talk) 07:36, 24 June 2023 (UTC)

Hello! When you say "ban" I assume it is the same as "block". Temporary users will be treated the same as IP users are treated right now (for the most part). So for your first question, an IP address block will work the same way as it does right now (ip users = temp users). I am in the process of writing more elaborate documentation to clarify the differences between temp and registered editors that should clarify this further.

As for your second question, no, temp account names will not be reused. -- NKohli (WMF) (talk) 20:36, 25 July 2023 (UTC)

Editing in flow without an temporary account

Hello, I found that there is problem when I am testing IP masking. I tested in a page in beta cluster which uses flow ([1]). When I tried to hide a topic. A temporary account cannot be created and causing the IP address leads. Another edit is that I tried to create a new topic without a temporary account ([2]), and the temporary account cannot be created. Is there are any reason why it happens? 49.197.52.98 10:37, 26 June 2023 (UTC)

Thank you for flagging this! I will pass this along to the Flow team. Most teams are in the midst of updating their tools and extensions to be compatible with IP masking at the moment. It is possible that the changes to Flow will be made in the near future. I will relay this to the relevant team and update back here when I hear about it. Thanks! -- NKohli (WMF) (talk) 20:42, 25 July 2023 (UTC)

Converting temporary accounts to permanent

While I generally think that IP masking project is the wrong approach to this problem and we should’ve invested far more resources into making our account creation as streamlined and smooth as possible, I can see one thing that IP masking can probably do right: convert temporary account attribution to proper user edits on account creation. Is this something that is/can be explored during the project? To clarify, I think that one of the drawbacks of the current system is that those users can edit for days/months, register their accounts and then those edits are not counted as part of their Wikipedia experience even though they are such. I think one of the best things this project can do is, if a user creates an account after some IP editing, to convert those temporary account contributions into their regular account contributions, perhaps sometimes even skipping the user to autopromoted rights like autoconfirmed if they satisfy the descriptions. Maybe that should require user consent, of course, but it feels like no-brainer to me if we tie anonymous identity more closely to a singular user. stjn^[ru] 05:29, 30 June 2023 (UTC)

It’s an interesting idea, and probably most people would welcome it, but it definitely needs user consent, as there are exceptions – first, more people can reveal a temporary user’s IP address than a regular user’s, and one may not want to have their permanent account linkable to their IP address; second, a temporary account can be shared by multiple people (even though it’s way less likely to happen than sharing an IP address), for example people using the same computer in a library, school etc., so linking these edits to the permanent account may attribute edits to a person who didn’t make them. —Tacsipacsi (talk) 18:40, 1 July 2023 (UTC)

I agree entirely that "IP masking is the wrong approach", but what's the problem? Either revealing an editor's IP address to the world directly after (s)he has given her informed consent is illegal or it's not. If it is illegal to act upon informed consent cite the law that says so. Without informed consent, IP addresses are "non-public information" which should be accessible only to people who have identified to the Foundation - i.e. Checkusers. Yet the core of this plan is to make the information accessible to anyone who qualifies for low-level rights (pending changes reviewer, rollbacker, etc.). 80.5.88.70 07:39, 2 July 2023 (UTC)

There is no identification to the WMF anymore, as that practice ended almost ten years ago. Functionaries such as Checkusers and Stewards only need to sign a confidentiality agreement, and they don't have to reveal their real name when they sign it. As for converting temporary accounts to normal accounts, the help page on MediaWiki states that it won't be possible. kyykaarme (talk) 13:46, 2 July 2023 (UTC)

This is skating round the issue. When an unregistered editor makes an edit (s)he will presumably be told that a temporary account will be created for her device and her IP address will remain confidential. She will assume that, like registered editors, only CheckUsers will have access to this information, and before the CheckUser can access it, she will have to complete a CheckUser log explaining why she wants it. What the editor will not be told is that the IP information (which could be hundreds of addresses in the course of a year) is in fact going to be made available no questions asked to virtually anyone who wants it. Imagine the power that gives to the authorities in totalitarian countries to identify and detain dissidents. 80.5.88.70 06:24, 3 July 2023 (UTC)

I don't disagree with you on the issue. I have serious concerns about this IP situation when it comes to privacy and what it means to the new editors who won't understand that there will be maybe hundreds of people who can access their IP. And most new users don't know anything about Checkusers, and instead they probably assume that only the paid workers can access their IP, because that's how it likely is on almost all if not on all other websites. kyykaarme (talk) 20:19, 5 July 2023 (UTC)

But the Foundation keeps saying we're going to get IP masking whether we like it or not. Can't we have an RfC in which we can get a consensus that the proposal is a non-starter and should be dropped? 62.140.210.130 10:16, 6 July 2023 (UTC)

I doubt an RFC would make any difference, because this whole project was started due to possible legal issues raised by the legal team. If there are issues with privacy on Wikimedia sites, it's the WMF who has to answer for it in the end. I'm sure the legal team is super busy, but I would love to hear their answers or comments regarding some of the concerns raised on this talk page. kyykaarme (talk) 17:21, 12 July 2023 (UTC)

By any reasonable definition, the vote (it's much closer to a true vote than a regular !vote) a few months into the IP masking discussion demonstrated that it was viewed as a highly unwise decision. That it continues is a decision by Legal to ignore community consensus on the matter - doing another RfC would only re-demonstrate that already known point and would not notably enhance the process. [I use ignore rather than, say, override, as Legal let the discussion run and only implemented that note after it became known, made an odd claim of being unable to waive legal privilege, and failed to answer a number of process concern questions (as opposed to substantive questions that might endanger legal concerns) - the IP masking team has been communicative throughout, is cogniscent of the flaws, and apologised for the issues, alas, they can't apologise for another group's issues] Nosebagbear (talk) 16:26, 30 July 2023 (UTC)

Link to previous: [3]. According to this website [4]:

"Browser fingerprinting is just another tool to identify and track people as they browse the web. There are many different entities - both corporate and government - that are monitoring internet activity, and they all have different reasons for doing so...Surveillance agencies could also use this ..."

A whole new set of surveillance tools is being set up ahead of the introduction of IP masking. The Community does not want it and when that became apparent Legal came up with "we are unable to waive legal privilege." The relevant article says:

"...legal professional privilege protects all communications between a professional legal adviser (a solicitor, barrister or attorney) and his or her clients from being disclosed without the permission of the client. The privilege is that of the client and not that of the attorney.

The client here is the Community. The Community does not want IP masking and Legal are lying when they say "legal privilege" makes it necessary. Lying to the client is possibly the gravest form of professional misconduct. Legal need to make a statement, and if they don't the next step is to establish the names of the people concerned and the professional associations they belong to so they can be struck off. 80.193.96.17 14:12, 31 July 2023 (UTC)

Actually, the client is the Foundation. Legal are an "in-house" legal team, which means that while they truthfully said that "we are unable to waive legal privilege" that puts the ball in the Foundation's court. The Foundation told the lawyers to say there are legal issues which cannot be disclosed, but an opposing lawyer would counsel that this is just a smokescreen to hide the fact that there are no reasons why the successful system used without problems for 23 years should be ditched. I don't know how the board members are elected, or what say in the matter Community members have, but the re-election of members who don't come clean should be opposed.

It is immoral that the whole project is predicated upon lulling unregistered editors into the false belief that it is designed to make IP numbers "non-public information". The privacy policy says no more than that they are "personal information." People do reveal personal information for reasons of convenience - for example if they live within the catchment area of a school they will reveal their home address to prove it. Schooling is compulsory - I doubt that the Local Education Authority would refuse to educate a child if the parents kept their address secret.

Board members have a conflict of interest because, so far as I know, they are registered editors. Registered editors can view their edits and their currency over 23 years - temporary accounts will last no longer than a year - and if you're editing from a public library no more than a day. The present system gives unregistered editors the same facilities that registered editors have - for example the Islington Libraries IP (62.140.210.130) has been used by editors since at least 2012 (check contributions on EN-WP). They can't use it now because the configuration (multiple devices in multiple locations) leads to it being viciously blocked by administrators who view it as an "open proxy."

The staffing seems to rotate. In 2014 Geoff Brigham was General Counsel and Stephen LaPorte was Legal Counsel. Now he's General Counsel. In 2018 Eileen Hershenov was General Counsel and Chuck Roslov was Legal Counsel. In 2019 Tony Sebro was "Interim General Counsel." In 2020 Amanda Keton was General Counsel. Geoff has moved to Facebook (maybe something to do with the Wikimedia case against NSA spying being thrown out of court in October 2015). The Foundation was going to appeal - what happened? Amanda left in February and this [5] I don't really understand. 2A00:23C0:7984:5101:F221:B1C7:9EB7:BD6B 13:10, 9 August 2023 (UTC)

SimilarEditors

There has been little discussion on mw:Extension:SimilarEditors compared to other things. I was able to find information on most things I wanted to know, except one.

• Which user groups will have access to mw:Extension:SimilarEditors ?

--Snævar (talk) 11:23, 24 June 2023 (UTC)

Unfortunately, the SimilarEditors extension work has been paused at the moment. We are focusing our efforts on IP Masking implementation currently. Given the broad scope of who can see IPs, it did not seem like SimilarEditors is a necessary feature before IP Masking deployment. We can come back to pick up the work on that project after IP Masking if that is seen as an important tool by the communities. -- NKohli (WMF) (talk) 20:39, 25 July 2023 (UTC)

Hi @NKohli (WMF). From what I understand, SimilarEditor would be the only way to check, from a temporary account A, if there is a "temporary account sock" B, by seeing all edits (from last 90 days, which is already a limit) of the IP used by temporary account A. Indeed, the right to access the temporary account A IP does not allow to find other temporary accounts using the same IP. Put another way, with only IP access right included in IP Masking, without any SimilarEditor tool, we will lose an hability we currently have: when we block an IP adress, we currently see all its edits. See also the second half of #Privacy concern of accessing temporary account all used IP address. Tell me if I understood it wrong ;-).

I will not insist further, but after discussing it with some fr-wp sysops and explaining it to fr-wp community, and while I think IP Masking is necessary, I'm deeply concerned that not having this tool would seriously compromise editors' acceptance of IP masking, because it will hinder abuse and vandalism fighting.

Best, — Jules* ^talk 21:00, 25 July 2023 (UTC)

Reading your reply to #Range checks for contributions, I realize I may have got it wrong. If you consider giving access to trusted users to all edits made by temporary accounts on an IP range, it necessarily includes seeing all temporary accounts who edited from a single IP adress. — Jules* ^talk 21:05, 25 July 2023 (UTC)

It's apparent that the consensus here is that we don't want IP masking (a) because we've managed successfully without for 23 years and (b) because it raises serious GDPR issues. It's like telling police officers they can't access their national database. You say "while I think IP Masking is necessary..." and then go on to say that what is planned "would seriously compromise acceptance". So can you explain why you think IP masking is necessary? Also, given your concerns would you (or another contributor) like to open an RfC on the matter? If the WMF shuts it down that would, as LilianaUwU puts it, scream "superprotect."

Also, why is this being progressed by the Anti-Harassment Team? Have they any evidence that unregistered editors are being harassed more than registered editors? It goes the other way, because if an unregistered editor feels she is being harassed she can move to another IP. If she's forced to edit through a temporary account then, like a registered editor, she just has to take what comes. 80.5.88.70 07:43, 26 July 2023 (UTC)

I don't see any evidence that "the consensus here is that we don't want IP masking" and the parallel with Superprotect does not seem relevant to me (it has been implemented without discussion with the community, which is not the case here). Some editors are against it, others (including me) think it's a good thing to not disclose IP adresses, and from what I saw in my community (fr-wp) a lot of people are rather neutral, with some wondering that it will hinder anti-vandalism work, without being radically against it.

I don't see any reason to open an RfC when we don't know yet precisely how will IP masking be implemented. Plus wikis that really don't want it will still be able to make registration mandatory instead. — Jules* ^talk 08:43, 26 July 2023 (UTC)

Superprotect came about because the Foundation insisted that on EN:WP editors would be presented with Visual Editor when opening the edit window. There is something which can be done on client side (as opposed to server side) which risks damaging the hardware to enforce the Community's preference. This was done and the edit window opened with source editor. Superprotect was designed to stop such a fait accompli happening again. I don't think your views (whittling away the feature which made Wikipedia succeed where other websites failed) are representative of the Community as a whole. I urge someone open-minded to open the RfC. Delaying is like writing to the Council when an intrusive building goes up next door instead of when notice of the planning application was posted. As for consultation, the way it has been conducted is like asking convicts whether they would prefer to be executed by hanging or lethal injection. 80.5.88.70 10:06, 26 July 2023 (UTC)

You may not have noticed, but WMF made real efforts and imho some progress in engaging with the community (communities?) since Superprotect, which was indeed a really bad thing. Your stance seems immoderate to me. — Jules* ^talk 10:18, 26 July 2023 (UTC)

The IP has been blocked as a long-term abuser (according to the block log).

Also, this is not directly relevant to IP masking, but I'm concerned about false rumors going around. Nothing this person said about SuperProtect appears to be true: wrong wiki, wrong software, wrong goal. Anyone who wants to know what actually happened should probably look at the log entries that triggered its first use, think about what might happen to the servers when admins wheel war over image display, and make up their own minds about whether the IP's story has any basis in fact. Whatamidoing (WMF) (talk) 23:15, 22 August 2023 (UTC)

Well, in any case, I appreciate the notification and I hope that the news about SimilarEditors arrives to the next MassMessage, whenever that may be. Snævar (talk) 11:33, 9 October 2023 (UTC)

As for the importance, checking the same things as SimilarUsers does manually is in the top 5 spots of the things that take the most time in reviewing other peoples edits. It would mean that patrollers can use that time to create more articles. Those points would help in some key result progress listed at Wikimedia Foundation Annual Plan/2023-2024/Product & Technology/OKRs, the first point (sentance) helping with WE1 Key result 2 and the second point (sentance) helping with WE1 Key result 3. Snævar (talk) 12:33, 9 October 2023 (UTC)