Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 14 days and sections whose most recent comment is older than 120 days. For the archive overview, see /Archives.

Where's the privacy enhancement

Currently everyone can see the IP addresses, and while from privacy standpoint that is not good, at least it's transparent. By that I mean that anyone can see that anyone can see the IP addresses. (I know that many people don't even know what an IP address is.) In the future IPs will be hidden from the general public, but it will still be possible for pretty much anyone to see them: they just need to wait 6 months and do some editing and then they'll either get the IP access automatically or they can apply for it. How is that enhancing the privacy of the unregistered users? And how is it going to be communicated to the unregistered users in a way that there is any chance of them understanding what a temporary account actually is? And understanding that their browser will store a cookie that records all the IP addresses that they have used with their temporary account, be it at home or at work/school etc.

I've been following this project from the beginning and waiting for the moment when I'll understand how this is better for the unregistered editors, and I still don't get it. kyykaarme (talk) 17:03, 3 May 2023 (UTC)

Hello, @Kyykaarme, I am happy to see your name here.

Currently, everyone can see the IP addresses. In the future, only a small fraction of people will be able to see the IP addresses. It is true that, with sufficient patience and effort, any individual could (probably) become part of that small fraction of people (more than registered editors, but still only a small percentage of users). It is also true that with sufficient patience and effort, a determined individual could become a CheckUser. In the end, "visible to some" is still improved privacy than "visible to all", even if it might not be as much of an improvement as would be ideal.

The messages in all the editing interfaces will have to change. To give an example, phab:T335590 outlines some of the proposed changes for talk pages. We are probably going to add a link to mw:Help:Temporary accounts as well.

(I believe that the IP address will be recorded on the server, just like yours and mine are now, and not in the cookie itself. The cookie records the automatic username.) Whatamidoing (WMF) (talk) 05:02, 5 May 2023 (UTC)

Hey, @Whatamidoing (WMF), thanks for the reply. It seems that IP masking is being treated as if the logic is the same as when the interface admin group was created to make it less likely that someone uses certain admin tools maliciously. With IP masking we should instead think about the issue from the point of view of the unregistered users. It's irrelevant to them that their IP was previously visible to everyone (maybe they have never even edited before), and instead what matters to them is who can access their IP now and if that's something that the user understands. If we care about people's privacy we should make sure that they understand what happens with their personal information (like an IP address). Also, since there's going to be a cookie that lives in the user's browser, I assume that there has to be a cookie notification that the user will have to agree to? (In the EU at least.) And yes, there's also a group of volunteers who can access almost anyone's IP, and IMO that should also be communicated to the (registered) users, so that they can decide if they agree to it or not. kyykaarme (talk) 18:28, 21 May 2023 (UTC)

I'm sure that Legal will update foundation:Privacy policy and foundation:Cookie statement between now and then, and these are linked on every page.  

The in-software messages are also being updated. The most relevant ones (e.g., the note at the top of the editing window that says you're logged out) will link to Help:Temporary accounts. Whatamidoing (WMF) (talk) 00:59, 23 May 2023 (UTC)

Updating disclaimers or policy pages is not the same thing as giving users the choice of consenting to the cookie that will be placed in their device for 12 months. Under GDPR rules the website can place cookies into the user's device without consent only in certain circumstances. Log-in cookies don't necessarily need a cookie notification, but the pseudo-account users aren't actively choosing to log in, they are just trying to edit and the pseudo-account is created for them automatically. They are then "logged in" for up to a year in a pseudo-account without an easy way to "log out". And all the while the cookie will collect personal information (regardless of where the information is actually stored) of that person and giving possibly dozens or hundreds of people access to that information.

Even if that's legal (and I have my doubts), I think it's unethical if the users are duped into believing that their personal information is much more private than it actually is, and they are not told in advance and therefore given the option to choose if they want to edit under these circumstances or if they'd rather create an actual user account or just not edit at all. kyykaarme (talk) 18:10, 6 June 2023 (UTC)

@Kyykaarme, I don't understand "the cookie will collect personal information". What do you mean?

For example, right now, if I go to the Finnish Wikipedia, I get a cookie called "fiwikiUserName" that has a value of "Whatamidoing%20%28WMF%29". The domain is fi.wikipedia.org (naturally enough). It has an expiration date of next year, and aside from a couple of settings, like whether it's for https: use, that's it. The cookie's contents aren't going to change. How does the cookie "collect personal information"? Whatamidoing (WMF) (talk) 22:57, 6 June 2023 (UTC)

The cookie will enable the aggregation of the edits the user made within a year, and everyone with the IP viewer user right will be able to access all the IPs the user has used. That is the personal information that the cookie collects. kyykaarme (talk) 17:47, 17 June 2023 (UTC)

@Kyykaarme, are you saying that Special:Contributions/WhatamIdoing is "collecting personal information" that is using a cookie to "enable the aggregation" of my edits? Whatamidoing (WMF) (talk) 23:01, 22 August 2023 (UTC)

Special:Contributions/WhatamIdoing doesn’t list the IP addresses you’ve used in the past years. Special:Contributions for a temp user would, for anyone with IP viewer right, thus allowing those users to link edits to IP addresses (which is what we want to avoid) as well as linking IP addresses to each other (which is today not possible at all – unless guessable from the edit pattern –, so it’s a step backwards privacy-wise). – Tacsipacsi (talk) 23:19, 23 August 2023 (UTC)

I think it's a mixed situation. Right now, anyone with access to the internet (=several billion people) can see the IP for an unregistered editor, forever.

In the future, only a small percentage of registered editors (probably less than 1% of all registered accounts; about 0.5% at enwiki, assuming they don't impose tighter restrictions locally [and they might]) will be able to see the IP address for unregistered users, for 90 days.

So far, this is obviously an improvement in privacy. Then we add:

The 0.5% of editors who can see the IP address can see all the IP addresses (but still only for 90 days).

Overall, I think that trading "a few people can temporarily see all of them" for "everyone can see each of them separately forever" is a privacy improvement. But if the communities think this is an unreasonable tradeoff, and they would prefer that only checkusers be able to see all of the IPs, then I believe it's technically feasible to restrict access to just the most recent one. Whatamidoing (WMF) (talk) 06:56, 24 August 2023 (UTC)

That still does not address the fact that said cookie (used to create and later identify the pseudoaccount) will allow aggregation of edits done from the same device, even if the user IP address changes. Nowadays, only checkusers are able to see that kind of aggregated data, but after IP Masking goes live, at least in its current design, the number of users that would be able to see (and link) IP addresses with pseudoregistered users (aggregated data based on non-public PII) will increase. This makes temporary accounts second-class accounts with regards to privacy. As for the cookie used to create the pseudoaccount and allow MediaWiki to attribute edits done by that device up to 12 months, it is my understanding that these types of cookies require an active and informed consent according to EU Law (See ECJ Judgement of 1 October 2019, Planet49 GmbH, C‑673/17, ECLI:EU:C:2019:801, § 82 (1)). As such, you need to clearly inform the user and allow him to consent in a manner that can be proven afterwards (premarked checkboxes or no checkboxes at all are not okay). Thanks, —MarcoAurelio (talk) 11:36, 24 August 2023 (UTC)

Yes, exactly. Currently IP users are in a hotel with no locks on the doors. In the new system there will be locks on the doors, but many, many people will have a master key. The IP users deserve to know that fact so that they can make an informed decision on whether they want to subject themselves and their private information (IP address) to this situation. I consider that to be a moral right of the users, but people from different parts of the world also have different expectations and actual legal rights when it comes to cookies and other privacy issues. How often do non-EU citizens see cookie notices? I see them daily and yes, I actually take the time to read them, and every now and then I hit the backspace because I don't want to visit a website where it takes too much effort to control the cookies that are inserted into my device. kyykaarme (talk) 17:52, 24 August 2023 (UTC)

MarcoAurelio, would you prefer to have the account name to change every time the IP changes?

(Kyykaarme, I see cookie notices every day. Personally, I don't need a checkbox to control cookies in my web browsers, but perhaps someone benefits from it.) Whatamidoing (WMF) (talk) 06:12, 28 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)

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: [1]. According to this website [2]:

"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 [3] I don't really understand. 2A00:23C0:7984:5101:F221:B1C7:9EB7:BD6B 13:10, 9 August 2023 (UTC)

IP Info

How is IP Info going? While I was far from the most avid tester, I did give it a few goes in both admin (now, I guess that would be "IP-masking cleared" and non-admin modes. I backed the three pieces of listed feedback as accurate. I'd also say that the non-admin version provided very little information of any practical use, regardless of its actual usefulness. Is Spur being responsive? What other additions are being considered? Cheers. Nosebagbear (talk) 16:29, 30 July 2023 (UTC)

I agree that the non-admin version (which I see on enwiki) is much less useful than the admin version (which I see on Commons). With the non-admin version I see myself turning to additional tools ~80% of the time (geolocation, WHOIS, and Spur), as opposed to about ~50% of the time (primarily Spur, occasionally WHOIS) with the admin version. Making the non-admin version more useful would be a very welcome improvement, and integrating Spur data would obviate most need for external tools. —‍Mdaniels5757 (talk • contribs) 01:40, 1 August 2023 (UTC)

I heard last week that there had been progress around improving the details provided in IP Info, but that it was not finished. Whatamidoing (WMF) (talk) 23:30, 22 August 2023 (UTC)

Should temporary accounts get notified of reverts?

I'm curious if any community members have thoughts on this. This topic relates to this Phab task: T333531.

Currently new accounts do not receive revert notices.

However, as of now, temporary accounts will receive revert notices since that is the system default.

I think there are pros and cons associated with either approach, and I'm curious if anyone has insight into which approach makes the most sense for temporary accounts. Thanks! - KStoller-WMF (talk) 22:58, 31 July 2023 (UTC)

How technically difficult would it be to add a temporal aspect to this - say, a week? If easy, then that seems best (I realise it might not be - I've no idea). Nosebagbear (talk) 17:22, 10 August 2023 (UTC)

Thanks for the feedback, @Nosebagbear! Hmmmm, that would definitely add some technical complexity. It seems like we should just have a binary "yes" or "no" as to whether temp accounts are going to receive revert notices to reduce community confusion about this. Personally I'm leaning towards keeping this simple and moving forward with the system default (which would mean temp accounts receive revert notices). Keeping system defaults is also more ideal from the user_properties table bloat perspective (T333531#9046743). KStoller-WMF (talk) 19:02, 11 August 2023 (UTC)

Fair enough - definitely greater priorities to spend the time on. Nosebagbear (talk) 19:55, 11 August 2023 (UTC)

I didn't know (or forgot?) that new accounts do not receive revert notices. I think both – IPs/temporary accounts and new accounts – should receive those.

It happens quite frequently at dewiki that IPs/new users don't notice that they have been reverted and continue editing other articles with the same mistakes while established editors wonder why they don't react to advise given in the revert's edit summary. Johannnes89 (talk) 20:39, 11 August 2023 (UTC)

This is the first I have heard of this. When I edit on EN:WP the first I know of an edit being reverted is when I check the page history, or my contribution record, or refresh the page and notice it isn't there, or someone posts a message to my talk page. I imagined that everyone would check to see how things develop. For a registered editor, does a revert trigger something on the message notification system, and if it does, how long has it done so? Is it open-ended? Would (s)he be notified of a revert made ten years later (assuming no intervening edits)? What about partial reverts? Occasionally the orange "you have new message" bar flashes up and I am directed to a message that may be ten years old, no one using that IP having accessed the site in the interim. 5.150.93.133 10:42, 12 August 2023 (UTC)

This notification is delivered using the Notifications extension, see mw:Help:Notifications/Types#Edit reverts. As far as I know, the Notifications system as a whole is unavailable to IP users. Revert notifications have been available for logged-in users for over a decade. —Tacsipacsi (talk) 11:07, 13 August 2023 (UTC)

I also didn't know that new users don't receive revert notifications, but I think it's a good thing that they don't. Sometimes a patroller might revert an edit when a more gentle approach like making adjustments to the edit would've been possible, for example. I've even seen patrollers revert test edits that were made on a test page. If a new user keeps making problematic edits, the experienced users should leave a message on the user's talk page instead of just reverting and writing their explanation in the edit summary. kyykaarme (talk) 08:49, 13 August 2023 (UTC)

Hi. I have mixed feelings, as @Johannnes89 and @Kyykaarme both have good arguments. But I think I would prefer that new users and temp accounts receive reverts notifications, even if patrollers should add an explanation on newcommers talkpages, in order to maximize the probability that newcommers see why their edits have been reverted. — Jules* ^talk 17:47, 31 August 2023 (UTC)

I think that the concern, in the past, has been that if new editors see they've been reverted, they will edit war, rather than trying to understand why their edits have been reverted. Whatamidoing (WMF) (talk) 19:50, 4 September 2023 (UTC)

It's quite difficult to have an opinion on different functions of the temp accounts when there is little information on what the users themselves will see in various stages of their experience (most importantly before they make their first edit). But I think it's a bad idea to show them revert notifications. Many temp account users will probably be people who are mostly readers of Wikipedia and they only make one or a few edits. I don't think we should show them a notification when someone has reverted an edit they made maybe months ago. I don't know if the list of notifications in the phab post 9079067 is accurate, but I don't think it should be possible to "thank" edits made by temp accounts, and the users should not be notified when they've been mentioned, nor should they be notified when they reach an edit milestone. kyykaarme (talk) 08:29, 13 August 2023 (UTC)

why shouldn't they get notified when they get mentioned somewhere? Johannnes89 (talk) 09:10, 13 August 2023 (UTC)

I see temp accounts as more like "IP editor plus" than "registered account light". They are people who have not chosen to register a user account just like current IP users haven't, and we should keep treating them in similar ways. If I think of current situations where an IP user might get pinged (if they could be pinged), it'd probably be when someone reports a vandal and in very rare occasions in some discussions. There's no need to notify a vandal and in the latter situation another user can leave a message on the user's talk page. Just like with revert notifications, pinging risks unnecessarily bothering people who are not actually editors and instead they're mostly just readers of Wikipedia. kyykaarme (talk) 13:25, 13 August 2023 (UTC)

IPs not having access to Echo has probably more to do with the fact that multiple people can share an IP and thus notifications can reach the wrong people. Temporary users, on the other hand, are likely to correspond to specific people (except for temporary users created on public computers, like in libraries) – while the likelihood of people changing temporary accounts, and thus missing notifications, is still high, the likelihood of people sharing temporary accounts and thus receiving notifications not aimed at them is significantly lower. So even though temporary users are more like “IP editors plus”, the technical differences can allow to include (at least some) notifications in the “plus” part instead of excluding them as part of the “IP editors” part.

There's no need to notify a vandal – why? If a vandal is not notified, chances are much lower that they will ever change their behavior. If they’re notified, maybe they realize that what they do is wrong, and start doing constructive edits (or at least stop doing destructive edits without the need for a longer block). Also, when one is pinged, then someone else wants something from them; it’s a necessary bothering of someone who’s not just a reader, but also an editor to some extent (if one is not an editor at all, i.e. never edits, the temporary account doesn’t get created and there’s nothing to ping). Other editors can always decide not to ping someone. —Tacsipacsi (talk) 18:48, 13 August 2023 (UTC)

I meant that when a user reports a vandal to the admins, at that point it's not necessary to notify the vandal that they're being reported. kyykaarme (talk) 08:50, 16 August 2023 (UTC)

And I meant that exactly at that point, it’s at least useful to notify the vandal, to give them a chance to realize that what they’re doing is wrong and could have serious consequences, and to stop vandalizing before they get blocked. —Tacsipacsi (talk) 23:37, 16 August 2023 (UTC)

And I meant that at that point it's too late. When a patroller reports a vandal to the admins, it's usually the case that the vandal has already been warned at least once or twice, or they have rapidly done so many edits that they need to be blocked ASAP. kyykaarme (talk) 07:55, 19 August 2023 (UTC)

It’s never too late. Especially in the second case, if the vandal has never been warned before, they may stop vandalizing if they are warned by the block request ping. But even in the first case, they may have missed/ignored/not taken seriously the previous warnings: it’s not likely that this time they will, but not impossible either. —Tacsipacsi (talk) 22:27, 20 August 2023 (UTC)

phab:T333531 indicates that Echo will infact be active for temp users with the notifications listed in the ticket. This is another thing that would be useful in the next MassMessage, along with all instances where temp users are not treated the same as IP editors. Snævar (talk) 12:02, 9 October 2023 (UTC)

Even if it's not "necessary" to notify the vandal that they're being reported, is it harmful?

Some wikis have better success in turning vandals into productive editors than others. Whatamidoing (WMF) (talk) 23:34, 22 August 2023 (UTC)

Anonymous blocks in the future

How will anonymous blocks persist in the future when blocks are set to an temporary account? And the block duration only until the account expires and what about the existing IP blocks that was set long in the past? JrandWP (talk) 16:09, 14 August 2023 (UTC)

@JrandWP, it will be similar to blocks for registered editors. The admins will have the option of blocking only the account or the account + the underlying IP address (to prevent the immediate creation of a new account).

This is sometimes called a "cookie block". There are technical details at phab:T5233. Whatamidoing (WMF) (talk) 23:38, 22 August 2023 (UTC)

Username format settled

I've got good news: The team has settled on a username format. We'll go from "192.0.2.1" to "~2024-12345-67". Anyone who has opted in to IP Info (which I recommend; it's currently in Beta Features) will also get the little ⓘ icon to reveal the IP address right on the page. The format is: tilde, year of temporary account creation (≈year of first edit in this account) in YYYY format, hyphen, and a purely numeric account number, broken into groups of five digits from left to right, with a hyphen between each group. (I believe that the last group mostly won't use all five digits; we're expecting to need between 10 and 20 million numbers each year.)

Due to a combination of luck and a Steward already updating the MediaWiki:Titleblacklist to prevent future creation of matching usernames, there should be no conflicting usernames (*whew*). However, bot ops and script writers should detect account status directly, rather than relying on the username format. I'm not 100% certain of the details for this, but I understand that MediaWiki will soon have three user account types, with the result that you'll be able to specify (if you wanted to) different behavior for temps vs IPs. Whatamidoing (WMF) (talk) 15:48, 15 September 2023 (UTC)

Any deep analysis on the impact of IP masking?

Apologies if I'm revisiting a previous question, but have there been any studies regarding the effects of concealing IP edits? I'm interested in comparing content contributions before and after the IP address masking. Specifically, I'd like data on edit counts, new article creation, content quality, IP-based anti-vandalism efforts, etc.  A l p h a m a  ^Talk 07:17, 20 September 2023 (UTC)

@Alphama, IP addresses are still being displayed on all the wikis, and that will continue to be the case until some time next year, so that research isn't possible yet. The team is setting up some metrics to watch, however. Whatamidoing (WMF) (talk) 02:53, 23 September 2023 (UTC)

FAQ

I posted IP Editing: Privacy Enhancement and Abuse Mitigation/FAQ yesterday. Please read it, please translate it, please share it.

If you are looking for technical information, please keep an eye on mw:Help:Temporary accounts/How it works. The product manager is planning to update it with the latest information in the coming weeks.

Also, a quick note about timing: The team is hoping to have this on a test wiki in December. You can test now at https://de.wikipedia.beta.wmflabs.org/ but it's still changing. IP masking won't be on any public content wikis until March 2024 (at the earliest). That said, this is a major project, so if you use or maintain scripts, tools, or bots that might be affected by this, I strongly encourage you not to wait until the last minute. Look into it now, put it on your calendar for December and January, and keep an eye on this page, the "How it works" technical help page, and IP Editing: Privacy Enhancement and Abuse Mitigation/Updates. (Next update there is coming soon.) Whatamidoing (WMF) (talk) 18:13, 23 September 2023 (UTC)

Hello, thanks for your work. I told to a local admin, and they not only want to know if they can see the IP address of temporary account, they also want to know if they can see the IP range. Could you please also clarify this in this section? Thanks. SCP-2000 02:38, 24 September 2023 (UTC)

@SCP-2000, is the admin hoping to see all accounts using a given IP range? Whatamidoing (WMF) (talk) 01:24, 25 September 2023 (UTC)

Yes. Thanks. SCP-2000 01:56, 25 September 2023 (UTC)

The team is working on a new tool to handle this. I haven't seen it myself, but it's supposed to be a new and improved version of https://guc.toolforge.org/ (phab:T337089) Whatamidoing (WMF) (talk) 18:43, 25 September 2023 (UTC)

Hello, @Whatamidoing (WMF): I have a question regarding on the first deployment on temporary account. As I had some tests on Beta Cluster, I know that the temporary account uses CentralAuth system. I can create a temporary account in https://de.wikipedia.beta.wmflabs.org/ and let them automatically created on other wikis. As you mentioned on IP Editing: Privacy Enhancement and Abuse Mitigation/FAQ, temporary accounts may become available on a test wiki in December 2023 or January 2024. Is the test wiki you mentioned are either testwiki, test2wiki or testwikidata? If so, does it do the same on Beta Cluster which I can create a temporary account on those wikis and letting them automatically created on the production wikis (such as enwiki)? If it is true, does it mean that the actual appearance on temporary accounts on production wikis starts when it is available on test wikis? 132.234.229.143 06:15, 24 September 2023 (UTC)

I don't think they know which test wiki will be used. My guess is testwiki or test2wiki, but it depends (e.g., on whether another team needs one of those to be stable for a different project that they're testing).

During the testing phase and even during rollout process, you could be "User:2023-12345-67" on one wiki and still be "User:192.0.2.1" (i.e., your IP address) at another wiki. If you get a temporary account at an early wiki, but then you switch to a wiki that doesn't use temporary accounts, your edits at the later wiki will be attributed to your IP address. A temporary account isn't meant to "leak" to wikis where they're not being used yet. Whatamidoing (WMF) (talk) 01:30, 25 September 2023 (UTC)

Global rollbacker

Will "ip-viewer" be added to GR? This is not clear from [4]. TenWhile6 (talk | SWMT) 09:32, 26 September 2023 (UTC)

I cannot imagine a global rollbacker wither less than 300 edits or 6 months account age... Unless the user is currently blocked from editing more than one Wikimedia project or there are stricter local requirements, they should have the ip-viewer right after optin-in and agreeing to the WMF policy.

But this leads to another important point: Crosswiki patroller such as global rollbacker or global sysops will likely need to check IPs on many different projects. If there is no way to opt-in via Special:GlobalPreferences the opt-in must be done manually on dozens or hundreds of projects (which is what annoys me about the current IP Info feature as well). Johannnes89 (talk) 11:50, 26 September 2023 (UTC)

@Johannnes89 Yes, no concerns, but only (global) sysops were mentioned as groups which hold the rights automatically (and can use it after checking the settings box).

I just wanted to clarify the text - ip-viewer (and ipinfo-full) should be added to the package of rights of GRs.

I fully support your point about the opt-in, without GlobalPreferences it will be very very annoying to do it in every project per hand while the policy is the same everywhere. TenWhile6 (talk | SWMT) 12:59, 26 September 2023 (UTC)

@TenWhile6, @Johannnes89,

Thanks for your questions. I asked about GlobalPreferences and got approval from Legal for that earlier this month. I expect that foundation:Policy:Access to temporary account IP addresses will be updated to endorse this. That question is now headed to the devs to see if they can correctly implement it (i.e., so that I have access on the wikis where I'm qualified but not on others, since I don't have a global user right that would give me access everywhere).

Legal officially approved access to ip-viewer for Global Rollbackers today. The main need is to support clear communication and avoid errors. Global Rollbackers need to be able to communicate clearly about abusers, e.g., by sending e-mail to a global sysop or steward, and this communication will be clearer and more reliable if you can write something like "Please urgently investigate and block IP address 192.0.2.1 for abuse" than "whatever IP address is associated with User:~2023-12345-67".

Global Rollbackers will need to understand and follow the rules at foundation:Policy:Access to temporary account IP addresses#Disclosure. Basically, people with access can publicly disclose IP addresses when that is necessary, but if it becomes unnecessary later, it should be revision-deleted or oversighted (not just blanked or archived). I should see if we can add that to IP Editing: Privacy Enhancement and Abuse Mitigation/FAQ#Project questions (the unfinished section) as well, just to make that information easier for people to find. Whatamidoing (WMF) (talk) 20:09, 26 September 2023 (UTC)

@Whatamidoing (WMF) I just talked with @DerHexer about how to interpret the policy. wmf:Policy:Access to temporary account IP addresses#Patrollers and other users 3.2. requires „a minimum of 300 edits to Wikimedia projects“. Does this mean 300+ edits globally (and meeting the other requirements) allow for IP access on every WMF project?

I initially thought the policy required 300+ edits at the project a user wants to use ip-view rights, but considering wmf:Policy:Access to temporary account IP addresses#Notes and wmf:Policy:Access to temporary account IP addresses#Local requirements („Examples of more restrictive requirements“ -> „Only edits that are to the specific project“) this really means 300+ edits allow for global IP access?

If so, why even bother with defining criteria for admins or global permissions, those users will meet the criteria for patrollers anyway? Johannnes89 (talk) 20:42, 26 September 2023 (UTC)

@Johannnes89, a global sysop will have IP access at all wikis. This decision was made because global sysops are highly trusted users and because they cannot do their work if they do not have access.

You need the ip-viewer user right. Stewards, global sysops, and global rollbackers will have that user right at all wikis, as part of their global role. This will be true even if you have never made a single edit to that wiki. Local checkusers, admins, etc. will have that user right at the local wiki only, as part of their local role. This will be true even if they have not made enough edits at that local wiki (e.g., if a small Wiktionary temporarily recruits a pair of checkusers from a big community to solve a problem they're having).

Editors with no special roles will have to qualify on the basis of local edits. For example, I have no global user rights. If you look at Special:CentralAuth/WhatamIdoing, I will have access at enwiki, enwikivoyage, htwiki, enwikisource, Commons, Wikidata, MediaWiki.org, and here at Meta-Wiki. I won't have access at dewiki, frwiki, jawiki, etc. Whatamidoing (WMF) (talk) 23:21, 26 September 2023 (UTC)

I'll ask Legal again about the editors with no special roles. I'm certain that global sysops will have access everywhere. Whatamidoing (WMF) (talk) 00:28, 27 September 2023 (UTC)

Thanks @Whatamidoing (WMF) for reaching Legal.

Will everyone with ip-viewer also get ipinfo-full? @Johannnes89 already mentioned it somewhere, that it would be good, otherwise Wikimedians with ip-viewer and without ipinfo-full have to copy the IP to something like whois to get the same Information like ipinfo could give. That would be nonsense in my opinion. Is this already clarified somewhere?

In my opinion, the rights should be given together. TenWhile6 (talk | SWMT) 05:22, 27 September 2023 (UTC)

see Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Info feature#Advanced information: I agree that it doesn't make sense to limit ipinfo-view-full to admins/checkusers/stewards when all the information provided can be accessed by non-admin patrollers with ip-viewer permission anyway by just using external tools to analyse an IP address. Johannnes89 (talk) 06:21, 27 September 2023 (UTC)

@TenWhile6, the product manager is planning to post a table outlining, e.g., the checkusers get everything but admins can't see the log, etc. I believe that table cleared Legal review yesterday afternoon and just needs to be shown to the devs, so that we're not promising something that they can't deliver.

I want to say now that the table is a bit confusing, because it says that admins have (e.g.,) ipinfo-view-full but bureaucrats don't. This doesn't mean that they're taking it away from the bureaucrats. It just means that there is nothing about the bureaucrat role (i.e., assigning additional user rights to others) that directly involves vandals and abuse. (Also, I understand that all the bureaucrats are admins anyway, and it's unnecessary to give it to them twice.) Whatamidoing (WMF) (talk) 16:31, 27 September 2023 (UTC)

@Whatamidoing (WMF) thanks for clarifying! I suggest changing the policy to avoid confusion. „300 edits to Wikimedia projects“ sounds to me like „300 edits globally to Wikimedia projects“ instead of „300 edits to this specific Wikimedia project“. And the example for local, more restrictive requirements „Only edits that are to the specific project“ doesn't make sense to me if the 300 edits are meant to be local edits anyway.

Regarding global sysops: How will global IP access be achieved on a technical level? Unlike global rollback this user group is not truly global (see Special:WikiSets/7), that's why currently ipinfo-view-full only works on GS-wikis for me. --Johannnes89 (talk) 06:52, 27 September 2023 (UTC)

Good point, I also saw the optional requirement in the policy. TenWhile6 (talk | SWMT) 07:17, 27 September 2023 (UTC)

@Johannnes89, @DerHexer, I've been able to confirm that they were previously going to make it a global edit count, and that's what's in the policy, but because of Special:GlobalPreferences, they might make it depend on the local wiki count.

I'm not sure if they will have an answer to this question before your presentation at WikiCon this weekend, but @MMoss (WMF) is the lawyer coordinating the decision about this, and she's super helpful. If they have an answer before your presentation, I'm sure she'll post it here for you. She has promised me that she will make the answer clear and unambiguous in the policy.

Und nun muss ich auch sagen: As you may have seen at the Kurier, I am reclaiming my volunteer status at the end of this month, which is just a couple of days from now. I know that we can get through the inevitable bumps and frustrating delays that this project will entail if we work together. You can find me on the wikis whenever you like at WhatamIdoing. Perhaps I will even come over to the German-language Wikipedia to write a few simple sentences some time. Whatamidoing (WMF) (talk) 00:11, 28 September 2023 (UTC)

Thanks for asking and in general for your work communicating these changes! Johannnes89 (talk) 19:10, 4 October 2023 (UTC)

IP as an indicator of reliability of edits

quite often i would click the "geolocate" link to check the location of ip. it helps to determine whether certain edits are probably helpful (made by people with the specific knowledge), or test/vandalism (made by people who're quite unlikely to have the knowledge).

now this use would be gone for most editors. RZuo (talk) 18:06, 5 October 2023 (UTC)

Hello @RZuo. Yes, you're correct, this will be gone for most editors. Even though most patrollers continue to have access to the full IP info feature, using geopositioning to assess if the edit may be factually correct is not within the purpose of having this information in the first place. It's more like a side-effect. Privacy-related reasons do take precedence.

I think this may be a good topic for conversations in individual communities – what to do with unclear cases given that less data about internet users is public. And that is an external trend. SGrabarczuk (WMF) (talk) 19:07, 5 October 2023 (UTC)

you talk about privacy. do you also include an option for ip users to willfully reveal their ip? there're users that deliberately edit without logging in, because they think revealing nothing but their ip is safer than an account.

it's not so straightforward to track down a person who's using different ips, but using an account makes it super easy to find out an account holder is using certain ips, which in turn would reveal more info about their real life.

in big cities, it's also common when those users edit using public computers/networks, which are often used by multiple persons. without an account it's harder to tell them apart. that's the art of hiding in the crowd.

so, all the talk about privacy is rather bullshit. ips are better than accounts in terms of privacy consideration.

in fact, the best thing to enhance privacy protection is to allow proxy ips. how about that? RZuo (talk) 19:34, 5 October 2023 (UTC)

If editors are not given the option to refuse all cookies and be identified for attribution purposes by IP address the scheme will not be legal [5]. 89.240.116.163 22:55, 6 October 2023 (UTC)

"Any time", really?

Moved from Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/FAQ

Should "Any time you publish an edit on Wikipedia or other sites hosted by the Wikimedia Foundation without logging into a registered account" (why mention Wikipedia in particular?) be replaced with something like "any time you publish an edit ... without logging into a registered account or being logged into à temporary account" (because a new temporary account will generally not be created for each edit)? Apokrif (talk) 10:14, 6 October 2023 (UTC)

Thanks @Apokrif, that's a good point, I will change this sentence. SGrabarczuk (WMF) (talk) 13:19, 6 October 2023 (UTC)

phab:T300265

As the username of the temporary account is start from ~, this task should be renamed to “Inform username accounts prefixed with "~"” if the plan of renaming all accounts start from ~ still exist. 132.234.229.68 02:13, 19 October 2023 (UTC)

Hello! Thanks for bringing this up. We haven't changed this because we're not 100% sure what the prefix will finally be, whether it would be a ~, or ~2, or perhaps even ~20. We'll start announcing this months before making the changes on wikis. It seems that the first deployments will happen in April, May, or even a bit later (there's a delay compared to the dates shared in the latest update.) SGrabarczuk (WMF) (talk) 13:23, 23 October 2023 (UTC)

It seems that the first deployments will happen in April, May, or even a bit later First I've heard of this. Where else has this been shared, and what's causing the delay (insofar as you can disclose)? Nardog (talk) 12:26, 24 October 2023 (UTC)

Hey @Nardog. You're totally right to be hearing this first time, because it's the only time anyone has wrote exactly this so far :D

The only source is a hint in the latest update. Specifically, the sentences: "This change to the structure may have an effect on the timeline of this project. We will have more updates to share as we develop a roadmap for the new team." The word "may" is used there because when we were drafting that, we didn't know what changes would happen, but we knew there may be some. Now we know that there will be some delay indeed. When we agree on a new roadmap with specific timelines for different projects, we'll post a new update.

Thanks! SGrabarczuk (WMF) (talk) 16:10, 24 October 2023 (UTC)

I get that any future date is subject to change. I also know the Earth is round. I asked specifically what the changes you now know will happen that are causing the delay are. If you can't divulge that then that's fine, say so, but frankly if what you've written is all you can say I wish you hadn't said anything because it's just condescending. Nardog (talk) 16:46, 24 October 2023 (UTC)

I'm sorry to read that. I didn't want my comment to feel condescending. We're discussing the new roadmap, and I don't have anything specific to share yet. SGrabarczuk (WMF) (talk) 17:20, 24 October 2023 (UTC)

@SGrabarczuk (WMF): I would suggest that the prefix should still remain ~. If you set the prefix to ~2, there will be a problem when it approach to year 3000 (though there is still a long time) or year 2100 if using ~20 as the prefix. 132.234.228.96 03:15, 27 October 2023 (UTC)

Hi @SGrabarczuk (WMF): What is the current plan of renaming those users? Are all users with prefix ~ will be renamed or just some of them will be renamed? And also what is the target names (or the target prefix) those users will be renamed to? 132.234.228.16 04:12, 2 December 2023 (UTC)

Will this be a feature on just Wikimedia's sites...

...or will it be native to the MediaWiki software itself in the near future? (H/T mw:Project:Support desk.) --Slgrandson (talk) 23:46, 27 October 2023 (UTC)

It is a MediaWiki core feature, controlled by $wgAutoCreateTempUser (plus disabling IP editing by setting $wgGroupPermissions['*']['edit'] = false for some reason, maybe just to make sure? or does it make a difference?). —Tacsipacsi (talk) 22:44, 28 October 2023 (UTC)

Finding out what Wikimedia is doing to your computer

Everything has gone quiet. My "cookie settings" display currently shows:

Cookies in use

The following cookies were set when you viewed this page

>en.wikipedia.org

>wikipedia.org

Name............No cookie selected

Content.........No cookie selected

Domain..........No cookie selected

Path............No cookie selected

Send for........No cookie selected

Created.........No cookie selected

Expires.........No cookie selected

Select........................Done

About en.wikipedia.org

Connection is secure..........>

Permissions for this site...Tracking prevention OFF

Cookies (2 cookies in use).......>

Tracking prevention for this site (Balanced)

Trackers (0 blocked).............>No trackers were blocked on this site

If this crazy scheme gets off the ground, how will the display change? Immediately after editing the unregistered editor clears the surveillance cookie (see the discussion at en:User talk:Risker#IP Block Exemption). She then edits again. Will the cookie be added back? If it is, that's what I would call online harassment. 62.140.210.130 16:42, 26 November 2023 (UTC)