Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

About IP Editing (discuss)
About IP Addresses (discuss)  · IP Editing Restriction Study (formerly Login Required Experiment) (discuss)

IP Editing: Privacy Enhancement and Abuse Mitigation Archive index
This page is to collect feedback for the privacy enhancement for unregistered users project.
Hoping to hear from you. You can leave a comment in your language if you can't write in English.
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 Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Archives.

Please remember that this page is used by people from a number of communities, with different native languages. If you avoid using acronyms from your home wiki, that will help them participate in the discussion.


How will I able to find my contributions? Will be there way to say to the site that I want to save my edit under IP? 17:25, 10 November 2021 (UTC)[reply]

Much like today! They will be tied to your identity; how said identity is to be defined is up for discussion (see above and the update on the main page). It won't last forever, of course, but then again – no unregistered identity does. Including IPs. /Johan (WMF) (talk) 01:12, 11 November 2021 (UTC)[reply]

It’s the way to finally force anyone who needs that to register. — 23:50, 10 November 2021 (UTC)[reply]

That's not our intention here, at least; then we wouldn't spend so much time and effort trying to make masking work. /Johan (WMF) (talk) 01:12, 11 November 2021 (UTC)[reply]
"It’s the way to finally force anyone who needs that to register."
"That's not our intention here..."
Why? Why are we all going through all this... effort, when simply going to mandatory account creation, across the board, would solve most, if not all, of these concerns with IP-editing, IP-privacy, IP-vandalism, IP-socking, etc., etc.? And, even if there are any 'cons' to mandatory registration, do they outweigh the 'pros'...? (jooc) - wolf 09:11, 25 January 2022 (UTC)[reply]

IP-based versus session-based masking: Why not both?[edit]

Consider this sequence of events:

  1. Alice makes an edit from, but does not clear cookies afterwards
  2. Alice makes an edit form, but remembers to clear cookies afterwards
  3. Alice makes an edit from

Now either IP-based or session-based masking "break the chain" at some point. But what if these edits are publicly logged as:

  1. Masked User 473982743:47982
  2. Masked User 027469812:47982
  3. Masked User 027469812:51023

Now everyone can see that there is might be one user behind all these edits, but we haven't given up her IP. Suffusion of Yellow (talk) 20:10, 15 November 2021 (UTC)[reply]

  • Third "Alice makes an edit from" is indistinguished from "Bob makes an edit from" so an assumption that all 3 edits are from one user is incorrect. The correct assumption is that Alice and Bob have the same IP, and then if we somehow know Alice's IP we know Bob's IP as well. This is a minor threat but still a threat. (In my opinion this is not so far from giving plain IP. Changes are redundand in such case). --Igel B TyMaHe (talk) 08:13, 16 November 2021 (UTC)[reply]
    Good point. This threat also applies to a pure IP-based masking scheme, too. Combining both schemes doesn't make it any worse, unless I'm not thinking of something. Suffusion of Yellow (talk) 23:23, 16 November 2021 (UTC)[reply]
    This starts to get into a meta-discussion (not the project) IMO about what actually constitutes a unique user. Certainly Alice and Bob are two distinct people. But if they are using the same IP and the same browser on the same device without any additional identifiers (like credentials or a token), are they actually a distinct user? Anyhow, the hybrid approach proposed above does seem like it would eliminate some of the concerns around the limitations of either implementation. SBassett (WMF) (talk) 22:12, 18 November 2021 (UTC)[reply]
    Might I suggest that the "MY LITTLE BROTHER DID IT" essay may hold some relevance to SBassett's question about a unique user. If abuse is coming from an IP, we block it. When blocking an IP, we aren't exactly blocking a person, but rather a connection to the internet. This wouldn't be any different, and Bob still gets blocked for what Alice did. The difference is that, Charlie, who just got Alice's IP, doesn't get blocked, as we could see that Alice definitely changed IP address so it would be pointless to block the one she has moved off. Mako001 (talk) 12:34, 13 January 2022 (UTC)[reply]
  • I like this hybrid approach. ProcrastinatingReader (talk) 19:56, 10 December 2021 (UTC)[reply]
  • I like the hybrid approach. Details that need to be worked out are the retention policy for the data. We need to consider scenarios where an authoritarian government (1) grabs a user's computer and checks their cookies, and (2) breaks into a WMF server and steals our logfiles. What policy strikes a reasonable balance between allowing WMF to defend its websites, and prevents our data from falling into the wrong hands and causing real life harm to a user or even a mere visitor to the website? This problem is deep and will require ongoing thought and research, regardless of which path is chosen. Jehochman (talk) 18:22, 4 January 2022 (UTC)[reply]
I guess that if an authoritarian government actually grabbed someone's computer, the cookies would be fairly irrelevant, browsing history would likely be enough, and we can't do anything about that. The idea of the whole IP masking thing is to avoid the situation where they actually do grab it. Mako001 (talk) 12:34, 13 January 2022 (UTC)[reply]
  • Indeed I see advantages in the hybrid approach too. --.mau. ✉ 18:25, 4 January 2022 (UTC)
  • Yes, using both is certainly an improvement to either. I also don't see why IPs from the same range editing the same page can't be tagged as possible socks (or some less accusatory wording). They are both still remain masked. This is not just a vandal fighting issue, ordinary collaborative discussions are affected. Conversations on talk pages will start to become really difficult when unregistered users get involved. At the moment, it is faily obvious when the same person makes another reply, even from a dynamic IP. With masked IPs this could get very confusing unless there is some kind of marker. SpinningSpark 18:56, 4 January 2022 (UTC)[reply]
  • I am also interested in seeing what a hybrid approach would look like. Will there be a trial period with specifics before we decide definitively which approach (or both?) will be used? Spencer (talk) 03:34, 5 January 2022 (UTC)[reply]
  • I also agree with a hybrid approach, but where the IP is not necessarily transparent. So, besides getting a session handler (e.g. anon-1fe49afc7bc5), for whom we can see the User contributions, we can also have an list of IP anonymised identifiers for that user (which might be shared by different anonymous users), and direct access to any contributions done each (still hidden) IP, and we are still able to (temporarily) block anonymous contributions from a given IP (even without seen it!), or pass it forward to a checker for more information if necessary. MarianoC 10:48, 7 January 2022 (UTC)[reply]
  • I like this approach, too. It could even be improved further by including a hash for the IP range (first three numbers) only: then one would see that all edits are from the same range without knowing the range... --Qcomp (talk) 13:47, 7 January 2022 (UTC)[reply]
  • Support, came here to suggest this, along with an explicit nod to basic hashed fingerprinting. That also elevates the feel of the whole project from "switch from one suboptimal solution to a second suboptimal solution, with added transition costs and confusion" to "extend current system to add more useful nuance + make everyone's lives easier" ;) –SJ talk  17:16, 7 January 2022 (UTC)[reply]
  • I also like this approach, but there are a lot of users if the IPs or cookies changes, and it's hard to discuss with masked usernames in this way. However, it can be inferred that it would be easier to combat vandalism, if we use both cookies (one cookies) or IPs IP editing. The cookies show that an temporary account for IPs are disappeared frequently, once cookies changes, the edit would be lost. Thingofme (talk) 11:58, 8 January 2022 (UTC)[reply]
  • Yeah, this should be the #1 option. Makes it much harder to evade scrutiny, ab-users will inevitably forget to always change both the IP and the Cookie. Assign the cookie to all users, registered ones too. Would give CU's another way of tracking down sockpuppeteers.Mako001 (talk) 12:21, 13 January 2022 (UTC)[reply]
  • I agree, combining both IP-based and session-based identifiers seems to be more useful than using either of these alone. Sintakso (talk) 17:33, 19 January 2022 (UTC)[reply]

IPv6 and privacy[edit]

"Users well-versed with IP addresses understand that a single IP address can be used by multiple different users based on how dynamic that IP address is. This is more true for IPv6 IP addresses than IPv4."

Actually, for purposes of privacy, IPv6 can be considered to be essentially static. Each user is assigned many IPv6 addresses, but each address belongs only to a single Internet connection (router), as opposed to a many-to-many relationship between dynamic IPv4 addresses and users. Hence, the IPv6 range assigned to a single household (it seems it's usually /64) is as personally identifiable as a static IPv4 address. Daß Wölf 19:48, 20 November 2021 (UTC)[reply]

  • No, IPv6 is protected against such a simple detection of a user as "privacy extension". Usually an IPv6 address is issued for 1 day, then the client receives a new one. Old IPv6 addresses respond 1 week. Also, new IPv6 is usually issued upon reconnection.

You also need to understand that IPv6 segments have a capacity of trillions of numbers. Therefore, mobile operators often create one IPv6 segment for the entire country. Therefore, if a vandal works from such a segment, you can neither block him by IP, nor even understand what city he is in.

An additional point is that it is rather difficult to apply masks to IPv6 addresses. The "user interfaces" portion of the address is actually under the control of the client. This leads to the fact that within one IPv6 segment, all users are fundamentally indistinguishable.

Vandals will not need open proxies in the near future, because their smartphone is enough for them to "crack" the protection of Wikipedia.

In the near future, IPv6 will replace IPv4. In the US, over 40% of connections are already IPv6.

Everyone who is crying here about blocking vandals' IP addresses needs to understand that in the next few years, IPv6 addresses will make it almost useless to study them, as blocking masks, and it will be impossible to block IPv6 segments. Blocking the IPv6 segment of a mobile operator means cutting off millions or even tens of millions of people.

Instead of suffering about getting into someone else's personal data, it is better to think about modern means of identifying anonymous users, which using modern technologies. This tech are NOT based on IP addresses, but are based on fingerprints based on the characteristics of browsers and hardware. This is similar to User Agent, but much more selective (identification accuracy is higher than 99.999%). Also, you will not be able to understand that User Agent is being faked for you. Modern fake addons like "Random User Angent" choose very realistic options from templates. However, browsers' fingerprints are blocked now very roughly and it is easy to understand what the user is doing. Such users can be blocked as users of open proxies are now blocked.--2A00:1FA0:C433:8FC2:ACAE:2BAC:619E:8195 16:30, 21 November 2021 (UTC)[reply]

If this really is as technically feasible as claimed, it is a great idea. SpinningSpark 18:57, 4 January 2022 (UTC)[reply]
Practically all websites that use fingerprinting abuse the unique identifiers that it exposes. Users should not be blocked for rightfully protecting themselves against fingerprinting. If the rest of the web did not abuse this technology I would agree though. PJvanMill (talk) 15:36, 26 February 2022 (UTC)[reply]


So, very soon we'll be sending out a notice to all admins. (This might include some people who very recently were admins, but are not longer, and exclude some who very recently became admins.) This is not because we're interested only in their opinion, but because it's one way we've identified to reach out to the communities and people who are likely to be active in vandal-fighting, without spamming every content contributor.

We're specifically interested in feedback on the solutions we have listed in IP Editing: Privacy Enhancement and Abuse Mitigation#IP Masking and how to protect the wikis (9 December 2021 Update). We're of course open to feedback on everything else, too. And I figure we'll get some "why are you doing this?" again, so I'll just point out again that we're doing this because the Wikimedia Foundation Legal department has told us it needs to happen, because of changing regulations and norms around privacy – the regulations are not the same today as they were in 2001. /Johan (WMF) (talk) 13:45, 4 January 2022 (UTC)[reply]

  • @Johan (WMF): I got the message three times (admin on three different wikis). If you can't even tell that an admin is the same user across wikis, I'm not convinced that "Session based identity" will help at all with cross-wiki spam compared to sticking with IP addresses or a direct analogy. Thanks. Mike Peel (talk) 18:27, 4 January 2022 (UTC)[reply]
    The easiest way to make sure all administrators are notified is to notify all administrators on all wikis. Inventing a way to remove duplicates and to prioritize wikis (per edit count? per importance? Did you expect a notification on wikidata or enwiki?) is largely unnecessary. ToBeFree (talk) 18:33, 4 January 2022 (UTC)[reply]
    Ain't that one of the good things of SUL, that you know such stuff and just send it to the Homewiki? It's not even necessary that it's a Wiki where s/he is sysop, it's just home base. Grüße vom Sänger ♫(Reden) 21:47, 4 January 2022 (UTC)[reply]
    I'm sure the complaint would then have been "Why have I received this message on the wrong wiki? I [could] have turned off notifications there." ToBeFree (talk) 23:41, 4 January 2022 (UTC)[reply]
    This —TheDJ (talkcontribs) 10:51, 8 January 2022 (UTC)[reply]
  • I'm an admin on several wikis, and I also administer single sign-on for a major university as my career, so I'm familiar with changing privacy norms around the web. I'm not at all surprised to see IP-based identification going away. While IP masking would work, I'd be in favor of switching to a session-based identity path. I think this is the more solid and user-comprehensible approach, and it opens better opportunities for anonymous editing in the future. I'm happy to see WMF dealing with this issue proactively.– Quadell 18:29, 4 January 2022 (UTC)[reply]
  • That said, I'm not sure at all this measure would protect any contributor from government's prosecution: a malicious government might create an user that gain adminship privilege and the IP privacy measure is made ineffective. -- Blackcat Ar Icon Contact.svg 18:31, 4 January 2022 (UTC)[reply]
    • Outside the US, if I remember my experience working for a supplier for Deutsche Telekom correctly, governments in many countries (except the US) can gain access to phone/internet details very easily -- although it is far more difficult, if not impossible for corporations to get this information. On the other hand, it is difficult for the US government to gain access to those details (who must seek a court order) while it is very easy for corporations to get it. (And thru these corporations, foreign countries can buy the information either directly or thru a strawman intermediary. There's less privacy out there than we know, dammit.) -- Llywrch (talk) 21:23, 4 January 2022 (UTC)[reply]
      • @Llywrch: I'd be less worried by a corporation rather than a malicious government, but my point was that you cannot declare "private" an IP address then let an admin disclose it. We do not have a policy for admins and admins are anonymous. To be consistent, WMF should issue a rule that whoever has sysop upwards privileges must be disclosed and cannot be anonymous. -- Blackcat Ar Icon Contact.svg 23:40, 4 January 2022 (UTC)[reply]
        I think that if people can't be trusted to see the whole IP address, then people should not be trusted to see the partial IP address. Only checkusers can see the IP address made by anons, and block IP ranges (IP range block log should be kept private to only checkusers). Also, the Confidentiality agreement for nonpublic information must be rewritten and existing functionaries should sign again. Thingofme (talk) 09:54, 8 January 2022 (UTC)[reply]
  • I prefer the session-based approach. It provides more value in being able to identify and communicate with legitimate anonymous editors. However, at the same time, we need abuse filter options to be able to identify multiple new sessions from a single IP. These could be legitimate (from a school, for example), but will most likely represent abuse or bot activity. One feature I haven't seen mentioned yet. When a session user wants to create an account, it should default to renaming the existing session ID to the new name of their choice. We need to be able to see and/or associate the new named user with their previous session activity. -- Dave Braunschweig (talk) 18:37, 4 January 2022 (UTC)[reply]
    Hello Dave, when a session user creates an account we are planning to not carry over their edits. This is because we can’t be sure that the device was used by a single person (the one now creating the account) and therefore shouldn’t attribute all the edits to them. This could be common on public or family computers for eg. ––STei (WMF) (talk) 14:46, 13 January 2022 (UTC)[reply]
  • The ability to perform purely session-based blocks in addition to the existing IP+session blocking would be an interesting upgrade. Being able to communicate with IPv6 users through their session instead of their repeatedly changing IP address would also be a benefit. ToBeFree (talk) 18:42, 4 January 2022 (UTC)[reply]
  • @Johan (WMF): Not an admin but saw this on various talkpages I'm watching. I noticed the message said "There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right". Who does "patrollers" refer to here? New page patrollers? Recent changes patrollers? Something else? I do think this right would be somewhat useful for the work I do patrolling. Elli (talk) 18:46, 4 January 2022 (UTC)[reply]
    Anyone is equally welcome to comment! ("[N]ot because we're interested only in their opinion", as I wrote above.) Who would need this user right would be largely for the local community to decide. Anyone involved in vandal-fighting (or who needs it for some other reason) who lives up to some simple requirements, and can be granted the right through some sort of simple community process. I would personally find it more useful when patrolling recent changes than when looking at new pages on my home wiki, but I don't imagine we know all potential needs. Johan (WMF) (talk) 18:54, 4 January 2022 (UTC)[reply]
    Including it in dewiki's "Aktiver Sichter" and enwiki's "rollbacker" could be an idea. The former is assigned automatically according to rather strict criteria. Is manual assignment a strict requirement? ToBeFree (talk) 18:58, 4 January 2022 (UTC)[reply]
  • I remain a steadfast IP anti-masker, but I feel that my opinion probably won't change things at this point. I'm grateful as an enwiki admin for the ability to still see IPs to block malicious ones. This will probably speed up the already-inevitable path to mandatory registration on enwiki, I think. John M Wolfson (talk) 18:49, 4 January 2022 (UTC)[reply]
    • @John M Wolfson: indeed I am almost completely agreeing. In order to fix a minor problem we are creating a bigger one. At this point either a) allow open proxies to avoid IP addresses to be tracked or b) impose mandatory registration. WMF seemingly chose to hide IP addresses from malicious eyes though admins, that can see those IPs, are largely anonymous. -- Blackcat Ar Icon Contact.svg 23:45, 4 January 2022 (UTC)[reply]
  • Anyone seriously interested in vandalizing or evading our controls will be using more than a a single computer or single browser. So do many good-faith users (I currently use ≥3 at least occasionally) They are usually but not always working from the same router, and I almost always use the same browser, but not necessarily the same version. If I were an ip unregistered user, trying to link what I do via session-based cookies would seem to be useless. DGG (talk) 18:56, 4 January 2022 (UTC)[reply]
    • There certainly would be an incentive for good-faith unregistered users to use an account. I'm not certain that's a bad thing. LtPowers (talk) 19:00, 4 January 2022 (UTC)[reply]
  • Based on a quick perusal of the issues, session-based IDs seems like the best solution. LtPowers (talk) 19:00, 4 January 2022 (UTC)[reply]
  • In the session based model, will we be able to see all sessions belonging to a given IP? Kusma (talk) 20:11, 4 January 2022 (UTC)[reply]
    @Kusma -- that's definitely possible to do by building a tool which exposes that to users who have IP-address access. It's also possible to do the reverse -- see all IPs associated with the same session which we are planning to expose with the help of the IP Info feature. -- NKohli (WMF) (talk) 12:21, 4 February 2022 (UTC)[reply]
  • Hi Johan, I (and presumably all the other admins) just got the message. Since most of it I've already discussed with you, I was just wondering why it places "norms" before "regulations" in the reasoning for why. I thought we'd settled that regardless of if they have or haven't changed in this way, Legal have no right to change things on that basis, and using it as cover is not acceptable for a top-down imposed change Nosebagbear (talk) 21:40, 4 January 2022 (UTC)[reply]
    Changing norms lead to changing regulations, is probably how my mind went at the time, but it was weeks ago, so honestly I couldn't tell you. This is me putting together a very brief explanation in a message I wanted short enough for people to feel they had the time to translate it. I wouldn't read too much into it. (: Johan (WMF) (talk) 23:20, 4 January 2022 (UTC)[reply]
  • Considering there has been near-unanimous opposition to this IP masking since day one and "But WMF legal told us to!" is the only reason anyone is pushing this and as more and more Wikimedia projects adopt the required registration policy I think simply implementing that globally would be better than this absolute mess. Don't solve a tiny problem by creating a much larger one. Naleksuh (talk) 23:53, 4 January 2022 (UTC)[reply]
  • I understand why this happens, but I think it is very close to seriously damaging our capacity to administrate wikis:
    • If a user edits on two wikis simultaneously from the same device/browser (e.g. creates an articles and adds a link to Wikidata), whatever the scheme, the identifier absolutely must be the same (otherwise it is just useless). If a user adds similar nonsense pages to all wikis, but they are Anonymous1235 on enwiki, Anonyme245 on frwiki and Анонім74 on ukwiki, we will need a steward to find this out, while today any bystander can detect this.
    • For session-based identifiers, I would really like us to use a MAC address rather than a cookie. Cookies are very easy to circumvent, and I don't think cookie restrictions will be any efficient against vandals. It would really be a cat and mouse game: an admin blocks by cookie, a vandal deletes it and can edit again immediately. A vandal can literally change their identifier after every single edit, and this change will take just 1-2 sec (restarting a router to get a new IP address for a dynamic range usually takes 1-2 min), which makes circumventing restrictions unreasonably easy. Unless our vandal has zero IT skills, this would be completely useless as modern browsers allow to purge cookies very easily (or offer quick access to private mode).
    • If using MAC addresses is not possible, keeping blocks by IP addresses is the best option. This approach has lots of disadvantages, but at least we know how to deal with it. However, there are two important conditions.
      • We absolutely need a replacement for range identifiers, notably for things like 3RR, bans and filters. Today we know that three anonymous reverts in a row made from the same range are almost surely the same person (more rare the range is, more likely is this fact). In future we would need to easily find out if these three anonymous edits are coming from the same range or from completely unrelated ones. There are significantly more use cases, for instance, we have AbuseFilters targeting some very specific behaviour from specific ranges. The most common tools we need would be <do anons X, Y and Z come from the same range> or <check all edits from X's range>. We can do it in a smart way, e.g. automatically querying WHOIS to get the respective range of the provider, or automatically checking provider's IDs to identify a different range of the same provider.
      • We need to prevent extra burden on admins. Anonymous edits are already quite hated by our admins. If these changes will mean that non-admins can do literally nothing with an IP edit (cannot check what other edits on this topic were made from this range, cannot check if they circumvent sanctions etc.), this would put an unreasonable burden on admins. I don't believe we would magically get more admins, so quite likely we will just end up doing what the ptwiki has done and ban IP edits altogether.
  • To sum up: session blocks are OK only if we use MAC addresses instead of cookies, IP bans are OK only if we have a good replacement for range tools for non-admins; both need to keep identifiers consistent cross-wiki. If not, banning IP editing altogether seems just the simplest option — NickK (talk) 00:00, 5 January 2022 (UTC)[reply]
    There is fortunately no way for an internet website provider to obtain the MAC addresses of their clients. This would be a privacy nightmare. IPv6 users can use their MAC address to generate an address in their /64, but this method is usually disabled for privacy reasons. Instead, a random address is generated ("Privacy Extensions", RFC 4941). ToBeFree (talk) 02:17, 5 January 2022 (UTC)[reply]
    @ToBeFree: Thanks for this clarification, I did not do any research into it. Thus our only option to ban a specific device is setting a cookie that a vandal can immediately delete? Or do we have any better option? For instance, pairs <IP+port> might be good in many cases, although we are not using them now AFAIK. It would be good to have a brainstorming on what our options (even if not readily available now) are — NickK (talk) 20:10, 6 January 2022 (UTC)[reply]
    A new source port is used for each connection, to separate them from each other. Connection reuse for multiple requests to the same server is a thing, but there may be multiple connections to the same server to improve performance, and at very least closing the browser and re-opening it throws the connections away. TCP/UDP source ports are thus less useful than IP addresses and cookies for any kind of identification.
    The thing is, if there was something more identifying than cookies (Browser fingerprinting has been mentioned above), then using it for identification would contravene the idea behind the whole action: Improving users' privacy. So even if there is something that could be technically used in place of the IP address, it won't be used for exactly the same reasons. ToBeFree (talk) 23:26, 6 January 2022 (UTC)[reply]
    Ah, and to address your banning concern: We can still see and block IP addresses, they're just not public anymore (#Blocking unregistered editors). ToBeFree (talk) 23:29, 6 January 2022 (UTC)[reply]
    @ToBeFree: Well, my main concern is: we are deciding what identifiers will see most registered users. The problem is that there are two separate approaches: we do want to protect privacy of good-faith casual unregistered contributors, but we need to be able to fight annoying unregistered vandals. There are way more non-admin vandal fighters than admins (perhaps at least by a magnitude of 10). I want to have some meaningful approach that would allow non-admin vandal fighters understand which vandal they are dealing with, otherwise we would have a real communication problem between admins (who do see IPs) and non-admins (who would have some weird identifiers). While I would definitely prefer a cookie identification for a 60-year-old lady contributing from time to time on the same topic but having no idea how IPs or registration work, I do want to have an IP (incl. range and provider) identification for a 16-year old geeky vandal who knows how to delete cookies or get a new dynamic IP.
    Regarding ports, of course I mean IP + port pairs as a way of identifying distinct connections, particularly for dynamic ranges. We already have this data somewhere and it is quite an industry standard, thus I think it is an option that should be explored and might be helpful — NickK (talk) 21:48, 10 January 2022 (UTC)[reply]
    Fortunately, there will be a user right we can give to non-admin vandal fighters to let them view the IP address ("The IP address itself will be visible to administrators and patrollers"). Perhaps it can even be given to all members of existing antivandalism groups such as enwiki's "rollbackers", or even to all members of automatically assigned groups such as dewiki's "Aktive Sichter". We'll need details about this (18:58, 4 January 2022 (UTC)).
    IP+port pairs are being used to identify connections all the time; that's their technical purpose. Displaying source ports to users – randomly generated, meaningless numbers up to 65535 – doesn't provide any benefit, though. ToBeFree (talk) 22:57, 10 January 2022 (UTC)[reply]
  • The session identity needs WAY more thought before rolling out. Cookie-based session identities? Come on now! That is way too easy to circumvent, which the deliberate miscreants will do anyway, negating any benefit that might have come from it. NickK has a good point that MAC addresses would be better. There is no harm in rolling out IP masking first. It doesn't change anything from the administration side, causes minimal disruption to existing workflows, and preserves privacy (particularly editors in countries like China who are hesitant of repercussions editing here). Anachronist (talk) 02:04, 5 January 2022 (UTC)[reply]
  • As long as IP based blocking remains possible, it seems like the session-based approach has some advantages. I don't think session-based blocking will be useful, almost everyone knows how to clear cookies. -- hgzh 14:58, 5 January 2022 (UTC)[reply]
  • Sorry ToBeFree however extraction and use of client MAC addresses is quite common. There are a number of open-source and commercial products available to do this (the IP stack is quite simple and open, however that's another story, should never have seen the light of day). It would not be difficult to extract MAC & IP and create a hash to be used for display purposes. It then creates an almost unique handle identifying IP editors, though obviously not as specific as a login, identifying only the device, however pretty close. Admins would need a tool for lookup for compare purposes, 'is this the same IP and a different device or perhaps a different IP and the same device' as that's the granularity that could be made be available, while hiding actual values from most. Would make sockpuppetry, etc, even easier to detect, to some degree. This is nothing new, it's an operational requirement in network providers all over (they don't bother creating hashes though!). Neils51 (talk) 22:26, 3 February 2022 (UTC)[reply]
    Neils51, the client's MAC address is never transmitted to the HTTP(S) destination; it is removed by the client's gateway to the Internet. ToBeFree (talk) 07:40, 4 February 2022 (UTC)[reply]

Can unregister user use username without password?[edit]

I think unregistered users must give a choice to make usernames without passwords. I mean when an unregistered user click on edit, he/she will see a popup showing some alphanumeric usernames or a text field that allow them to create a username without a password? Such usernames may have their separate namespace.--Ameen Akbar (talk) 20:50, 4 January 2022 (UTC)[reply]

I agree, it would be nice to let users that aren't logged in to identify themselves somehow. 20:54, 2 May 2022 (UTC)[reply]
I disagree on this however this may result in impersonate unless we define that anonymous username cannot uses for identify individual, in additional I think doing this have no significant good reason for Wikimedia communities. --NP-chaonay (talk) 13:10, 4 May 2022 (UTC)[reply]
For me if public-hidden IP is implemented, I think it best to use something that can uniquely linked to IP address without reveal of the IP address, instead of using username (or assume that you agree on username for unregistered, let Wikimedia shown both username and unique ID), in this way anyone who cannot access IP-user's IP address can able to distinguish and report ip-user behaviour. NP-chaonay (talk) 13:17, 4 May 2022 (UTC)[reply]

Concerns by an IP editor[edit]

I have been editing as an IP for a while (there are reasons for it), and I feel that this proposal may be for the worse. Because my IP changes over time, with the first approach it would be completely different each time it changed, and I couldn't be a "range", but a semi-random set of IPs, which would make it hard for non-admins to know all the IPs are me. Similarly, with the second approach, I clear my cookies very frequently, so that'd be worse. What can I do (apart from registering)? -- 03:01, 5 January 2022 (UTC)[reply]

If you had an account, you could add your IPs to your user page – I don't know if the issue is about not registering or not logging in.
There could be an interface for copying your session cookie and reusing it in the next session. Depending on how those cookies are stored and checked at the server side you could do it manually, but support could be included in the web interface, allowing any users to save and reuse the cookies.
LPfi (talk) 13:30, 13 January 2022 (UTC)[reply]
Thank you for sharing your thoughts on this as an IP editor. With the encrypted IP method people won’t be able to see the range from which you might be coming; only those with the Admin or IPViewer role would see that. In the session approach, as User:LPfi mentioned there might be some ways to keep the same identity. Maintaining a list of all temporary user accounts that you’ve had in the past on your current temp user page would be cumbersome but one way to maintain identity. Browsers also support clearing only certain cookies and leaving some be, that approach would make things easier for you. –– STei (WMF) (talk) 17:25, 19 January 2022 (UTC)[reply]

They need to know their IP can be seen by sombody[edit]

Hi. In the current situation they get a banner to inform them that their IP can be seen by users. In the new banner they only get an invitation to make an account. The idea of masking is good but they still need to know their IP can be seen by some users (admins etc.) Gharouni 04:03, 5 January 2022 (UTC)[reply]

Gharouni makes a good point. The banner should include:

  • your IP is ... and it is visible by several users of anti-vandalism teams
  • your masked IP which will be used for your contributions will be ... and will be visible to all users

--FocalPoint (talk) 09:53, 5 January 2022 (UTC)[reply]

And users who have the same IP will be able to see that your edits came from the same IP. –LPfi (talk) 13:33, 13 January 2022 (UTC)[reply]
LPfi, Gharouni, we will inform editors that their IP addresses will be seen by admins as we've indicated in this screenshot on the project page. Thank you for your suggestions. –– STei (WMF) (talk) 17:22, 19 January 2022 (UTC)[reply]
@STei (WMF): I think admins seeing them is a minor concern, compared to whether people they know (such as their boss) can see the connection, and whether the addresses are saved in logs that may be given away, such as in the case with (Penet remailer). –LPfi (talk) 17:59, 19 January 2022 (UTC)[reply]
I hope that the popup is not fhe final version. It doesn't mention the new IP reviewer group, and it's missing a link to a page or pages where it's explained who can see the IPs. "Administrators" probably means nothing to most people, and many might mistakenly believe that administrators are WMF employees. kyykaarme (talk) 09:35, 23 January 2022 (UTC)[reply]

Clearly for IP based and new tool to identify when a registered user is disconnected.[edit]

Hi User:Johan (WMF), just to share as admin that the option of cookies and so on seems to complicate the admin environment without resolve many things concerning wrong social behavior on Wiki projects. As some ones already explained, it will just change the rull of the game of troll (not game of trone ;-) but not changing situation. May be trolls will appreciate this change that make their occupation of disturbing project a bite more exiting...

In the other hand, masking IP address is an excellent idea. It's simple, don't disturb the community habits and give to the technical team lot of time to think and develop new tools. For instance, with masked IP, It should be, for instance, very useful to develop a new tool that permit to see when an IP will be used by a registered instead to be connected. For a registered user, it's indeed a frequent practice to voluntary disconnect the session before writing something unpleasant to another user without being identified. If they are identified as well when they are not connected, that's could limit this practice, while forcing users to communicate in an identified way and therefore with more courtesy.

Best, Lionel Scheepmans Contact (Fr-N, En-3, Pt-3) 15:38, 5 January 2022 (UTC)[reply]

Lionel Scheepmans, good to hear from you. Thanks for the feedback. ––STei (WMF) (talk) 17:12, 19 January 2022 (UTC)[reply]


I wonder if it would be possible to use both ways to determine identity:

  • cookie = true, ip = foo > Alice
  • cookie = false, ip = foo > Alice (deleted cookies / incognito mode)
  • cookie = true, ip = bar > Alice (other IP but same browser)
  • cookie = false, ip = bar > Bob

That would make it even better than the current system. It will keep the identity of people under IPv6, but also many of the ones behind CG-NAT (in my country many ISPs use CG-NAT for at least half of their IP4 ranges). Geraki TL 16:28, 5 January 2022 (UTC)[reply]

@Geraki, there is no way for us to know that cookie=false, ip=foo is still Alice. The IP could’ve been assigned to another device. –– STei (WMF) (talk) 17:06, 19 January 2022 (UTC)[reply]
@STei (WMF) Yes, but it is already the current (or future) IP-based identity path. There are 6 browsing devices in my home, I am already assigned one identity and if my kid edits, we already have the same identity. If I edit from another place with the same device, I will get another identity, and get back my older identity when I move back to home. So I already have two identities, and one of them is already shared with another person.
Keeping track of the path of both the ip and devices will help people have a persistent identity (even if it is shared, which is not different from the current situation), and help with the workflow against vandals. There is no need to keep track of all the past IPs: only the last and current IP, so that multiple people will not get the same identity just by editing from an IP that was used a week before. Geraki TL 07:03, 20 January 2022 (UTC)[reply]


Whatever you guys decide on is fine, just don't pet-peeve me by making those temp-accounts English. Create a Mediawiki page for localization. Thanks. Seb az86556 (talk) 17:06, 5 January 2022 (UTC)[reply]

@Seb az86556, thank you, yes, we are considering this. –– STei (WMF) (talk) 17:04, 19 January 2022 (UTC)[reply]

Page by page revealing[edit]


This may have got resolved in a discussion and I missed it, but last I recall the question of how to handle the WMF (more accurately, Legal) wanting to log cases of IPs being revealed (rather than them being revealed as default to those with that setting) and the issue that doing that one by one would be a massive pain and disruption to the workflow hadn't been resolved.

Several people had mooted the possibility of revealing a page at a time, and I think Johan said they'd consider it and ask Legal (apologies if I am incorrect about that final aspect). Did this get escalated and if so, what was the outcome? Nosebagbear (talk) 13:13, 6 January 2022 (UTC)[reply]

@Nosebagbear, Legal has confirmed that page-by-page is good to go. –– STei (WMF) (talk) 16:59, 19 January 2022 (UTC)[reply]
Tah muchly! Nosebagbear (talk) 17:05, 19 January 2022 (UTC)[reply]

Account age[edit]

The content page mentions that there will be restrictions based on "account age". This is a problematic metric. How many years old is my account? I recommend that you recommend a metric such as "at least 100 edits in 12 of the last 18 months". (talk) 20:09, 6 January 2022 (UTC)[reply]

@ our most recent update does say "accounts over a certain age and with a minimum number of edits." We are even considering adding a community vetting for anti-vandalism fighters who want to opt in. So this user right would be handled like other user rights by the community. It'll require a minimum number of edits, days spent editing and vetting. –– STei (WMF) (talk) 16:57, 19 January 2022 (UTC)[reply]

Why choose one, if we can have both[edit]

Moving to a session-based identification for anonymous users seams in line with the 'assume good faith' philosophy, and could potentially expand the number and quality of the contributions from occasional users, perhaps even 'convert them' to logged-in users.

The down side of such change would be, that it would be harder to detect some of the most common types of vandalism.

Now, I understand that moving to a session-based identity for anonymous users will take some work on the platform. If we are already working on supporting cookie-based identities, why not keep some of the benefits that we have from the IP-based identification?

So basically, besides getting a handler (e.g. anon-1fe49afc7bc5), for whom we can see the User contributions, we can also have a hashed-IP identifier for that user (which might be shared by different anonymous users), and direct access to any contributions done from that (still hidden) IP, be able to (temporarily) block anonymous contributions from said IP (even without seen it!), or pass it forward to a checker for more information.

I understand there are also other ideas of how to make this and other frequently used tools possible under the new scheme.

I short, I agree with the session-based identification, but let's also work on improving the mechanisms available to mitigate vandalism.

MarianoC 21:57, 6 January 2022 (UTC)[reply]

There's a discussion about this up-page: see § IP-based versus session-based masking: Why not both?. You might want to move your comment there. — Scott talk 22:52, 6 January 2022 (UTC)[reply]
Thanks! MarianoC 10:49, 7 January 2022 (UTC)[reply]
MarianoC, Scott, I guess I will see you in the other thread. ––STei (WMF) (talk) 16:46, 19 January 2022 (UTC)[reply]

Aporte de argumentos sobre la relevancia en Wikipedia de: Centro de Investigación y Desarrollo Agrícola de Ohio[edit]

Questions from 魔琴[edit]

Hi. I have 2 questions:

  1. I am from mainland China, so I wonder, since users from mainland China can't sign Confidentiality Agreement for Nonpublic Information, can they have access to unencrypted IP addresses?
  2. I participate in SWMT, but I don't have global rollback/sysop right (lacking experience...) How will it affect my work?

--魔琴 (talk) 05:21, 8 January 2022 (UTC)[reply]

That's the problem. The Confidentiality agreement for nonpublic information sign that user mustn't live in countries that censor Wikipedia like mainland China, so zhwiki is the largest wiki in which there are no local checkusers, even with 65 admins. For IP address, I think that user are not trusted to see the IP address, so personally, I think only checkusers can check unregistered users for their IPs. They would be called as a random name, and would not affect global tasks. However, rangeblock would become impossible and only for checkusers. Thingofme (talk) 14:27, 8 January 2022 (UTC)[reply]
"[S]o zhwiki is the largest wiki in which there are no local checkusers." No, the zhwiki doesn't have local CU because the Foundation removed CheckUser access from all local users due to "security concerns" in Mar 2018, accordingly after some still-unknown CheckUser posted IP-user relationships on the village pump. --魔琴 (talk) 04:48, 9 January 2022 (UTC)[reply]
魔琴, Thingofme, we will get back to you on special cases like that of China. But for others, we have some notes here and there with more information on editors who will be able to see IP addresses and what they are required to do for access. ––STei (WMF) (talk) 16:39, 19 January 2022 (UTC)[reply]
@STei (WMF) hello - I was wondering if there had been further thought on the general question of "are regions subject to CANI restrictions, also subject to unmask-UP restrictions"? A not tiny percentage of the editorial base are associated with a project that has admins but is CANI-limited.
On a personal basis, the Chinese government (as the big example) is more than capable of knowing every China-based editors' IP address when editing, regardless of our own masking. There are, of course, countries where such a safeguard may be of use, even on a limited state-actor level. Nosebagbear (talk) 15:14, 15 March 2022 (UTC)[reply]
魔琴, I will be reaching out soon to see if we can speak one-on-one about your unique challenges, including the message you left on my talk page. –– STei (WMF) (talk) 07:14, 22 March 2022 (UTC)[reply]


Regardless of which approach are being pursued, I think it should be compartmentalized per wiki so if you have permission to unmask on one wiki, you can't unmask based on information gathered from another wiki; And only people with some global unmask permission can unmask globally. This would prevent the issue if someone with nefarious intent manage to get unmask permission on a smaller wiki to be able to unmask all IPs on all other wikis. AzaToth (talk) 13:17, 8 January 2022 (UTC)[reply]

@AzaToth thank you, yes, this is what we planned. –– STei (WMF) (talk) 16:33, 19 January 2022 (UTC)[reply]
And vice versa: it could make it impossible to see cross-wiki vandalism for local admins, and would make it harder to judge local edits' validity.
Which makes it logical that we need a tool to find cross-wiki same-ip (or same subnet) edits without revealing the specific IP? grin 15:02, 20 January 2022 (UTC)[reply]

Some thoughts on how the media could perceive this[edit]

@Johan (WMF): The change needs to be communicated carefully to the general public, I think. In the past, there have been several articles by investigative journalists (such es here in Switzerland, or in Germany) about manipulation of Wikipedia that relied in part on the IP addresses in the version history. They then were able to show "this article has been edited anonymously from an IP that can be traced back to corporation X", or that it is an IP from the federal government of Y, and so on. Making the IP addresses no longer visible to the public could be perceived as an attempt to sweep attempts to manipulate Wikipedia under the rug, to make the project less transparent and making the journalists' work harder. To me, the privacy enhancement / legal reasons seem to be clear and convincing enough, but I wouldn't count on the media to see and to depict it that way! Try to avoid "Wikipedia hides manipulation!" headlines... Gestumblindi (talk) 19:02, 8 January 2022 (UTC)[reply]

Gestumblindi, thank you for this insight. Our press team will work on this. –– STei (WMF) (talk) 06:53, 11 January 2022 (UTC)[reply]
Also it is very true: this would make it almost impossible for investigative jhournalists to trace back malevolent edits to companies, governmental institutions and other dishonest organisations.
Maybe there ought to be a researchers' access to IP data as well (which is a can of worms, I do know that). grin 14:59, 20 January 2022 (UTC)[reply]

Proposal: Keep own IP address unmasked[edit]

This discussion page has been brought to my attention by a notice on German Wikipedia’s version of the Signpost.

I do not have the time nor am I in the mood for reading all the discussions on this page, so I do not know whether a remark like mine has already been put forward earlier; apologies if this is the case.

I would like to propose that logged-out users still be able to see their own IP addresses (unmasked) as well as retrieve them via the API (meta=userinfo). In terms of privacy this should be entirely unproblematic (since the users are only shown information about themselves, not about other users). Given that sysops, CheckUsers and others are able to see unmasked IP addresses (and potentially investigate information associated with them, such as geolocations), it would only be fair if (potential) logged-out contributors were able to check beforehand the information exposed about themselves to those users. (As an aside, this also applies to logged-in users, who can at the moment see their IP address before logging in, albeit in their case it would only be exposed to other users in case of a CheckUser investigation against them.)

To rule out any misunderstanding: When talking about “being able to see one’s own IP address” I mean somewhere in the UI, for example in Special:Contribs, not everywhere a masked version of the IP address would be shown instead to other users; not in signatures, for instance, which are obviously generated once an edit is made and not easily available for being altered on-the-fly by the UI.

I would expect this to be piece of cake technically since the means of displaying an unmasked IP address in Special:Contribs are already there, they would just have to be made conditional based on whether the requested contributions are one’s own (as redirected by Special:MyContributions). The API query meta=userinfo would not even need to change at all since by design it only returns information about the calling user. --2A02:8108:50BF:C694:A1E3:B362:5009:4A0B 20:22, 8 January 2022 (UTC)[reply]

Thanks for the suggestion. –– STei (WMF) (talk) 16:30, 19 January 2022 (UTC)[reply]
The IP address in the page w:Wikipedia:Get my IP address; or we can get it by many other ways, not just in wikipedia. Thingofme (talk) 01:44, 9 January 2022 (UTC)[reply]
Yes; as long as these ways of getting one’s own IP address are still there, there should be no problem. (As far as I can see, w:Wikipedia:Get my IP address is not a Special Page, and I don’t know whether there is an equivalent in every language version; for example, I don’t know of any in the German language Wikipedia, but I haven’t bothered looking for one, since de:Special:MyContributions aka de:Spezial:Meine Beiträge did the trick.) As for the API (meta=userinfo) it’s (probably) mostly a matter of avoiding breaking changes, in case there are any consumers out there relying on it returning an IP address (instead of a masked version thereof) as user name when queried without being logged in. --2A02:8108:50BF:C694:986:2570:11A4:4D82 12:05, 9 January 2022 (UTC)[reply]

Good when it comes to privacy protection, bad when it comes to LTA-users[edit]

In general, I do think that it is good to have more privacy protection for unregistred users. When it comes to privacy, this is definitely a good idea. However, couldn't that demotivate people from creating accounts? Also, smaller projects that struggle with constant attacks from LTA IP-offenders (e. g. Croatian Wikipedia), could take damage from that, atleast in my personal opinion but I am not making claims here. During the past, the IP helped us sysops to identify banned users, who kept returning as IP-users. If the IP is no longer visible, it might be a problem to identify banned users who stopped creating accounts and decided to edit/troll as an IP (often in use of a VPN). --Koreanovsky (Ča–Kaj–Što?!) 13:23, 12 January 2022 (UTC)[reply]

@Koreanovsky, @Wutsje, unregistered users will still not have access to some features like Watchlist and Preferences. Also sysops will have IP viewer rights. –– STei (WMF) (talk) 16:29, 19 January 2022 (UTC)[reply]
I know, but I'm more worried about long term cross-wiki abuse. Wutsje (talk) 16:58, 19 January 2022 (UTC)[reply]

Access for community tools[edit]

Hi, I see the two approaches about the IP-masking (IP vs. session). I personally would like to choose the session-based approach as it offers new opportunities on analyzing user activities (and keep the option open for blocking or deleting cookies). However, I see that many editors will be against it. What we should ensure that statistical and similar tools developed by community members (for example on will not be broken after this move. Will we provide automatic access for these tools to the IP addresses (or session data) or did you think on this issue? Samat (talk) 22:31, 15 January 2022 (UTC)[reply]

Hello @Samat, I will get back to you on the status of community tools and those we are currently working on/refreshing for the era of masked IPs. –– STei (WMF) (talk) 09:00, 18 January 2022 (UTC)[reply]
Hi @STei (WMF): - now that the WMF has opted for session data, can you confirm how these tools will be affected? Nosebagbear (talk) 15:05, 15 March 2022 (UTC)[reply]


I think anyone who has access to the new user right that allows them to see IPs should have to sign the nondisclosure agreement or some other form of a privacy agreement. I am an active vandalism fighter and a SWMT member and I intend to seek it. I also think there should be some form of a global user right that gives users access to the privilege. Bobherry (talk) 00:54, 18 January 2022 (UTC)[reply]

I agree with the trust of Bobherry's comment, noting tough that a restriction of access with extensive exceptions is essentially no restriction at all, so that the it's all in the details. Thank you also to STei (WMF) for the links provided below. Cheers. 2601:246:C700:558:4934:BD1D:2B41:D139 22:50, 23 January 2022 (UTC)[reply]
Bobherry, we have some notes here and there with more information on editors who will be able to see IP addresses and what they are required to do. –– STei (WMF) (talk) 08:00, 18 January 2022 (UTC)[reply]

Preferences in the session-based approach[edit]

Would anon editors be able to use preferences in the session-based approach? It seems feasible because browser cookies are tied to a computer account (used by one user) instead of a modem (possibly used by several users). -- 04:41, 20 January 2022 (UTC)[reply]

Without a registered account, an editor will not have access to Preferences. –– STei (WMF) (talk) 06:17, 24 January 2022 (UTC)[reply]

What if somebody spy on my computer to get IP addresses while I don't know?[edit]

About "Following implementation of IP Masking, who will be able to see IP addresses?": What if somebody spy on my computer to get IP addresses while I don't know my computer 's being spied? For example, if my brother look at my computer while I am viewing an IP's talk page, and thus get the IP? I'm afraid actually....--Emojiwiki (talk) 05:39, 20 January 2022 (UTC)[reply]

I do not think the Internet can solve your social or family problems.
It is not clear what you wanted to ask but I suspect your family share the same IP so the point is moot: you all have the same IP and therefore you have the same talk page if it is shared by IP only, and you have a different talk page if it's based in cookies. Either way you should rather talk to one another instead expcting Wikipedia to resolve your internal problems. In my own opinion. grin 14:53, 20 January 2022 (UTC)[reply]
I think he meant that he may accidentally give away the unencrypted IP addresses. --魔琴 (talk) 15:08, 21 January 2022 (UTC)[reply]
yes, gave away unencrypted IPs that are not mine. Emojiwiki (talk) 11:12, 14 February 2022 (UTC)[reply]
Per Grin, it is your social or family problems. Unfortunately there is no way on Internet and Mediawiki that can resolve your problem. Only you can resolve problems by yourself. Thank you. SCP-2000 12:12, 14 February 2022 (UTC)[reply]

Suggestion about the new right of viewing IP addresses[edit]

I suggest to default give the "IP viewing" right to extended confirmed if any, and create a new right for sysops to assign if not. Also, give the community time to talk about this and determine the right of getting this role. This allows anti-vandalism can be continue without any mess after IP masking are added.--Emojiwiki (talk) 05:43, 20 January 2022 (UTC)[reply]

@Emojiwiki we have more information on the proposal about who sees IP addresses here. There's additional information regarding how we want to work with the community here also. –– STei (WMF) (talk) 06:51, 24 January 2022 (UTC)[reply]

IP rangeblock[edit]

As someone, who fights school vandalism daily, it is the most important thing to know the range IP. However, if different cypher keys are used for different IPs, how I will be able to differentiate between two not connected IPs and two IPs from the same range without clicking to a proposed window? A09090091 (talk) 14:43, 22 January 2022 (UTC)[reply]


The message that was sent to admins said "we will decide after 17 January". At least it was not straight after that date. Or is it extended? Stryn (talk) 08:08, 23 January 2022 (UTC)[reply]

Stryn, status not available yet. We will do our best to spread information when there's an update. –– STei (WMF) (talk) 06:23, 24 January 2022 (UTC)[reply]

As a...[edit]

dedicated non-logging (IP) editor, committedly so in the context of the very longstanding commitment of WP to such freedoms, I would suggest you put out a further call, through registered editors, seeking contact with IP editors to include in the current "what to do with..." discussion. I say this as one of those, but one who has managed to engage a circle of editors who are sufficiently patient to ignore bot-edit warnings, read edit summaries, and engage edit texts for their constructive, quality-directed aims. (That is, to edit with few misinterpretations of work-as-vandalism, and so very few cursory reversions.) Whatever new guidelines and attitudes are engendered by these discussions, they should not force IP editors into positions of recognition here that they have reasons to avoid, nor should they feed destructive attitudes that already exist—that there is something suspicious, if not wrong with the lot of us. I volunteer as one, but I would suggest (something like) your picking your top 100 articles, asking a regular registered editor at each to skim histories for recent, regular or otherwise significant IP editors at each (because these might, like myself, be ones with academic or other expertise), and reaching out to those "good" IP editors for their views. Will look in again here for a response. Cheers. 2601:246:C700:558:4934:BD1D:2B41:D139 22:38, 23 January 2022 (UTC)[reply]

Thank you for your suggestion –– STei (WMF) (talk) 09:03, 1 February 2022 (UTC)[reply]

Thank you[edit]

Thank you all for talking to us about how to proceed with IP Masking.

The Wikimedia Foundation will be reviewing your feedback as it decides on the best approach and features to employ. We hope to announce the outcome of the decision making soon.

In the meantime, we are revising the project page to make it easier to read and also provide answers to your most recent questions.

––– STei (WMF) (talk) 06:25, 14 February 2022 (UTC)[reply]

A personal thank you[edit]

Tagging along here, with Sandister adding thanks above, I just wanted to say thank you to everyone who has put their energy into this project and returned to comment, discuss, and prompt us along to how to best handle the situation. Due to time constraints, I'm no longer actively involved in this project, as STei (WMF) has taken over my role, and it felt strange to just fade away with no explanation to those who have talked so much with me specifically. This is a difficult project, but I have – as always – really appreciated the time some of you have put into it. /Johan (WMF) (talk) 10:21, 14 February 2022 (UTC)[reply]

@Johan (WMF): had missed this and wanted to thank you - both NKohli, and then you, have done a strong job being communicative despite a) being tasked with a mandatory change that multiple communities don't want, thus inserting you into a firestorm and b) being the front-facing person between the communities and other, less communicative, teams. Nosebagbear (talk) 10:07, 23 February 2022 (UTC)[reply]

New update - 25 Feb 2022[edit]

Hi all -- we have a new update for you on the project page: Implementation Strategy and next steps (25 February 2022). We appreciate all the time and effort you all put into providing your thoughts in these discussions the last few weeks. We tried to take every comment into consideration and come up with a solution that brings out the best-possible outcome. I want to apologize at the outset if this does not agree with your personal opinion. It was a hard decision to make either way. Your opinion is still valid and welcome. It helps us in planning for the tools we may need to build or plan for use cases we may not have thought about. Thank you very much. -- NKohli (WMF) (talk) 01:16, 26 February 2022 (UTC)[reply]

Hi @NKohli (WMF) and STei (WMF):, this got discussed right back at the start, but I've not seen any formal answers on it. As the definition of success is "does all of the current workflows at least as well, and hopefully some other aspects better", how are you measuring this?
False positives, false negatives, and time-taken/account are all key facets - and needs to be tracked individually for LTA-pursuit, CU work, regular SPI caseload etc etc.
I'm just don't want us to get to the end of the process and have disagreements as to whether there's been a net gain. This is especially the case as workflow time isn't really fungible - saving time for one group but costing it for another doesn't even out, because not all editors (definitely including me!) can do all things that required knowledge of IPs. Nosebagbear (talk) 12:48, 26 February 2022 (UTC)[reply]
Hi @Nosebagbear. That's a good question about measuring impact. We brainstormed on it internally when we kick-started this project. Like you said, there are many facets to measure and it is difficult to measure them all effectively.
On the quantitative end, we made a list of metrics ("guardrail metrics") which we will be tracking continuously to see if any of those numbers change dramatically as we rollout the key features on this project and begin the process of masking IPs (still a while away). These numbers include: number of active admins, admin to content ratio, new admins per month, number of blocks, unblocks, range blocks, reverts, page protections, page deletions, checkuser requests etc. You can find the full list in the tasks listed under this phab task.
For each of the individual features we are working on, we will be building out a feedback mechanism. This is true for both IP Info and Similar Editors (automated sockpuppet detection service). We'll be carefully evaluating feedback and using it to fine tune the features to get better results.
Lastly, we are thinking about doing qualitative analysis by running surveys on individual projects as we roll out the features to both a) spread awareness about this work and b) get feedback.
If you think of other things we can be doing, let us know. These are some of the ideas we came up with but I'm sure there's more we can be doing to measure the impact of this work. -- NKohli (WMF) (talk) 20:46, 1 March 2022 (UTC)[reply]
Hi @NKohli (WMF):, had seen this when you replied, and with some more thought it seems fine in most regards - there are three significant ones, two of which would need to be included in the feedback/survey bits and one that I'm not sure how to track off the top of my head:
  1. Time of task - this has lots of aspects, but is fairly clear - time to handle each part of a workflow that would use the info (noticing, finding appropriate IPs, blocking etc etc)
  2. (Perceived) complexity of workflow - even if it's roughly time equivalent, if people are thinking it's significantly more arduous that will have an affect (for example, I view CVU as a lightweight task to do when I am tired)
  3. The trickier one is one of the most crucial - identifying numbers of new editors moving into the different workflows - which the userright is not a clearcut marker for in total, let alone individual strands. One of my concerns is that editors who already do it, will accept a certain amount of awkwardness to keep doing what they know, but newer editors won't take it up at the same rate. That would impose an appreciable medium-term (12 months+) risk. Nosebagbear (talk) 09:55, 15 March 2022 (UTC)[reply]

Tools update[edit]


I was just hoping I could get a bit of clarity on the most recent update (that is, the tools update made on the 3rd March). It reads as if in the present tense (that is, the team has been redeployed to securepoll/votewiki for the affiliate/community elections later this year), but then the detail and the linked-to pages read as if in relevance to last year's redeployment to securepoll for the STV creation et al.

In effect, I'm a bit confused by the timings, current focus, and such Nosebagbear (talk) 14:07, 3 March 2022 (UTC)[reply]

Sorry @Nosebagbear we didn't post anything new about that. @STei (WMF) has been moving things around, trying to make the page more succinct and readable. It was probably an accidental change there. @STei (WMF) could you review the changes once please? I think the dates of the updates might have gotten lost. Thank you. -- NKohli (WMF) (talk) 21:37, 3 March 2022 (UTC)[reply]
@Nosebagbear, @NKohli (WMF)is right. No updates on tools, just an update on the implementation. STei (WMF) (talk) 17:47, 4 March 2022 (UTC)[reply]
Ah, that makes more sense, tah muchly Nosebagbear (talk) 18:18, 4 March 2022 (UTC)[reply]

The right to privacy is what they have given up, there is no need to spend energy on it.[edit]

It's easy to create accounts, and it's easy to create a whole bunch of them if you focus on vandalism. (Because my community has a lot of blocked disposable accounts)

If you have an account, as long as you don't disclose information, no one knows where you come from, which means you have enough privacy. And if you're not a vandals, UserChecker won't actively check your account and know the IP you're logged in with(though they won't publish your IP either). For good guy, an account is the best privacy protection and a regular channel of communication..

If you edit with an IP, a whole bunch of people can know where you're from, or where you want to be seen as where you're from (for vandals). When you edit with IP, you're already preaching: you don't mind your privacy at all (on the bright side).

In this case, why do we spend a lot of money on superfluous? (Although the foundation has a lot of money to fill the pool and swim in it.) THEY DO NOT CARE THAT. I fear this will become the next "Superprotect" and "Media Viewer". --Cwek (talk) 01:23, 15 March 2022 (UTC)[reply]

@Cwek FYI: It is because of the legal risk. SCP-2000 02:39, 15 March 2022 (UTC)[reply]
Those who give up their rights do so at their own risk, not make the foundation a babysitter. --Cwek (talk) 02:55, 15 March 2022 (UTC)[reply]
"do so at their own risk". This puts an enormous amount of responsibility in the hands of people who might not be as computer versed as you are, or maybe simply have made a one-off mistake. To me, it is like saying that Ponzi schemes should not be forbidden, because people entered into them of their own volition. Survival of the fittest combined with survival bias... I find that an incredibly naive view of technology. We are a very big website, with lots of our editors residing in dangerous places (and those places being increasingly hostile specifically towards us) and personally think that ethically we can not keep using IP addresses the way we have been. We DO have responsibility, we cannot just say "you should have used an account/VPN in the 5 years before your country's regime went fascist". —TheDJ (talkcontribs) 13:48, 15 March 2022 (UTC)[reply]
When they edit with IP, they should already know what risks they face. So if they can take their responsibility to protect their privacy rights, they should know what to do, which is what we should encourage - create an account. In short, an account is already the best way to protect user privacy. --Cwek (talk) 03:12, 15 March 2022 (UTC)[reply]
Unfortunately based on the information given by WMF legal team, it is legal need instead of ethical responsibility. SCP-2000 12:39, 15 March 2022 (UTC)[reply]
It's ridiculous to say it's a waste of money when no one has any idea if they adds any costs. That's such an off discussion issue that WMF already considered. If this is for legal issues, then so be it. That alone saves the foundation from potential lawsuits. The Grid (talk) 16:54, 15 March 2022 (UTC)[reply]

IP Masking implementation strategy and next steps[edit]

The Wikimedia Foundation has decided to go with the session-based approach. It has taken note of the numerous feedback on the issue of users deleting their cookies and changing their identities. As we work out the technical details, if you have any more comments on the session-based approach and any additions we can make, please leave them below. Thank you.

–– STei (WMF) (talk) 14:55, 15 March 2022 (UTC)[reply]

  • Please think again. A session-based approach has advantages when a good-faith anonymous editor uses one device on multiple IPs, but these are outweighed by the scope for abuse when a new unblocked identity can be created at will. The code you propose to write will never be executed, because this plan will force projects to ban unregistered editing completely. The thrill of seeing my first IP edit (a trivial typo fix) go live for the world to see led to 14 years of contributions. Please don't prevent new editors from making that journey. Certes (talk) 14:42, 16 March 2022 (UTC)[reply]
    Thanks for your comment. –– STei (WMF) (talk) 15:38, 17 March 2022 (UTC)[reply]
  • @STei (WMF) does the team have a method on ensuring how they're going to stop the increased vandalism/socking that this will enable (resetting cookies/sessionID being (even) easier than resetting IPs), or is it just being accepted as a negative in return for the positive? Nosebagbear (talk) 15:47, 16 March 2022 (UTC)[reply]
    We mentioned in the update that the technical details of how we will address this issue of cookie deletion and identity change will be shared when finalised. –– STei (WMF) (talk) 15:45, 17 March 2022 (UTC)[reply]

Stable section titles would be appreciated[edit]

Stable section titles would be appreciated for persistent links, e.g. from The Signpost. Someone added "NEW" to one of the section titles and I suppose it will be removed in the future. Bri (talk) 15:36, 16 March 2022 (UTC)[reply]

The page has seen a lot of updates and we try to make recent information easy to catch for readers. However, this concern is also true. 'NEW' will be removed. –– STei (WMF) (talk) 15:49, 17 March 2022 (UTC)[reply]
@STei (WMF): You don’t need to remove the ‘NEW’ from the title, you could just add the old title to the {{anchor}} template immediately preceding it. Actually I’d suggest doing that and keeping the section title unchanged, so that translators don’t have to update the translated section titles to remove ‘NEW’ from them. It also has the benefit that links like Special:MyLanguage/IP Editing: Privacy Enhancement and Abuse Mitigation#Implementation Strategy and next steps (25 February 2022) work even if the section title is translated into the user’s language. —Tacsipacsi (talk) 16:07, 17 March 2022 (UTC)[reply]

The collapsible headings make the page a bit awkward. Usually when you click on a heading in the TOC you're directed to a section where you see the same headings, but here for example in section 6 you have subheadings 6.1-6.4 in the TOC but in the actual section there are two subheadings (Legal update 02 & 01). The TOC and page headings don't match and it's quite confusing (to me at least). -kyykaarme (talk) 12:02, 26 March 2022 (UTC)[reply]

Statistics woman![edit]

Statistics woman, we need you! I'm quite serious, we do. A "session-based approach" has been decided upon. Exact details aren't quite known at this point I think, but "session-based" alone is making some vandal fighters shiver. What we need from you is quite simple: statistics. How much vandalism there is now, how much vandalism there is right before this is rolled out, how much vandalism there is right after and how much after vandal fighters (and vandals..) have had some time to get used to the new system. Important decisions may hinge on this, and without data no community can make an informed decision. Statistics woman, please, save the day. :-) Alexis Jazz (talk or ping me) 03:36, 27 March 2022 (UTC)[reply]

IP Info Feature now available on testwiki for beta testing[edit]

The IP Info Feature which is a tool that will display information about an IP address, commonly sought in investigations is now available for testing. Please read the update on this, and join the beta testing if you are interested. Best regards –– STei (WMF) (talk) 14:56, 1 April 2022 (UTC)[reply]