Talk:IP Editing: Privacy Enhancement and Abuse Mitigation

Add topic
Active discussions


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.

Previous discussionsEdit

IPv6 and privacy
"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)

  • 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)

If this really is as technically feasible as claimed, it is a great idea. SpinningSpark 18:57, 4 January 2022 (UTC)
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)
Can unregister user use username without password?
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)
I agree, it would be nice to let users that aren't logged in to identify themselves somehow.
93.107.67.214 20:54, 2 May 2022 (UTC)
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)
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)
Aporte de argumentos sobre la relevancia en Wikipedia de: Centro de Investigación y Desarrollo Agrícola de Ohio
{| class="hidden-archive mw-collapsible mw-collapsed" style="width: 100%; clear: both; font-size: 88%; padding: 1px; margin-top: 0.2em;"

|- ! style="padding: 0.25em 1em; line-height: 1.5em; background-color:#f2dfce;" | Off-topic/Unrelated to the IP masking subject. |- | style="text-align:center; font-style:italic;" | The following discussion has been closed. Please do not modify it. |- | style="border: solid 1px silver; padding: 8px; background-color: white;" |

El Centro de Investigación y Desarrollo Agrícola de Ohio es un artículo relevante en la Wikipedia en español por los siguientes argumentos:
1º Es un centro de investigación y desarrollo de proyectos relacionados con la agricultura, que es dependiente de la Facultad de Ciencias Alimentarias, Agrícolas y Ambientales de la Universidad Estatal de Ohio, prácticamente desde sus inicios en 1882.[1]
2º En el año 1979 por parte de los científicos de esta institución se realizó un descubrimiento de la mayor importancia, un teosinte en México ("Zea diploperennis")[2][3], que podía cruzarse con maíz para hacer este más resistente a las enfermedades.[4]
3º Entre otros muchos trabajos realizados en este centro, es un lugar de investigación en la consecución y desarrollo de nuevos cultivares de manzana, entre ellos es de destacar la variedad Melrose, desarrollada en la década de 1920, cuya selección final se hizo en 1937 y la manzana se introdujo en los circuitos comerciales en 1944. Posteriormente se la nombró como la manzana oficial representante del Estado de Ohio.[5][6]
4º A que en la wikipedia en inglés"Ohio Agricultural Research and Development Center" está aceptado este artículo con suficiente amplitud de criterio, además de no estar cuestionada en absoluto su relevancia.
Javier martinlo (discusión) 18:41 7 ene 2022 (UTC) |}

Questions from 魔琴
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)

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)
"[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)
魔琴, 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)
@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)
魔琴, 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)
Access for community tools
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 toolforge.org) 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)
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)
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)
What if somebody spy on my computer to get IP addresses while I don't know?
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)
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)
I think he meant that he may accidentally give away the unencrypted IP addresses. --魔琴 (talk) 15:08, 21 January 2022 (UTC)
yes, gave away unencrypted IPs that are not mine. Emojiwiki (talk) 11:12, 14 February 2022 (UTC)
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)
WMF: Thank you, time to review your feedback
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)

WMF: A personal thank you
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)
@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)
WMF: New update on IP Masking implementation - 25 Feb 2022
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)
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)
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)
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)
Tools update
Hello,

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)

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)
@Nosebagbear, @NKohli (WMF)is right. No updates on tools, just an update on the implementation. STei (WMF) (talk) 17:47, 4 March 2022 (UTC)
Ah, that makes more sense, tah muchly Nosebagbear (talk) 18:18, 4 March 2022 (UTC)
The right to privacy is what they have given up, there is no need to spend energy on it.
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)

@Cwek FYI: It is because of the legal risk. SCP-2000 02:39, 15 March 2022 (UTC)
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)
"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)
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)
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)
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)
WMF: IP Masking implementation strategy and next steps
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)

  • 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)
    Thanks for your comment. –– STei (WMF) (talk) 15:38, 17 March 2022 (UTC)
  • @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)
    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)
Stable section titles would be appreciated
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)
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)
@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)

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)

Statistics woman!
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)

New DiscussionsEdit

WMF Update: IP Info Feature now available on all wikis for beta testingEdit

IP Info Feature has been deployed to all wikis as a beta feature.

After an initial run on testwiki we received a good amount of feedback. Here is a summary of the key pieces of feedback:

  • The biggest and most important feedback was about the data quality of MaxMind. MaxMind's data quality, especially about proxy data, is not great. We have reached out to Maxmind about this and are also actively talking to Spur to get their data feed. Once we are able to obtain Spur's data feed we will be able to integrate it into the feature and show information from multiple data sources.
  • We heard about the interface being unclear about what information is available and what isn't. We are working on improving the labels and providing better guidance about the information displayed.
  • We heard a request about expanding the tool to include global information and also include information about IPs that have not made any edits on the given wiki. We will be looking more into both of these requests. We have done some prior investigation into showing global information.

We would love to hear more feedback about the feature, please share comments on the IP Info Feature discussion page. Your feedback will help improve the tool.

–– Best, Anti-Harrasment Tools Team

Questions on the usernames generated to the unregistered users under the session based methodEdit

I have several questions regarding the usernames generated to the unregistered users under the session based method.

  1. Do the usernames generated to the unregistered users have a certain prefix, such as “Unregistered user ABC”?
  2. Do the usernames generated to the unregistered users can be registered by either the unregistered user or others and added on the CentralAuth?
  3. Will usernames which are not registered locally but in the CentralAuth system being allocated to the unregistered users?
  4. Do the usernames which are reserved for such propose are globally reserved (i.e. The username are on hold from register in all wikis)?
  5. How many usernames are reserved for such porpose if the usernames are generated randomly instead of using a certain prefix?
  6. How can I know if a certain username is reserved for allocation for the unregistered users?
  7. Do the usernames generated to the unregistered user are same in all wikis?
  8. Will the reserved usernames being appeared in the CentralAuth?

These are the questions that I would like to know. Thank you. 49.182.189.38 08:35, 23 June 2022 (UTC)

We are still making decisions about username conventions. However, any auto-generated username for unregistered editors will be based on a cookie placed in their browser. The generated username for User:192.168.1.2 might look like User:Anon3406 as an example.
––– STei (WMF) (talk) 12:48, 23 June 2022 (UTC)
Thanks for letting me know. I believe that usernames with the same prefix would be a good idea on distinguishing unregistered users. 49.182.189.38 13:07, 23 June 2022 (UTC)
@STei (WMF): I have an idea on the usernames for the allocation of unregistered users. At the moment, usernames which like an IPv4 address (such as User:999.999.999.999) are marked as invalid to be registered instead of being banned by title blacklist. Those fake IPv4 addresses are also different from the other unregistered usernames when viewing on Special:Contributions (example: Special:Contributions/Global rename script, which is also invalid to register due to other reasons, have words "User account "xxx" is not registered.", while Special:Contributions/999.999.999.999 do not). I believe that it would be a good idea on using those usernames (from User:256.0.0.0 to User:999.999.999.999) given that those usernames are currently invalid to be registered, no new ranges of currently registrable usernames being reserved for such propose. It can also help the identification of unregistered users by the others given that they are similar to the IPv4 address. It is also easier on updating the abuse filter on distinguishing unregistered users. There are some wikis (such as zhwiki) prohibit the creation of user page of the unregistered users by using title blacklist which currently also includes those invalid IP addresses (in zhwiki at least). It will help on no further changes of the title blacklist is required on those wikis. Using those usernames of the fake IPv4 addresses from User:256.0.0.0 to User:999.999.999.999 will be able to allocate 744 billion usernames to unregistered users, which is more than enough given that the global population is only about 8 billion at the moment. I hope that this option can be considered when making the decision of the usernames. Thank you. 202.144.171.1 04:03, 12 July 2022 (UTC)
Thank you for the feedback. ––– STei (WMF) (talk) 16:55, 12 July 2022 (UTC)
My thoughts - There should be no words, letters, or characters, since these usernames need to be able to serve all the languages in the entire world, so if should be numbers only. But, it needs some human-readability. I would suggest date of first use, hyphen, and a consecutive numbers, something like User:20220724-248. Oiyarbepsy (talk) 22:25, 24 July 2022 (UTC)
I have also an idea. To prevent the usernames which are currently registrable becomes invalid, it is possible the usernames can be start with / (i.e. User:/12345). “/“ is currently uses as the subpages in the user namespace so it is not possible for the pages start with /. It is invalid to be registered with the character /. As there should have something before the subpages. It is not possible for the user page and user talk pages start with /. I believe that it would be possible to prevent the current registrable usernames become invalid to be registered. Hope you can also consider it. 49.182.153.225 23:19, 24 July 2022 (UTC)
Thank you, I am noting your suggestions. Thanks all. cc @Oiyarbepsy ––– STei (WMF) (talk) 10:46, 25 July 2022 (UTC)

Cookie notificationEdit

When an unregistered user starts to edit and they're given an auto-generated username, will they see a cookie notification and what happens if the user rejects the cookie? kyykaarme (talk) 15:33, 25 July 2022 (UTC)

Return to "IP Editing: Privacy Enhancement and Abuse Mitigation" page.