The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the Foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.
Discussions of proposals which do not require significant foundation attention or involvement belong at Village pump (proposals)
This page is not a place to appeal decisions about article content, which the WMF does not control (except in very rare cases); see Dispute resolution for that.
Issues that do not require project-wide attention should often be handled through Wikipedia:Contact us instead of here.
This board is not the place to report emergencies; go to Wikipedia:Emergency for that.
Threads may be automatically archived after 14 days of inactivity.
Behaviour on this page: This page is for engaging with and discussing the Wikimedia Foundation. Editors commenting here are required to act with appropriate decorum. While grievances, complaints, or criticism of the foundation are frequently posted here, you are expected to present them without being rude or hostile. Comments that are uncivil may be removed without warning. Personal attacks against other users, including employees of the Wikimedia Foundation, will be met with sanctions.
Our proposal in a nutshell: Temporary accounts offer improved privacy for users editing without an account and improved ways to communicate with them. They have been successfully rolled out on 1046 wikis, including most large Wikipedias. English Wikipedia has defined the criteria for Temporary Accounts IP Viewer (TAIV) right and granted it to 100+ users. We plan to launch temporary accounts on enwiki on October 7th 21stNovember 4th. If you know of any tools, bots, gadgets, etc. using data about IP addresses or being available for logged-out users, please help test that they work as expected and/or help update these.
Hello, from the Product Safety and Integrity team! We would like to continue the discussions about launching temporary accounts on English Wikipedia. Temporary accounts are relevant to logged-out editors, whom this feature is designed to protect, but they are also very relevant to the community. Anyone who reverts edits, blocks users, or otherwise interacts with logged-out editors as part of keeping the wikis safe and accurate will feel the impact of this change.
Temporary accounts have been successfully deployed on almost all wikis now (1046 to be precise!), including most large Wikipedias. In collaboration with stewards and other users with extended rights, we have been able to address a lot of use cases to make sure that community members experience minimal disruption to their workflows. We have built a host of supporting features like IP Info, Autoreveal, IPContributions, Global Contributions, User Info etc. to ensure adequate support.
With the above information in mind, we think everything is in good shape for deploying temporary accounts to English Wikipedia in about a month, preferably October 7th [update: on November 4]. We see that your community has decided on the threshold for non-admins to access temporary accounts IP addresses, and there are currently over 100 non-admin temporary account IP viewers (TAIVs).
The wikis should be safe to edit for all editors irrespective of whether they are logged in or not. Temporary accounts allow people to continue editing the wikis without creating an account, while avoiding publicly tying their edits to their IP address. We believe this is in the best interest of logged-out editors, who make valuable contributions to the wikis and who may later create accounts and grow the community of editors, admins, and other roles. Even though the wikis do warn logged-out editors that their IP address will be associated with their edit, many people may not understand what an IP address is, or that it could be used to connect them to other information about them in ways they might not expect.
Additionally, our moderation software and tools rely too heavily on network origin (IP addresses) to identify users and patterns of activity, especially as IP addresses themselves are becoming less stable as identifiers. Temporary accounts allow for more precise interactions with logged-out editors, including more precise blocks, and can help limit how often we unintentionally end up blocking good-faith users who use the same IP addresses as bad-faith users. Another benefit of temporary accounts is the ability to talk to these logged out editors even if their IP address changes. They will be able to receive notifications such as mentions.
How do temporary accounts work?
When a logged-out user completes an edit or a logged action for the first time, a cookie will be set in this user's browser and a temporary account tied with this cookie will be automatically created for them. This account's name will follow the pattern: ~2025-12345-67 (a tilde, year of creation, a number split into units of 5). All subsequent actions by the temporary account user will be attributed to this username. The cookie will expire 90 days after its creation. As long as it exists, all edits made from this device will be attributed to this temporary account. It will be the same account even if the IP address changes, unless the user clears their cookies or uses a different device or web browser. A record of the IP address used at the time of each edit will be stored for 90 days after the edit. Users with Temporary Accounts IP viewer right (TAIV) will be able to see the underlying IP addresses.
This increases privacy: currently, if you do not use a registered account to edit, then everybody can see the IP address for the edits you made, even after 90 days. That will no longer be possible on this wiki.
If you use a temporary account to edit from different locations in the last 90 days (for example at home and at a coffee shop), the edit history and the IP addresses for all those locations will now be recorded together, for the same temporary account. Users who meet the relevant requirements will be able to view this data. If this creates any personal security concerns for you, please contact talktohumanrightswikimedia.org for advice.
For community members interacting with logged-out editors
A temporary account is uniquely linked to a device. In comparison, an IP address can be shared with different devices and people (for example, different people at school or at work might have the same IP address).
Compared to the current situation, it will be safer to assume that a temporary user's talk page belongs to only one person, and messages left there will be read by them. As you can see in the screenshot, temporary account users will receive notifications. It will also be possible to thank them for their edits, ping them in discussions, and invite them to get more involved in the community.
User Info cardWe have recently released the User Info card feature on all wikis. It displays data related to a user account when you tap or click on the "user avatar" icon button next to a username. We want it to help community members get information about other users. The feature also works with temporary accounts. It's possible to enable it in Global Preferences. Look for the heading "Advanced options".
For users who use IP address data to moderate and maintain the wiki
For patrollers who track persistent abusers, investigate violations of policies, etc.: Users who meet the requirements will be able to reveal temporary users' IP addresses and all contributions made by temporary accounts from a specific IP address or range (Special:IPContributions). They will also have access to useful information about the IP addresses thanks to the IP Info feature. Many other pieces of software have been built or adjusted to work with temporary accounts, including AbuseFilter, global blocks, Global Contributions, User Info, and more.
For admins blocking logged-out editors:
It will be possible to block many abusers by just blocking their temporary accounts. A blocked person won't be able to create new temporary accounts quickly if the admin selects the autoblock option.
It will still be possible to block an IP address or IP range.
Temporary accounts will not be retroactively applied to contributions made before the deployment. On Special:Contributions, you will be able to see existing IP user contributions, but not new contributions made by temporary accounts on that IP address. Instead, you should use Special:IPContributions for this.
See our page Access to IP for more information about the related policies, features, and recommended practices.
If you know of any tools, bots, gadgets etc. using data about IP addresses or being available for logged-out users, you may want to test if they work on testwiki or test2wiki. If you are a volunteer developer, read the documentation for developers, and in particular, the section on how your code might need to be updated. If you know of tools, bots or gadgets that have not yet been updated and you don’t know of anyone who can update these, please reach out to us.
If you want to test the temporary account experience, for example just to check what it feels like, go to testwiki or test2wiki and edit without logging in.
Tell us if you know of any difficulties that need to be addressed. We will try to help, and if we are not able, we will consider the available options.
To learn more about the project, check out our FAQ – you will find many useful answers there. You may also look at the updates and subscribe to our new newsletter. If you'd like to talk to us off-wiki, you will find me on Discord and Telegram.
We would like to thank stewards, checkusers, global sysops, technical community members, enwiki functionaries and everybody else who has contributed their time and effort to this project. Thank you for helping us get here. NKohli (WMF) and SGrabarczuk (WMF) (talk) 11:38, 11 September 2025 (UTC)[reply]
It's still not clear to me what would be allowed to discuss publicly.
Temp account X seems the same as Temp account Y
Temp account X seems the same as older IP editor Y
We should rangeblock IP adresses X to stop temp account A, B and C
Temp account X is a school account for school X / a government account for department Y / ...
...
Should all these only be had "behind closed doors" somewhere, or are these allowed in the same circumstances as we would discuss them now (SPI, ANI, ...)? Fram (talk) 11:53, 11 September 2025 (UTC)[reply]
Thanks @Fram, first we wanted to emphasize, to make it just clear to everybody around, that temp accounts are just a different paradigm; they don't match 1:1 with IPs, and in some cases it doesn't make sense or there's no need to link them with IPs 1:1.
These restrictions only apply when you (1) use data from the IP reveal tool to make the link and (2) discuss publicly. All of the above can be discussed in a private venue where only TAIV users can see the information. Also if the link is only behavioral, then any user, including those who have TAIV, can make the link publicly. But if you do have TAIV and talk publicly, there may be an implication that you used the tool to make the link. CUs often get around this by declining to comment about IPs if they have run CU on a user, so they can avoid the implication that they linked the IP and user together using CU data.
Now to your questions:
This is OK if necessary for anti-abuse purposes, and you can even say "Temporary account X is using the same IP address as temporary account Y" as long as you don't mention the specific IP.
Not publicly, unless the link is made purely through behavioral evidence (i.e. edits).
Not publicly. You can, however, say "Please block the common IP ranges used by temporary accounts A, B, and C" publicly where the admin could use IP reveal to find which range you were talking about. Another option for non-admin TAIVs is to say "Please block this IP due to abuse from temp accounts" (without naming the accounts).
If you are using access to IP addresses to get this information, then probably not okay. If using edits, then okay.
Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective remedies for one-off abuse. Even if we agree that English Wikipedia is unique and whatnot, there is a pattern and hopefully discussions about blocking IPs won't be that frequent (phab:T395134#11120266).
Thanks. So access to IP adresses is treated as CU access basically? That seems like a severe step backwards in dealing with vandalism, sockpuppetry, LTAs, ... Curs both ways of course, we now also exonerate people with things like "the IPs used by that vandal located all in country X, but this new IP comes from country Y, making it unlikely to be a sock. This happens in standard ANI discussions and the like, not requiring any CU access, but will no longer be possible for most editors.
Your "Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective" seems like a non-existent advantage. We had many "single" IP blocks, these will be changed to "single" TA blocksn this is not an advantage or disadvantage of TAs. The issues are rarely with the simple straightforward cases.
A very simple example: when I look at the revision history of [1] I immediately see that the last three IP edits are made by the same person, using two IP adresses. If we are lucky, in the future, this would be one temp account. If we aren't lucky, then these would be two completely unrelated temp accounts.
Or take this edit history for a school. Since March, I see different IPs in the 120.22 range; it seems likely that this is either the school or the village or city, so no socking, unless these 4 were all from an IP provider in, say, France, in which case it's much more likely to be the same person in each case. From now on, no more means to raise such issues or notice them if you are not of the few (and if you are, you can't raise it publicly).
Or to make it more concrete still: we have this current ANI discussion where a non-admin raises an issue related to completely disparate IP adresses: "a certain editor who has been editing over several months from various IPs, all geolocating first to South Korea, then more recently to Japan. " If said IP disables or removes cookies, there is no way that most of our editors would be able to adequately see or raise such issues, they would just have to say "there is a range of temp accounts, no idea if there is any connection between them".
@Fram With respect to Your "Finally, a very important note just for context: on other projects, including large Wikipedias, we have seen a significant decline in IP blocks, indicating that temporary account blocks are often effective" seems like a non-existent advantage. We had many "single" IP blocks, these will be changed to "single" TA blocksn this is not an advantage or disadvantage of TAs. [sic] The point being made here is that even in larger wikis there has not a significant requirement to resort to IP blocks (which are still going to be allowed). It appears that based on the trends WMF is monitoring, there is evidence that most typical vandals are not shifting across temporary accounts by disabling or removing cookies. Sohom (talk) 15:08, 11 September 2025 (UTC)[reply]
I understand the point being made, and I don't see the importance of it. Most IP blocks that are now being made also don't require CU, SPI, ANI discussions, ... Basically, for the "easy" IP problems nothing changes, but the more complicated ones get harder to spot, discuss, ... "Most typical vandals" are not the ones I am talking about.
A report like this one from this month could no longer be publicly posted. In the future, the editor who posted it has temp IP rights, so he could notice that a group of temp accounts is from "This large IP range in Australia ", but wouldn't be allowed to post this fact. They link to an IP range edit log[2] which would no longer be possible in such a discussion, as that would disclose the IPs of the temp accounts. It would lead to such discussions being had in back chambers, out of view of most editors, and more importantly still impossible to be initiated by most editors. That kind of stuff is the issue, not the "one-off vandals will get a 31h block on the temp account instead of on the IP". Fram (talk) 15:19, 11 September 2025 (UTC)[reply]
There's also a lot of "appears to be a one-off-vandals" that with a quick check of some small ranges turns out to be someone vandalizing for months or years. That visibility will be gone, too. ScottishFinnishRadish (talk) 15:21, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish, @Fram You will still be able list temp-account edits by IPs and ranges at [[Special:IPContributions/<insert IP address here>]]. I don't understand how we suddenly be unable to make the requests that you are pointing to. Sohom (talk) 15:49, 11 September 2025 (UTC)[reply]
I will not request the temp IP viewer right under the above rules. I have had one ridiculous outing block for coupring someone's handle to someone's real name, even though they were listed as such on their Wikidata page and they used both in combination elsewhere as well: I will not risk getting another block because I somehow "outed" and IP address I learned through that right but was not allowed to share with the masses no matter how useful that might be. And no admin c.s. will be allowed to show such IPcontributions list when they may not reveal the IP address behind the temp account name. Fram (talk) 15:54, 11 September 2025 (UTC)[reply]
That's on you, the above directive is pretty explicit that you can report "hey Special:IPContributions/192.168.0.0/16 (not exactly that, but you get the drift) is a bunch of school kids, can a admin block it" or "hey Special:IPContributions/192.168.0.0/24 appears to a bunch of temporary accounts with very similar disruptive edits to game engines". It's a change of vocabulary yes, but the kinds of reports you are talking about are definitely doable and not being explicitly disallowed. Sohom (talk) 16:05, 11 September 2025 (UTC)[reply]
""hey Special:IPContributions/192.168.0.0/24 appears to a bunch of temporary accounts with very similar disruptive edits to game engines". " That makes no sense. IPs are not temporary accounts. And in any case you restrict such reports and the checking of such reports!), now made by regular editors (see my link to such a report in the current ANI) to a much smaller group of people. By the way, the people with the right can see the IP address belonging to a temp account: but can they easily do the reverse? Fram (talk) 16:14, 11 September 2025 (UTC)[reply]
appears to be a bunch of temporary accounts sorry for the typo. (A IP range can map to multiple temporary accounts since a TA corresponds to a machine). Also, you do realize that almost anyone with rollback or NPR will be able to make the same report with no problems. The persons who will be able to take action (i.e. block, revert) is already limited and almost all of the folks who can respond will already have TAIV (or will be handed TAIV at PERM with zero questions). Sohom (talk) 16:28, 11 September 2025 (UTC)[reply]
Yes, and when they state "Special:IPContributions/192.168.0.0/24 includes temp accounts X, Y and Z, two of which have been blocked already" or some such, they should get blocked for outing as making that claim publicly (linking IP to temp account name) will be disallowed. If we follow the WMF rules on this, people will need to be very, very careful not to accidentally break them. Even claiming "temp accounts X, Y and Z all locate to Perth, Australia, so are likely socks" is not allowed, as one can only know that through the IP adresses, and publicly stating anything learned by seeing the IP addresses is, again, not allowed. Fram (talk) 16:49, 11 September 2025 (UTC)[reply]
So that'll add how many seconds to the average task that is done 10,000 times a month by a few dozen people? A ten second increase adds dozens of hours per month to an already overwhelmed workflow. Or this extra stuff doesn't get checked anymore, which is more likely, and everyone wastes even more time dealing with unmitigated vandals. ScottishFinnishRadish (talk) 16:44, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish, If your gripe here is "this adds 10 seconds to a existing workflow", I see that as a okay tradeoff to the other alternative, which is "WMF (and Wikipedia) gets sued out of existence by frivolous GDPR lawsuits" or "we lose legitimately a significant chunk of good contributions from IP addresses by blocking all IP editing". Sohom (talk) 18:10, 11 September 2025 (UTC)[reply]
You forgot "there's not enough labor available to keep up with the increased workload and trying to keep up leads to administrator burnout and even less labor available for the increased workload which leads to increased burnout..." ScottishFinnishRadish (talk) 18:14, 11 September 2025 (UTC)[reply]
@ScottishFinnishRadish Admin burnout and not electing enough admins is a "us" problem. The fix is nominating folks at WP:AELECT, WP:RFA (the very same processes you are defending as set in stone) and fighting to make it easier for the community member to elect worthy candidates to adminship, not arguing against the implementation of a system that has been brought on to prevent us from being sued from existence and where WMF has put in significant effort into reducing the friction down to 10 seconds. Sohom (talk) 18:22, 11 September 2025 (UTC)[reply]
Uh, the very same processes you are defending as set in stone, what?We don't actually know what the additional time required will be, and having worked with the interface to place over 13,000 blocks, I think 10 seconds is on the low end of the scale. Editor and administration time is not cheap and putting a system in place that will result in a huge increase in labor cost without looking at the available labor is probably going to be worse than what we've seen at ptwiki.We're routinely dealing with bot attacks that will require an IP block as well as a temporary account block that use multiple IPs a minute. The end result of increasing the workload of defending against these attacks is no one actually doing the work. ScottishFinnishRadish (talk) 18:34, 11 September 2025 (UTC)[reply]
Uh, the very same processes you are defending as set in stone, what? - We are talking about the inflexibility of community processes to deal with TAs and why they might not scale.
We don't actually know what the additional time required will be, and having worked with the interface to place over 13,000 blocks, - While I respect your opinions here, I think you are overestimating the amount of time here, you see a bunch of edits across different TAs, a non-TAIV editor starts reverting posts on AIV that a bunch of TAs are posting similar edits, a admin looks at the IP addresses for a few accounts (two or three more extra click than normal), clicks on the IPContributions and widens the search space untill all the TAIVs listed in the AIV report are covered and blocks the IP range and we are done. (If a TAIV editor sees the same edits, they directly report the IP address range and a admin blocks). I do understand your point about friction but I don't see it in the vast majority of the cases we aren't adding anywhere the amount of friction where folks will "just not do it". (and I assume with time user-scripts will be developed to make process smoother and less clicks). Sohom (talk) 19:42, 11 September 2025 (UTC)[reply]
There is Autoreveal mode for users with the checkuser-temporary-account-auto-reveal right, which reduces friction for users who need to be able to scan a list of IP addresses of temporary accounts when viewing logs. KHarlan (WMF) (talk) 21:03, 11 September 2025 (UTC)[reply]
Thanks. So if, there is an IP vandalizing pages infrequently over months or years, and once discovered, I would like to go back to check if their previous edits were also reverted, that would now be impossible? ARandomName123 (talk)Ping me!17:39, 12 September 2025 (UTC)[reply]
That was my thought as well. Even if someone who cleans up/investigates copyvio has TAIV, the lookback seems quite limited so you would have to hope that each temp account is doing something obvious on a behavioral level to link them. And then that circles back to if you can name a CCI after an IP address & list the temp accounts there. @SGrabarczuk (WMF): I'm not comfortable with "it may actually be OK to document IPs" - there should be definitive clarification one way or other before the rollout occurs. Sariel Xilo (talk) 20:03, 12 September 2025 (UTC)[reply]
Even if we agree that English Wikipedia is unique and whatnot, there is a pattern and hopefully discussions about blocking IPs won't be that frequent (phab:T395134#11120266). I hope we agree that if EnWiki isn't unique, it's uniqiue in size (though I would argue that EnWiki, like all other large projects actually is unique in its practices and challenges, even if much is common). And so even if the number of range blocks decrease, the scale of exceptions may cause more problems than even other large projects. Best, Barkeep49 (talk) 15:09, 11 September 2025 (UTC)[reply]
I think this line of thinking (disabling IP editing) is short-sighted and will lead to a eventual demise of the the project (if we don't let people know we allow editing, we lose potential new editors/contributors). We should not' be making it harder for people to edit, instead we should be looking at ways to make it easier for folks to engage and edit our content (especially in the context of the fact that a lot of our content is being indiscriminately being remixed by AI). Sohom (talk) 13:07, 11 September 2025 (UTC)[reply]
Bizarrely, the only major test we have had of this has not in any way lead to the demise of said project. Protuguese Wikipedia has disabled IP editing since October 2020 (according to the Temp Accounts FAQ, question "Would disallowing or limiting anonymous editing be a good alternative?" where the WMF claims "there is evidence that this came at the cost of a significant reduction in non-reverted edits, weakening the growth of content in the Portuguese Wikipedia, and potentially leading to other negative long-term effects."
These claims seem false or at the very least severely overstated (no surprise, sadly, to see this kind of thing when the WMF wants to promote what they want or suppress what they don't want), there is no reduction in the number of editor edits[3] compared to e.g. 2019 (2020-2021, the Covid years, are a bad comparison). The same can be seen for the number of new pages[4]. The number of new editors is stable as well[5].
So contrary to what the WMF claims and what you predict, there are no negative effects from disabling IP editing (on the one large wiki who has done this). Fram (talk) 15:33, 11 September 2025 (UTC)[reply]
The number of new editors is stable as well The chart you linked to shows a slow decline/downward trend since 2020 to the present day (August 2023 was 9K, August 2025 is 7K). Again, this is not a Freenode style sharp drop-off we are talking about but a slow downward decline not unlike stack overflow. Sohom (talk) 15:55, 11 September 2025 (UTC)[reply]
Er, August 2023 was 7894, not 9K. August 2025 was 7227. As comparison, enwiki August 2023 was 93052, August 2025 was 85195. So Pt is at 91.5%, and enwiki is at, hey, 91.5%. Frwiki 11989 / 10656, or 88%. Dewiki 5919 / 5594 = 94.5%. So it seems like the decline for ptwiki is exactly in line with that of other large Wikipedia versions in general, and identical to the enwiki one. Fram (talk) 16:07, 11 September 2025 (UTC)[reply]
I misspoke, I meant June 2024, I think we can quibble statistics for a hot second, but there is a significant anecdotal and UX research behind the fact that you present people with a "sign up before doing the thing" screen, you see a steady user-attrition in that area of the funnel. If you are telling me that Wikipedia is somehow so special that this doesn't apply, I'm going to need a to see a lot more data than what you are showing me at the moment. Sohom (talk) 16:22, 11 September 2025 (UTC)[reply]
So you have no evidence for your claims, you compared apples and oranges, but according to you it should happen as you predict and I somehow need more than figures of the past 5 years to prove that this didn't that didn't materialize, actually didn't materialize? Perhaps what you and your "sighificant anecdotical research" e.g. haven't taken into consideration, is that there may be many more editors who stick around because they no longer have to deal with lots of IP vandalism?
Anyway, "I misspoke, I meant June 2024"? Oh right, that month with 7880 new editors, that makes all the difference in explaining how you came up with 9K... Please don't make such a mistake a third time or I will have to consider it deliberate. Fram (talk) 16:37, 11 September 2025 (UTC)[reply]
Fram, your message above is extremely adversarial and abrasive. I will refrain from engaging in this particular thread any further unless you reword your statement because your point here appears to be engage with me personally rather than with the issue more broadly. Your comment implies that I'm trying to deliberately misrepresent information in some way, which I sincerely am not and is a asusmption of bad faith.
To explicitly answer your question, there is a clear slow decline visible and yes, I misspoke, I meant June 2023. Also, here is the other thing, we do need some kind of IPMasking, otherwise we open ourselves to lawsuits related to GDPR. I do not have access to any data about editor attrition due to IPMasking, but the whole reason the WMF is doing IP masking is to make sure admins and patroller have the tools they need to still continue doing anti-vandalism even with the legislation-required changes. Best, Sohom (talk) 17:30, 11 September 2025 (UTC)[reply]
I see no reason to change anything in my statement when you cherrypick one month and rwice fail to pick the right one to boot. June 2023 is also a thousand up from June 2022, so what´s that supposed to prove? One doesn´t check trends over 5 or more years by comparing one month from midway in the set with one from near the current end, unless one wants to prove some otherwise unsupported point. Fram (talk) 18:20, 11 September 2025 (UTC)[reply]
If temporary accounts goes poorly - something that seemingly hasn't happened on other large projects - that seems like a logical response for the community to make. However, many people have been in favor of turning off IP editing for a while and so temporary accounts aren't forcing those people, or the community to that position. I have seen the value of IPs on their own merits, and seen the from Editor reflections many editors with registered accounts started as IPs and so we should be careful about turning off that gateway. Best, Barkeep49 (talk) 14:25, 11 September 2025 (UTC)[reply]
This is what's known as the Brussels effect. Its why for example, caps on bottles are tethered in the UK, even though its required under EU law. Countries outside the EU may have this treatment, so that companies don't create a queue for EU and non-EU lanes. JuniperChill (talk) 18:18, 11 September 2025 (UTC)[reply]
I’m concerned that IP info will disappear after 90 days. This will make it difficult to address long term abusers with stable addresses, of which there are a significant number. Instead, we’ll be playing whack a mole every 90 days or so, unless we can somehow retain info on IP use. — rsjaffe🗣️15:10, 11 September 2025 (UTC)[reply]
As I’m thinking about this some more, one way to retain the ip record is to block the ip rather than the temp account when we suspect a long term abuser with perhaps a stable ip. If the block of the ip isn’t sufficient, then block the temp account. — rsjaffe🗣️15:33, 11 September 2025 (UTC)[reply]
As I understand it, I as a CU cannot do this because the Ombuds have decided this is the same as the longstanding prohibition on connecting IPs to an account. But I hope non-CU admins could without jeopardizing the right. Best, Barkeep49 (talk) 15:42, 11 September 2025 (UTC)[reply]
Even CUs can block on behavioural similarities, unless that's changing too. A bigger question is perhaps, if an IP is blocked, is that block visible on the temp account and can others see the reason for the block as they do now? CMD (talk) 15:45, 11 September 2025 (UTC)[reply]
Correct. I could block a temp account based on behavior. But I can't do what SFR and rsjaffe are mooting: block the IP as a signal before blocking the temp account (or at least can't without obfuscating it in some other way). Best, Barkeep49 (talk) 15:50, 11 September 2025 (UTC)[reply]
If the IP is blocked but not the temporary account: All temporary accounts on that IP address will be prevented from editing, because all IP address blocks apply to temporary accounts (even if the IP address block isn't a hardblock)
If the temporary account is blocked but not the IP: The temporary account targeted by the block will be unable to edit. Additionally, if autoblocking is enabled on the block targeting the temporary account then:
The last IP used will be autoblocked for 1 day (in the same way as autoblocking works for registered accounts)
Attempts to edit using that blocked temporary account will also cause an autoblock to be created
Thanks very much, hopefully this can all be collated somewhere. I suppose the remaining question is whether other users see IP blocks and their reasoning, and if so how. CMD (talk) 16:32, 11 September 2025 (UTC)[reply]
Blocks placed on IP addresses will continue to be visible on Special:BlockList and other places that show blocks. However, a user wouldn't be able to see that a temporary account is blocked by an IP address block, unless they use IP reveal (TAIV) to get the IP address and then look for the block targeting that IP (such as opening the contributions page for that IP). WBrown (WMF) (talk) 08:41, 12 September 2025 (UTC)[reply]
Really? If that is the case, how are admins expected to handle say vandalism reports of a temporary account where an IP is already blocked? Always block the temp account as well? CMD (talk) 09:58, 12 September 2025 (UTC)[reply]
If the IP address is blocked, then the temporary account cannot edit. Therefore, the admin wouldn't need to take additional blocking action on the temporary account. However, if the temporary account switches IP addresses then they will be able to edit.
Given that, if the target of the block is intended to be the temporary account the admin should block the temporary account. This will usually mean that it is better to block the temporary account first as opposed to the IP address.
We have seen that blocks of temporary accounts on other wikis have been enough to prevent abuse in most cases. Generally an admin would want to block the underlying IP address(es) if:
If this user has evaded blocks by logging out, waiting for the autoblock to expire, and making another edit
Multiple temporary accounts are editing for a sustained period on the same IP (therefore, it's easier to block the IP than multiple temporary accounts)
The issue I raise is vandalism reports, as given we now can't see if an editor is blocked multiple reports could be made. I suppose an admin could reply "Already IP blocked" and that wouldn't disclose the IP connection, but I suspect if multiple reports come in a dual block of teh temporary account as well will provide the clearest information. CMD (talk) 12:25, 12 September 2025 (UTC)[reply]
Yeah, a dual block would be the most clear. Blocking just the temporary account should be enough for any user that has not used TAIV to view the associated IP address.
This is useful information. Is there any compendium of lessons learned so far? That would help reduce the disruption that I’m sure will occur as we learn over time how to address this new way of tracking unlogged-in users. — rsjaffe🗣️13:19, 12 September 2025 (UTC)[reply]
Or rotate their IPv6 address by simply restarting their router. Autoblocks should inherit the block settings of the TA, and if they are using IPv6 addresses, they should apply across the /64 range as well. ChildrenWillListen (🐄 talk, 🫘 contribs) 20:04, 12 September 2025 (UTC)[reply]
@Barkeep49, I can't block the IP as a signal before blocking the temp account - I'm pretty sure you can, I'd like somebody else to confirm it but as far as I know, this happens on other wikis, it's a tradeoff Legal is OK with. SGrabarczuk (WMF) (talk) 16:17, 11 September 2025 (UTC)[reply]
I'm glad to hear admins can. But (and I would hope @RoySmith or some other Ombud reading this corrects me if I'm wrong) the Ombuds have written that I cannot as a checkuser. They did so in a message sent to checkusers in March and when I wrote in reply I find the implication that CUs will have to take similar measures to blocking two connected IPs as we do to blocking a registered account and an IP address to be incredibly surprising. no one corrected me or said I was misunderstanding in anyway. Best, Barkeep49 (talk) 16:32, 11 September 2025 (UTC)[reply]
It's great that we'll be able to block the temporary account MAB or Salebot is using, then spend additional time to view the IP and check if it's a proxy before placing the proxy block, and if we're lucky finish that process before their bot has moved onto the next temporary account on another IP that will require twice as many blocks and three times as much time to take care of. Or, as Barkeep points out, since we've gotten conflicting information I might have to block the temporary account, find an active checkuser or other trusted editor I can disclose the IP to, have them block it, and waste multiple people's time. ScottishFinnishRadish (talk) 16:49, 11 September 2025 (UTC)[reply]
@Barkeep49 I don't remember your specific comment, but I assume it was in response to the OC's email of 17 March, which is reproduced for public view at meta:Ombuds commission/2025/Temporary Accounts. I encourage anybody reading that to note that it's full of weasel words like "limited experience", "initial", "preliminary guidance", "evolving landscape", "current understanding", etc. I should also point out that just like ArbCom, the OC doesn't make policy; we (again, like ArbCom) just get blamed for trying to enforce it. RoySmith(talk)17:16, 11 September 2025 (UTC)[reply]
On the other hand, if an LTA comes back within 90 days on a new temp account and we can behaviorally link it to the prior temp account, and find that both are on the same ip, then we can go for a prolonged ip block. I think there’s going to be a significant learning curve to this as we figure out how to address chronic abusers. — rsjaffe🗣️16:02, 11 September 2025 (UTC)[reply]
There's also this: When it is reasonably believed to be necessary, users with access to temporary account IP addresses may also disclose the IP addresses in appropriate venues that enable them to enforce or investigate potential violations of our Terms of Use, the Privacy Policy, or any Wikimedia Foundation or user community-based policies. Appropriate venues for such disclosures include pages dedicated to Long-term abuse. If such a disclosure later becomes unnecessary, then the IP address should be promptly revision-deleted. (Source) SGrabarczuk (WMF) (talk) 17:28, 11 September 2025 (UTC)[reply]
You can configure your browser to reject cookies, and in that case, a new temporary account will be created for every edit you make. See this FAQ entry. Note that if you do this, you can edit only 6 times/day before you have to create a real account, per this FAQ entry. OutsideNormality (talk) 03:30, 12 September 2025 (UTC)[reply]
Hi! I want to note that we are not implementing any tracking cookies in your browser. Tracking cookies are used to track your browsing history and activities, typically across multiple websites. We are adding a cookie to attribute your edits to an anonymized username. And your data (IP address) will be stored for a limited amount of time and be exposed to a smaller group of individuals. We have a similar cookie for registered accounts, except that it lasts for a longer time period. -- NKohli (WMF) (talk) 09:32, 12 September 2025 (UTC)[reply]
Cookies don’t anonymize edits, they de-anonymize them. They enable activity to be tracked across IP addresses. (Or whatever you want to call it that isn’t “tracking”—haha, gotcha! It’s totally not tracking because we defined tracking as something you do with muffins, not cookies!) This cookie has no other purpose and I don’t want it. 98.97.6.48 (talk) 00:51, 13 September 2025 (UTC)[reply]
The alternative is the expose your IP address every edit. The purpose of temporary accounts is to de-anonymize your activities on Wikipedia (which must be done in some way so blocks apply to the same person) while hiding your real-life identity, the latter of which is what the WMF probably means by "anonymize". Aaron Liu (talk) 11:41, 17 September 2025 (UTC)[reply]
Some questions about temporary accounts:
Would there still be a way for an unregistered user to view all of their own IP's (post-rollout) contributions, or equivalently the list of their own IP's past temporary accounts?
Some questions about temporary account viewers:
If an unregistered user only edits constructively and without engaging in vandalism, trolling, or similar shenanigans, then would it be against the rules for a TAIV to check their IP address, or could they just decide to do it on a whim?
What's stopping a rogue TAIV user from programmatically checking the IP of every single temporary account that has edited in the last 90 days and dumping that list somewhere? Would there be ratelimits put in place or something? 98.170.164.88 (talk) 05:49, 12 September 2025 (UTC)[reply]
To answer your first question about temp accounts, what do you mean by "their own IP"? :) This was a fundamental concern with how we handle unregistered editors. IPs can change, sometimes very rapidly. We cannot say IP 1.2.3.4 is always User ABC.
Contributions made before the launch of temp accounts will not be affected. So a user can see edits made by logged out editors an IP/range from before the rollout. Post rollout, a temporary account holder can look at their contributions from their temp account. If they have happened to have other temp accounts in the past, they'll need to remember which ones those are if they want to see their contributions from those temp accounts.
To answer your questions about temporary account viewers:
The policy lays this out so please refer to it. We tried to make it as succinct and clear as we could. If you have clarifying questions about anything outlined in the policy, please let me know. Happy to answer.
There is a log in place but we do not have any rate-limits. We trust that editors with this right will exercise their judgement and act in the best interests of the project. We also expect that admins will ensure users who are granted this right truly need this right to carry out anti-vandalism efforts.
Chipmunkdavis, Rsjaffe, and other interested parties: I have made an attempt to document the answers to questions in this discussion at User:Perfect4th/Temporary accounts. It's roughly topical; anyone who wishes to or has a better understanding than what I wrote is free to correct it, reorder in a way that makes sense, add further answered questions, etc. Happy editing, Perfect4th (talk) 18:23, 12 September 2025 (UTC)[reply]
Nice. Thanks for making this. Perhaps you should consider moving it to projectspace, or someone should create something similar to it in projectspace. I think a projectspace page to put tips, tricks, and notes on temporary accounts is going to be needed to help get everyone up to speed. –Novem Linguae (talk) 21:07, 12 September 2025 (UTC)[reply]
I'm just going to comment here that anyone who wants to see how temp accounts work in action can look at the other wikis, particularly Simple English for those who aren't bilingual (myself included). QuicoleJR (talk) 12:03, 20 September 2025 (UTC)[reply]
I'll admit I've for some time now been rather dubitante over this whole change, and my overall assessment is almost certainly irrelevant to the people responsible anyway, but I'm still not sure if it's ever been explained by the WMF or anyone else why masking schemes that preserve ranges were disfavored, if that has been explained somewhere a pointer would be welcome. 184.152.65.118 (talk) 21:17, 21 September 2025 (UTC)[reply]
Will it be possible for editors on a temporary guest account to "upgrade" their guest account to a "proper" account during the 90 days, retaining their editing history? I an imagine quite a lot of editors might start as guests, but find they are making good progress, finding it fulfilling being part of the project, and want to keep going. It would benefit both the community and the individual if they can move seamlessly to a named account. That way, we have continuity in any ongoing discussions in which they're taking part, and in interactions concerning their edits, and they can still go back to their older contributions, which will count towards their extended-confirmed status. In fact if they get kicked off, start a named account, and immediately reinforce a view they've expressed somewhere controversial, we have to make sure they don't get instantly accused of socking. Elemimele (talk) 14:46, 27 September 2025 (UTC)[reply]
Disclosing another's IP would run afoul of TAIV rules. I'm sure whoever chooses to use the process would be warned about the chance risks. Aaron Liu (talk) 19:43, 27 September 2025 (UTC)[reply]
I don't believe that's possible, in the same way it's not possible now with an IP. But there's nothing to stop somebody from making an account and noting "I used to edit as ~2025-12345-99" on their user page if they want to. RoySmith(talk)14:51, 27 September 2025 (UTC)[reply]
ChildrenWillListen, I don't think so; I was under the impression that the main point of having the temporary accounts was to conceal the IP of the person using them, so that they offer logged-out users a better level of privacy, consistent with the way privacy law is going. Yes RoySmith they can do so, but from a community perspective it still means we need to look back at a separate place for their edit history, and from their perspective they're back to square one for anything like extended-confirmed (not that that's tragic) Elemimele (talk) 17:46, 27 September 2025 (UTC)[reply]
Hey @Elemimele, I just wanted to confirm that it's not possible to "upgrade" into a registered account. Instead, temporary account holders will be (perhaps they already are, periodically) encouraged to create registered accounts. SGrabarczuk (WMF) (talk) 12:10, 28 September 2025 (UTC)[reply]
There's a certain IP address whom I work with, as they periodically make NFL drafts and I come along to improve and publish them (I find the drafts by checking their contributions). How will I be able to continue working with the IP editor if this change goes through? BeanieFan11 (talk) 16:35, 7 October 2025 (UTC)[reply]
Ask them to create an account and edit using that. We are long past the "if this change goes through" point. It is going to happen, it's just a matter of the exact rollout date for enwiki having changed. RoySmith(talk)16:58, 7 October 2025 (UTC)[reply]
If they insist on not registering a "permanent" account, at least they will get a user page for the temporary account where they could note that they previously edited from an IP address. If I were regularly collaborating with an IP editor I'd find it hard to resist reminding them that a regular account would make communication and collaboration much easier. ClaudineChionh (she/her · talk · email · global) 21:30, 7 October 2025 (UTC)[reply]
What I don't understand is the resistance to registering an account. Let's say, like Beanie's collaborator, you have a long-term static IP address that people know you by. That's essentially the same as having a registered account except that 1) there's a few editing rights you can't have and 2) anybody can find out where you are by looking you up in one of the public geolocation databases. So what are you gaining by not registering?
I'm not being facetious here; I really do want to understand why people are opposed to registering an account. Given the disadvantages of IP editing, there must be some offsetting advantages which makes it the right choice for some people. RoySmith(talk)21:46, 7 October 2025 (UTC)[reply]
@RoySmith: We have our reasons. And there are more of us still around than you might at first think.
Not everyone is so philosophical about it, and as tongue-in-cheek as WP:WNCAA may be, it's not actually unpersuasive on its own merits; for some that's sufficient. For others remaining unregistered is their way of trying to help others get involved with the project and indeed to induce future registrations [6].
Contrarianism also plays a role. And of course historically, and unsurprisingly given the type of people attracted to editing here, there were some who saw their role as challengers of perceived injustice and others who thought that by pushing back against needless demands being difficult if you will they were performing a genuine public service by keeping the project from becoming too rules-bound and authoritarian. Never all that common, and rare now, but every so often I do catch a familiar old scent.
As for myself, I'll concede accounts offer greater anonymity, and access to some additional tools though making use of some script assistance while logged out isn't that hard if one is so inclined. Even so my ideals, however dated, are what they are. Editing unregistered is a matter not only of habit, but of fidelity. We all have our roles and for some of us that means being forever IPs. Not that in my case it really matters much given how limited my activity has been over the last decade.
I suppose one day all of us relics will be gone. Long-term trends are negative, quite the contrast with early wiki culture which was largely hostile to registration, when it was even permitted some will ascribe that merely to the outsize influence of Ward's Wiki but believe me when I say it ran deeper. The net as a whole has just not come along as free and open as hoped. So some day yes, but not yet. 184.152.65.118 (talk) 01:21, 3 November 2025 (UTC)[reply]
I was looking at the contributions pages for temporary accounts on other language editions of Wikipedia to get a feel for how this will work. I discovered that, under the new temporary account system, every time an unregistered editor merely reads a Wikipedia edition they had not previously accessed, the date, time, and language of their reading will be publicly logged.
See for example Special:CentralAuth/~2025-54321-0, who made one edit to Polish Wikipedia on 7 September, then merely read an article on German Wikipedia on 3 October (without making any edits in German). Another example: Special:CentralAuth/~2025-100123, who edited Polish Wikipedia and then read the German, Serbian, and Chinese Wikipedias about 13 hours later.
I find this odd. Why does the software have to keep track of mere reads instead of actual edits? If the goal of the new system is to improve privacy, then this seems like a step backwards. 98.170.164.88 (talk) 04:51, 15 October 2025 (UTC)[reply]
Hello. This is a quirk of the account registration system in MediaWiki. Every time a user visits a project that they haven't visited before, the account "attaches" to the new wiki. This works similarly for registered accounts too (example). Since temporary accounts use the same mechanism to generate accounts, the same behavior applies to temporary accounts. -- NKohli (WMF) (talk) 09:27, 15 October 2025 (UTC)[reply]
It does the same for us logged-in users too. This is currently the only way to automatically log-in on wikis you haven't visited before that share your account because the account-creation date is a required field on each local wiki too. Aaron Liu (talk) 11:32, 15 October 2025 (UTC)[reply]
I have some questions regarding not-logged-in participants in deletion discussions and other situations where consensus is being determined. Under the old system it is allowed for these editors to participate, but it is not allowed for one person to create the appearance of being multiple people by using multiple accounts. (1) If comments by multiple temporary accounts appear to be in good faith, are we therefore forbidden from checking whether they are actually the same IP? That is, does this count as "investigation of or enforcement against vandalism, abuse, spam, harassment, disruptive behavior" or do we have to have more direct evidence of disruptive behavior to look at the IPs? (2) If a not-logged-in editor participates in good faith in a discussion but ends up getting multiple accounts (because their 90-day window expired or they disallow cookies), should they be required to disclose that these accounts are the same editor, or if not how are other editors without IP view access supposed to know this? (3) If they are not required to disclose the continuity of their identity in such cases, how are we supposed to distinguish a good-faith not-logged-in editor with multiple temporary accounts from a not-good-faith editor who is deliberately creating multiple temporary accounts to create the appearance of being multiple participants? —David Eppstein (talk) 05:17, 31 October 2025 (UTC)[reply]
@David Eppstein: (1) I would say that you need some kind of reason to suspect disruptive editing in order to look at the IPs, so if comments by multiple temporary accounts appear to be in good faith and are not disruptive, then it doesn't seem like we need to check the IPs. However, if there is some kind of reason to suspect that the temporary accounts might be the same person masquerading as multiple people, we can look at the IPs. It seems to me that the bar for looking at the IPs of a temporary account with TAIV is lower than the bar for looking at the IPs of a regular account with CheckUser: you do not have to explicitly provide a reason in the log to check the IP of a TA like you would for CU, and the log of temporary account IP accesses is only available to checkusers, and it does not seem like anyone is really auditing it at the moment. (This is merely an observation... not an encouragement for people to start revealing all IPs willy-nilly.) (2) I see this as not too different from before, in the case where a user was on a dynamic IP address that changes frequently through no fault of the user. If one person ends up with multiple TAs in the same discussion, they should not intentionally participate in a way that suggests they are multiple people. Relevant policy here would be WP:EWLO: I don't think they would necessarily be required to always make a disclosure, but they should not be actively trying to deceive or mislead us. (3) We would look at the behavior to distinguish between good-faith and bad-faith users of multiple temporary accounts. Specifically, are the accounts engaging in the behaviors that are prohibited at WP:ILLEGIT? Are they deliberately trying to mislead us, or did their TA change naturally? If we ask them directly, do they answer truthfully? For what it's worth, the criteria for WP:TAIV access is pretty intentionally low, so hopefully it should be easy to get IP access for most members of the community that would need it. Mz7 (talk) 18:43, 5 November 2025 (UTC)[reply]
I cannot emphasize this enough, with a level of privacy now afforded to logged-out editors, certain admins need to seriously stop letting schoolchildren inserting random characters into articles hurt their feelings, because now if they're not careful they're outing the identity of a minor with the block logs (whereas before the minor did it to themselves). If they're on a vandalism spree that needs to be addressed, but a little kid writing "hi" or "poop" on an article one time (and self-reverting on top of it) after the IP (which represents thousands of users) came off of a ten year block is not "persistent vandalism" (it's arguably not even vandalism under policy; "test editing" isn't considered vandalism). Personally, I think there needs to be some training for some of these networking-illiterate (for lack of a nicer term) folks who can't tell the difference between the inevitable (i.e. out of over 60,000 people, someone in Port Charlotte will vandalize or test edit Wikipedia once in a while, and ditto for a school district/university population of comparable size) and a problem that needs to be addressed, and there needs to be consequences for anyone who decides to be heavy-handed. Just my two cents. PCHS Pirate Alumnus (talk) 00:35, 5 November 2025 (UTC)[reply]
It depends on the range. On one hand, if an admin blocks a temporary account along with a /24 belonging to the Okaloosa County School Board (for example) in response to a complaint at WP:AIV, or if that temporary account stops editing shortly after the range block, people can connect the dots and it suddenly becomes easier to identify Jane who is in fourth grade and is obsessed with carrot cake because someone can find a Pinterest profile of a person named Jane Doe located Okaloosa County, Florida who is obsessed with carrot cake, or maybe a Minecraft user whose handle is her real name Jane Doe and has a carrot cake themed world. Now in an absolute worst case scenario the news channels could be reporting that a little kid connected with a predator because he was able to identify her partially because her IP was leaked over a series of dumb Wikipedia edits that were easy enough to recognize as unhelpful and revert with the click of a mouse (or even the action of a bot). The headline would be ridiculous, but it's still something we don't want to deal with. CheckUsers already have to be careful about accidentally making such connections, and now a lot more people with less experience are going to have to exercise the same discipline. On the other hand, if an admin is blocking /16 range for a major ISP like CenturyLink or Comcast to block one school, maybe the admin is being a little overzealous with his/her blocks. There's no reason to block millions of people to stop one kid or even 50 kids from writing something silly on an article. PCHS Pirate Alumnus (talk) 13:06, 5 November 2025 (UTC)[reply]
Users stop editing for far more reasons than simply a range block being issued. And you'll find a ton of users that become inactive all the time, and some of these inactivities are bound to coincide with a rangeblock. Not everybody with an extremely common name that stops editing after a range block did so because they fell within the range block. Far more commonly, they stop editing simply because they do not decide to continue editing. Aaron Liu (talk) 14:12, 5 November 2025 (UTC)[reply]
I'm speaking from experience with CheckUsers issuing blocks on IPs; there have been times I've been able to identify the IP address of a user just by looking at their block log. The exact details of how or why do not matter as much as the obvious increased probability of someone's identity being outed with less experienced administrators (and even non-adminstrators) now having access to private information (which would have been public before and therefore no big deal). Also, I'm well aware of wide range blocks. To say I think they're detrimental to the project is sugar coating it for the sake of civility. PCHS Pirate Alumnus (talk) 14:31, 5 November 2025 (UTC)[reply]
Sometimes you can assume who a rangeblock is intended for, but the common practice is to have another CU place a rangeblock or long-term IP hardblock for you to obfuscate such connections. Most of those possible connections you've assumed are likely a CU picking up a block for another CU. As far as the type of disruption that the wide rangeblocks are most often preventing here's a recent example from my own talk page, I will work to ensure you never feel safe at an WMF event ever again... I'll find your wife and tell her exactly what you are, a pedo£%ile protecting scumbag who tried to cover his tracks when he got caught. Maybe she'll be the one to shoot you? There is an enormous amount of serious abuse and threats that too many editors have to deal with on a day to day basis. Having to block wide ranges is unfortunate, but they are a necessary part of dealing with abuse on Wikipedia. Or maybe people should have to just deal with death threats and abuse? I guess that's always an option, too. ScottishFinnishRadish (talk) 16:14, 5 November 2025 (UTC)[reply]
I should clarify that there is a huge difference between enacting a large rangeblock to attempt stop a dedicated idiot like the one you have descibed and ephebiphobically enacting a large rangeblock to stop sporadic test editing and silly vandalism from elementary and high schools (and blocking public libraries, research hospitals, Ivy League univerities, and whatever else falls in that wide /16 range in the process), something I know for a fact some admins do. I've been on the receiving end of what you are describing and am well aware of the disruption someone like that can cause. PCHS Pirate Alumnus (talk) 17:11, 5 November 2025 (UTC)[reply]
Another factor is that many good editors get fed up and leave after spending a year defending the articles they wrote or maintain from test edits and other idiocy. Many passing IPs (now TAs) change dates or remove critical words like not to change the meaning of a sentence. Hilarious, but significant numbers of very good editors abandon Wikipedia because they feel that they are not supported. In addition to what has been described above, a range block can help retain good editors. Johnuniq (talk) 04:40, 6 November 2025 (UTC)[reply]
Just checking — The cookie will expire 90 days after its creation means that the cookie expiration is not refreshed by subsequent visits by the same browser? So an "IP editor" will get a series of user names – a new name per browser every 90 days? Which means that any discussions in the user's talk page will need to be linked or moved to the new account if the discussion is to continue? Is the cookie lifetime 90 days on all wikis? — GhostInTheMachinetalk to me15:35, 11 September 2025 (UTC)[reply]
Since its not possible to delete an account on Wikipedia due to attribution issues, does it mean temporary talk pages will be kept after 90 days? Messages from IP users get deleted after a few years, but remains visible in the edit history. JuniperChill (talk) 18:13, 11 September 2025 (UTC)[reply]
It is up to each wiki to decide how they want to handle the talk pages of old temporary accounts (leave them unchanged, blank them, or delete them). I don't expect enwiki to delete them. jlwoodwa (talk) 23:56, 11 September 2025 (UTC)[reply]
@KHarlan (WMF) "Yes, the cookie is per-browser..." If a user has 5 or 6 browsers, like one of my test computers has, this means they would get a different temp account on each browser, right? Does this have any real ramifications?
I don't see how this is any different than people with dynamic IPs completely changing their identity (my old ISP would give me a IP on one of several /16 ranges for example) in the same amount of time. Plus things have changed a lot since the 2000s (which is where a lot of people on the wiki seem to be stuck, no insult intended), a person can walk through downtown somewhere and access a variety of IP ranges like flavors of ice cream at Baskin Robins thanks to Wi-Fi using different ISPs at different businesses. PCHS Pirate Alumnus (talk) 13:23, 5 November 2025 (UTC)[reply]
To the best of my understanding: 1. it is 90 days after the temporary account was created (globally, not locally), which is public information, and 2. it has the same effect as blocking it for the remainder of its lifetime (modulo a brief difference in autoblock behavior at the end, perhaps). jlwoodwa (talk) 01:06, 12 September 2025 (UTC)[reply]
To answer your first question: When a temporary account has expired, this information is shown publicly on Special:CentralAuth. For example, at testwiki the temporary account ~2024-10120 is shown as having expired. I am not aware of an interface that shows when a temporary account is expected to expire (though you could estimate this by looking at when the account was registered and comparing it to the current date)
To answer your second question: Any block placed on a temporary account for longer than it's remaining lifetime will succeed. We do not prevent the blocking of temporary accounts for more than 90 days. One advantage with this is because there may be a need to track block evasion. For example:
A temporary account is editing disruptively and an admin decides to block the user behind the temporary account indefinitely (intentionally)
The admin communicates that this block is indefinite and editing the wiki again would be considered block evasion
The user ignores this and, after waiting till their old temporary account expires and waiting for any autoblocks expire, they edit again getting a new temporary account
A different admin receiving the report of block evasion can more easily see that there is still an active block on the first temporary account that applies to the user behind the account. Without a block longer than the expiry time of the temporary account, then the different admin would need to check that the intention was to block the user for more than the lifetime of their old temporary account
If there is no need to block the user behind the temporary account, then a block of 90 days as standard would be enough to always ensure that they are prevented from editing throughout the lifetime of that temporary account
"If there is no need to block the user behind the temporary account, then a block of 90 days as standard would be enough to always ensure that they are prevented from editing throughout the lifetime of that temporary account" Under what circumstances would we ever block a temp account without the need to block "the user behind the account"? Blocks (excluding some username blocks, which aren't relevant here) are always for the user behind the account, and not for the account itself. Fram (talk) 09:21, 12 September 2025 (UTC)[reply]
Yes, I agree that blocks are intended for the user behind the account and so in probably all cases the best approach would be to block the temporary account indefinitely.
I mentioned the last point primarily from the point of view that some wikis have requested that we change the default blocking period for temporary accounts on their wiki to 90 days (T398626). Without a change in blocking policy to indicate 90 day blocks apply to the user indefinitely, these 90 day blocks would no longer prevent that user from editing under the blocking policy after their original temporary account expires. WBrown (WMF) (talk) 09:38, 12 September 2025 (UTC)[reply]
Perhaps one nice thing about temporary accounts will be that they can be blocked like regular users, without special rules about block duration. There are many IPs out there that have only gotten 36 hour blocks or one week blocks, when a full account would have normally been indef'd. In other words, it simplifies blocking. (And of course the normal indef appeals process can be used. Indefinite is not infinite.) –Novem Linguae (talk) 21:47, 12 September 2025 (UTC)[reply]
Are blocks on previous temporary accounts only visible to admins, or are they visible all editors with TAIV permissions? CMD (talk) 03:14, 25 September 2025 (UTC)[reply]
@Chipmunkdavis the latter - TAIV gives you access to other temp accounts from the same IP.
To check the blocks on previous temp accounts from the same IP, use IP reveal, check the list of temp accounts using the IP, and then see if any have been blocked.
In addition (thanks to @WBrown (WMF) for this part), if the active temporary account is editing similar pages to other inactive temporary accounts, you could initially assume that these older temporary accounts are the same person as the active temporary account (especially if the topic isn't that active for editors). You could then confirm this by using IP reveal to look up the IPs of the temporary accounts you found and compare to the active temporary account.
Hey @ChildrenWillListen, yeah, I'm almost certain I've seen that question too but I'm not sure what you mean. A couple of thoughts:
How would you like to have them flagged, given that there are so many IP ranges? You can see different temp accounts using the same IP on Special:IPContributions (it will be blueified once temp accounts get introduced). You can read more about this page in the guide Temporary Accounts/Access to IP.
Definitely it's not possible to flag any connections publicly.
In the context of tracking abusers, we're trying to move away from treating IPs as the main identifiers. The connection between a person and a temp account, their editing patterns and other metadata is much tighter than that between the user and the IP. As an example, we expect that IP reputation filters will be useful in mitigating abuse without needing to target a specific IP address.
If the address is an IPv6, any temp acccount within the same /64 should be flagged. It is practically impossible for it to belong to someone else. We can filter by user agent here, particularly for IPv4 addresses since there's a possibility they're behind a NAT and the address is shared with multiple households.
Why not? We're just linking ~2025-3999-1 with ~2025-4002-3. No IP info is revealed. I'm not a lawyer, so I could be totally wrong here.
Currently, for people with TAIV access, you need two operations to find temporary accounts within an IP range, much like with the CheckUser tool. The more time you spend combating abuse, the less time you have to, well, build an encyclopedia. If this feature is introduced, a person can simply see at a glance that these accounts belong to the same network, and report/block if needed, which also reduces the number of IP reveals needed, improving temporary account privacy in the long run.
As for the connection between a person and a temp account, their editing patterns and other metadata is much tighter than that between the user and the IP, while this may be true in the short term, people can and will change their behavior, and sometimes technical evidence is the only way you can link them.
The answer to 2 is because you could link one temporary account to multiple IPs, eg. home and work. However, I agree with 3. Regarding How would you like to have them flagged, it would be useful if a temporary account contributions pages included any underlying blocks for IPs, and this could just include the type of block and reason without specifying the IPs. Similarly, any IP contributions page should on that page include blocks given to linked temporary accounts (presumably there is no need to hide the account name that way around). CMD (talk) 13:18, 26 September 2025 (UTC)[reply]
The answer to 2 is because you could link one temporary account to multiple IPs, eg. home and work.: No, because no IPs are revealed in the process. All you see is ~2025-3999-1 and ~2025-4002-3 share the same IP addresses. Unless you use the TAIV tool to reveal the actual IP addresses, you cannot come to that conclusion. ChildrenWillListen (🐄 talk, 🫘 contribs) 13:21, 26 September 2025 (UTC)[reply]
Has it always been permissible to link IPs to accounts publicly. For example, if an IP user gets blocked, and a new user does the exact behaviour (or vice versa)? Of course, CUs are not allowed to use the tool to link IPs with accounts. JuniperChill (talk) 00:41, 27 September 2025 (UTC)[reply]
If the behavioral evidence used to come to that conclusion is all public, then I believe it's always been allowed. Unlike things like a logged in user's IP address, there is no expectation of privacy for two accounts that behave the same and someone simply points out the similar behavior. WP:DUCK comes to mind. –Novem Linguae (talk) 03:32, 27 September 2025 (UTC)[reply]
@SGrabarczuk (WMF): This is definitely a welcome step, but I have a few more comments:
numbers are bucketed to protect privacy: 0, 1-2, 3-5, 6-10, 11+: How does this protect privacy? If the exact number of TAs is leaked, how would a bad actor be able to find the IP address of a temporary account?
We should *not* provide any details about which specific temporary account names are active on the same IP / IPv6 /64 range. Again, why? The whole point of temporary accounts is to prevent most users from seeing the IP addresses of anonymous contributors. It is not meant to conceal connections between different accounts operating under the same IP address/range. This information cannot be used to find the IP addresses of the underlying TAs.
Even if you don't agree with the above statement, it would be nice for people with TAIV access to be able to list the specific accounts with one click, since they would be able to do that manually anyway.
@ChildrenWillListen thanks for these questions and my apologies about the delayed response. Bucketing the numbers was a suggestion from Legal. We are talking with them about making these exact and we should have an update soon. Same goes for the second point you made -- we are currently looking into a way to show connected temporary accounts. I will be able to share more details once I have more clarity from engineering and legal about these. Thanks. -- NKohli (WMF) (talk) 11:10, 7 October 2025 (UTC)[reply]
@ChildrenWillListen: There is nearly the same probability of two or more people sharing an IPv6 /64 as being NATted behind a single IPv4 address. Homes and small organizations typically get a temporary IPv6 /64 assignment from their ISP for use on their internal network. All devices connected to the same internal network interface use one or more IPv6 addresses from the assigned /64. If you block the /64, all of the people connected to the internal network interface where it is assigned will be blocked. If you block a dynamically assigned /64 and it gets reassigned before the block expires, all of the people connected to the internal network interface where it gets reassigned will be blocked. 216.126.35.228 (talk) 01:07, 16 October 2025 (UTC)[reply]
Some mobile providers will assign the same /64 to all users within a certain area, though those often are already getting anon-blocked for long periods. Workplaces yes, but Wikipedia editing is not a common enough hobby where that's an issue unless the number of employees on a network is large and of course many employers don't want their employees editing on the clock anyway. That same relative rarity usually prevents issues when /64s are reassigned between end-users.
There have been a handful of genuine cases where one user within a household was blocked but the other, but it is to be sure an exceeding rarity. Admittedly I'm not around much, but I can't think of a case where someone's been unambiguously subject to a mistaken block for that reason since Roger Hui, and that was almost a half-decade ago. 184.152.65.118 (talk) 00:20, 3 November 2025 (UTC)[reply]
I do not think those APIs currently return whether a temporary account is considered expired. We can expose this information via the API if this would be useful for scripts (the pagetriagelist API returns whether temporary accounts shown in the API results are expired, so it should be easy to replicate this in another API).
If you could file a feature request on Phabricator for this along with any relevant use cases you see for it? If you'd prefer not, I can file it (if you give me a ping with any relevant examples you would see it being used for). Thanks and happy editing, WBrown (WMF) (talk) 20:51, 4 November 2025 (UTC)[reply]
WMF, in the FAQ it is claimed in the section "Would disallowing or limiting anonymous editing be a good alternative?" that this is "unlikely" because at the Portuguese wikipedia "On the other hand, there is evidence that this came at the cost of a significant reduction in non-reverted edits, weakening the growth of content in the Portuguese Wikipedia, and potentially leading to other negative long-term effects." As I described above, these claims seem false, and the growth or decline of ptwiki seems exactly in line with that of other large Wikipedia versions. There is no significant extra loss of new articles, user edits, or new editors compared to these other Wikipedias. See e.g. the number of active editors[7]. So based on what numbers do you claim these statements to be true? Fram (talk) 16:30, 11 September 2025 (UTC)[reply]
I'm very curious about this as well. Because the public research I've seen suggests it didn't harm ptwiki, but have had multiple conversations with various WMF staffers who firmly believe it did. While I expressed reasons other than this above why I supported keeping IP editing, that was before I realized that no matter what temp accounts reset after 90 days. So understanding what evidence we have about this would be important for me in any such discussion about disabling IP editing. Best, Barkeep49 (talk) 16:47, 11 September 2025 (UTC)[reply]
I too am interested in this question, and share Fram's concern that causal inference in statistics is very hard and at minimum a proper difference-in-difference model is necessary to attempt to capture the causal effect of disallowing IP editing on content, which we don't seem to have. KevinL (aka L235·t·c) 17:57, 11 September 2025 (UTC)[reply]
Hello! I want to first clarify about the metric. The leading metric we looked at for ptwiki is Net non-reverted content edits - defined as the number of content (main-namespace) edits that were not reverted within 48 hours, excluding bot edits, reverted edits, and edits that reverted other edit. We chose this metric because we felt it was most representative of the impact on the community's content health as a result of this change. Unfortunately this metric is not displayed by default on stats.wikimedia.org.
We have measured the impact of this change three times since the change was implemented: In August 2021, June 2022 and April 2024. Each time we saw a similar downward trend in Net non-reverted content edits. You can see how the numbers compare over the four years in the most recent report, Table 6. In Q1 of this year we saw a decline of as much as 36% compared to pre-restriction days. We also compared this trend with Spanish, German, French and Italian Wikipedias and did not see the same trend on those wikis.
You are right in noting that there have been many positive outcomes from this change as well - lower blocks, reverts, page protections -- all point to a decrease in vandalism on the project. The feedback from the survey was quite positive as well. However, we do not think the decline in net non-reverted content edits is worth the trade-off. @Benjamin Mako Hill and his team wrote about the Value of IP Editing to offer their perspective on this too in case you haven't seen it.
Lastly, I want to point out that before embarking on temporary accounts our team seriously considered turning off logged out editing as a viable alternative. Some of you might recall that we put out a call to communities that want to experiment with this change. The Farsi Wikipedia experiment was a result of this call. If this option did turn out to be viable, it would have been the easier way out - way less work than temporary accounts. Unfortunately the results from ptwiki and fawiki were not what we had hoped for. -- NKohli (WMF) (talk) 13:19, 12 September 2025 (UTC)[reply]
I find it disingenuous that you never mentioned the only metric that matters: the editors of ptwiki are happy with banning IP edits, and they have no intention of going back. Moreover, the metric you do focus on, net non-reverted content edits clearly shows that ptwiki was already in decline before it. Tercer (talk) 14:43, 12 September 2025 (UTC)[reply]
I disagree that editor happiness is the only metric that matters. I am here to serve our readers and so if our readers are being hurt by having old information, when new information would be possible, or (more importantly) incorrect information when correct information would be possible, that matters a great deal to me. It also matters a great deal to me about whether turning off IP editing harms the pipeline to gaining more new registered editors. Best, Barkeep49 (talk) 17:30, 12 September 2025 (UTC)[reply]
I generally tend to express my unhappiness instead of leaving right away if there is something I don't like, since I have invested a lot in the project. I imagine it's the same in other wikis Ita140188 (talk) 16:51, 15 September 2025 (UTC)[reply]
Perhaps you are a very dedicated editor that will stay no matter what, but you can't generalize this to everyone. Editors come and go all the time. I don't think there's really any doubt about whether unhappy editors tend to leave the project.
And in this particular case WMF has already been clear that it will push through regardless of editors' opinions, so "expressing your unhappiness" won't make any difference. Tercer (talk) 15:52, 16 September 2025 (UTC)[reply]
Also, it's not a good look reputation-wise if readers are exposed to more vandalism or long-term abuse, which they most likely will be in the long run with the temporary accounts feature. Not all vandalism is reverted quickly. For instance, to pick a relatively low-stakes example, if temporary accounts had been active here in May, I would never have discovered this edit because of the 90-day cutoff for retrieving IP information (see this comment of mine for more context). If push came to shove I would absolutely support discontinuing IP editing ... but we're basically damned if we do, damned if we don't. When I was invited to participate in the WMF's let's talk program, one of the reasons I agreed to do so was to bring up my concerns about this cutoff. ButI well know why it's been implemented. Graham87 (talk) 09:17, 14 September 2025 (UTC)[reply]
I think the only big issue with this is that everyone's complaining about traceability, since this doesn't really affect the reverting vandalism side of things aside from tracing. And this whole TA thing is literally reducing traceability, so you can't really get around that despite any attempt to do so. The alternative would be to set no expiration or longer expiration to the cookies, but then it would be basically 'we replaced IPs with something that looks a bit better but functions like an IP' 2A04:7F80:6E:D2B:900C:A6A9:FD99:F70 (talk) 14:31, 18 September 2025 (UTC)[reply]
Traceability is my main concern as well (see my comments above). In their FAQ, the WMF said that they are "open to extending" the 90 day period for IP retention. Maybe it should be increased?
In the same answer, they mention we could use "behavioral evidence or patterns of editing" but that's a bit hard to do for the occasional vandals with little edits. ARandomName123 (talk)Ping me!14:57, 18 September 2025 (UTC)[reply]
I could also see cases where a range IP user that clears cookies could either purposely or accidentally sock in a low volume way that would be really hard to notice based on behavioral evidence alone. In a recent AfD, I encountered an IP who nominated the article and then later voted when their range changed slightly. I don't think they intended to be malicious but I was able to flag that I thought these two edits were by the same user. But there wasn't really anything behavioral that stood out to connect the two edits and in the case of temp accounts, I wouldn't have been able to identify them as being from the same editor. Non-admins who frequently close discussions should probably have TAIV. Sariel Xilo (talk) 16:28, 18 September 2025 (UTC)[reply]
I wouldn't say the metric was already in decline before the date. It seemed to be just jumping up and down within the same range, but after that there was a very clear downward trend. Aaron Liu (talk) 11:47, 17 September 2025 (UTC)[reply]
There were roughly 195k non-reverted edits in 2017, 132k in 2019 (the baseline), and 107k in 2023. The decline from 2017 to 2019 was roughly 47%, much larger than the 22% decline from 2019 to 2023 that WMF considers so disastrous.
I don't think these numbers can be correct. I just checked, and the last 5000 non-minor mainspace non-bot edits on ptwiki[8] go back 2 days and 3 hours, which equals some 70,000 edits this month. This would mean that about half of those edits are not counted as "net non-reverted content edits", despite the much lower revert rate since disabling IP editing (revert rate in 2024 was below 6%). Is there any explanation anywhere what they actually consider to be "content edits"? Fram (talk) 16:37, 25 September 2025 (UTC)[reply]
Content edits are identified based on whether they are from a content namespace. This is the monthly average data (no idea why it's the heading of the first column instead of the last four); the numbers average all the monthly totals within that quarter instead of being a sum total. Aaron Liu (talk) 01:48, 26 September 2025 (UTC)[reply]
I'm not sure I agree with We chose this metric because we felt it was most representative of the impact on the community's content health as a result of this change. If community systems are overwhelmed in a community that has IP editing (with or with-out Temp Accounts) the edits that stay unreverted may be, on the whole, a net negative to the project and to its readers. Put another way: if a community is overwhelmed then the net non-reverted edits are lower pre-change than policies and guidelines would suggest they should be and if they are then not overhwelmed afterwards, may be showing the true rate. I also am not sure I agree that it is the only metric worth looking at - as I indicated above statistics about overall community health in terms of editor registration, retention, and "moving up the ranks" - also feel worth examination. I would suggest English Wikipedia is not currently overhwelmed and so we do have a good baseline - something I don't know was the case for ptwiki - but I do worry that these changes will overwhelm the system because of the extra work that it is going to require to dealing with unregistered accounts. Best, Barkeep49 (talk) 17:38, 12 September 2025 (UTC)[reply]
@Barkeep49 I did not mean to imply that this was the only metric worth looking at. Like you can see in the report we did examine multiple other metrics and also carried out community survey(s) to assess how the editors feel about the change. However this metric stands out as important to us because it indicates a sustained loss in high-quality contributions and has consistently been on a decline in ptwiki since the restriction was in place.
I would also like to add that our team has been continually working on delivering tools to assist with anti-vandalism work. hCaptcha, GlobalContributions, IP Info, AbuseFilter improvements (including IP reputation filters), UserInfo card etc to name a few. We strongly care about moderator burden and this is reflected in our team's priorities. If you have ideas for how we can do these better, your thoughts are welcome on the talk page. -- NKohli (WMF) (talk) 11:15, 15 September 2025 (UTC)[reply]
@NKohli (WMF) I did read the report and did see other metrics. In the most recent report the two other takeaways were favorable on disabling IP editing. The fact that the foundation has decided that the metric which showed a decrease is so alarming as to say it's a failure suggests that the WMF does think it's the only metric that matters. I appreciate you answer my question - I really do - but I think my original assessment the public research I've seen suggests it didn't harm ptwiki. needs to be amended to the public research I've seen suggests mixed results on ptwiki which does not, for me, justify the labeling the Foundation has chosen to attach to it. Best, Barkeep49 (talk) 14:36, 15 September 2025 (UTC)[reply]
It's also worth noting that @MuddyB: complained about the surge of vandalism on the Swahili Wikipedia (where he is an admin), following the enabling of temporary accounts, though as I understand IP editing may have been previously disabled outright on this wiki. [9]Hemiauchenia (talk) 23:32, 12 September 2025 (UTC)[reply]
Temporary accounts are going to be "rammed" down everyone's throats as they are being made for legal reasons. For better or worse, office actions exist for these sorts of matters. (And curiously Swahili Wikipedia was another one that had Vector2022 imposed over the wishes of the community. That said, Vector2022 has also now become universal across all wikis, as temporary accounts will also.) CMD (talk) 10:18, 13 September 2025 (UTC)[reply]
Please read the thread before commenting. The subject is banning IP edits as an alternative to introducing temporary accounts. It would also solve the legal problem. Tercer (talk) 11:25, 13 September 2025 (UTC)[reply]
You are misunderstanding the implications of the proposal. Banning IP edits is not an alternative to temporary accounts, both actions are technically independent of each other. Temporary accounts are becoming implemented whether IP edits are allowed or not. Even if en.wiki responds by banning article editing by IPs, we will still have to figure out how to work with temporary accounts on talkpages. CMD (talk) 14:35, 13 September 2025 (UTC)[reply]
Of course it is an alternative. If IP edits are banned there's no longer a legal reason for implementing temporary accounts. Are you claiming that WMF would nevertheless implement temporary accounts? Just out of spite? I find that hard to believe. Tercer (talk) 14:49, 13 September 2025 (UTC)[reply]
Why do you assume that when people say we should ban IP editing they are only referring to mainspace? But, yeah, as a practical matter, anonymous editing exists (and thus temporary accounts also exist) and that's not going to change any time soon. So the community needs to figure out how to handle them. RoySmith(talk)14:50, 13 September 2025 (UTC)[reply]
I think the WMF would implement temporary accounts because they already exist and have already been rolled out and will continue to be rolled out as a standard part of the underlying software for every wiki, whatever en.wiki does, rather than out of spite.I assume that in general the IP editing bans will be likely called for with the main space in mind because of the consistent raising of the pt.wiki precedent, as well as on-wiki precedent regarding how we currently handle protections and even weird situations like the ARBPIA ECP talk page restrictions. CMD (talk) 15:08, 13 September 2025 (UTC)[reply]
To be fair I don't think the latest surge in vandalism on swwiki is related to temporary accounts. WP:LTA/Wikinger decided to target swwiki in the past weeks/months on an almost daily basis. The LTA uses rapidly changing proxy IPs which is a burden to admins with or without temporary accounts.
I did a quick check and it seems to me that none of the swwiki admins enabled their access to temporary account IPs which also means they can't use features like IP autoreveal – and have no way of knowing (except based on behaviour) if a temporary account is a newbie or a potential LTA.
@Johannnes89 It's chaos—completely. Temp aacounts actors aee now on my blog, commenting gibberish. Good thing Wordpress can't comment without approval. Ditching them every now and then. Muddyb (talk) 13:21, 18 September 2025 (UTC)[reply]
I can’t see the blog comments but I bet all of them were written by WP:LTA/Wikinger. I don’t think the situation on your home wiki would be much different without temporary accounts (except that some tools currently require a few more clicks). Wikinger has annoyed different projects for years and unfortunately he currently chooses to annoy swwiki. You might want to check mw:Extension:IPReputation/AbuseFilter variables in case that’s helpful to fight against his proxy abuse (unfortunately many open proxy IPs are not known to IPoid). Johannnes89 (talk) 17:24, 18 September 2025 (UTC)[reply]
What's the point of comparing different months in different years (August 2021, June 2022 and April 2024)? This will not eliminate seasonality effects. Maybe it's not that 2024 saw less edits, but that April has generally less edits than August or June? Ita140188 (talk) 16:49, 15 September 2025 (UTC)[reply]
I think it inevitable that Wikipedia projects will disable anonymous editing in the future. As projects grow, the opportunity for anonymous editors to do anything productive continues to shrink. (1) The level of knowledge necessary to contribute positively to the projects keeps increasing. More policies, more guidelines, more standards, more templates. This growth in required knowledge is glacially slow but inexorable. (2) There is ever increasing lack of ability for editors to contribute in general due to the (ever unattainable, thankfully) goal of completing the project. The lack of productive work possibilities gives ever decreasing opportunities to anonymous users to contribute positively. (3) The ratio of administrators to the amount of work administrators need to do continues to worsen. Those are just a few of the factors in play that are driving this reality. Imagine, if you will, Wikipedia 50 years from now. There will always be growth to be sure, but the opportunity for anonymous users to do anything will be almost absent. There needs to be a long term strategy to reverse these trends, else new blood coming into the projects will die. We're already in a long term drought. --Hammersoft (talk) 14:52, 12 September 2025 (UTC)[reply]
There won't be any wikipedia 50 years from now. What wikipedia does is harness the energy of many people to read books, newspapers, journal articles, etc, and distill them into encyclopedia articles. In way less than 50 years from now, AI will be good enough to make that an obsolete concept. RoySmith(talk)01:26, 13 September 2025 (UTC)[reply]
Yeah, 50 years is quite optimistic. I can see the project lasting for another decade or two, but beyond that... I'm not so sure. Some1 (talk) 01:43, 13 September 2025 (UTC)[reply]
AI will be good enough to decide what is true? Leaving this to AI (ie. most likely to a private corporation) will never be acceptable, no matter how "good" the AI is. Wikipedia works because it's based on consensus among people. Ita140188 (talk) 16:37, 15 September 2025 (UTC)[reply]
Nah, there's enough spare capital Wikipedia won't go under. Most likely in 50 years it will be like Jane's Fighting Ships, minimal readers, but powerful nostalgic legacy project the caretaker's won't let go of. Server load drops with readership, and hosting fees are minimal. I would even venture the brand will be around in some form a century from now. 184.152.65.118 (talk) 23:55, 2 November 2025 (UTC)[reply]
I would second what Aaron Liu says. Doubtless editing has become more difficult than it was on average even a decade ago. At the same time we are always building new things and updating old ones. Massive amounts of information are added by casual and one time editors and quite often fully in compliance with policy, or easily tweaked to be so, without those doing the edits knowing the name of even one policy here. 184.152.65.118 (talk) 23:46, 2 November 2025 (UTC)[reply]
I think, let's see how it goes, but certainly keep this option open if it proves untenable, as I suspect it well might. I'm not tremendously impressed with WMF over this whole thing; there was a lot of pushback on the idea, so they came up with "We're legally required to do this!", but then when they were asked "By what law, where?", they wouldn't answer that. SeraphimbladeTalk to me08:46, 16 September 2025 (UTC)[reply]
any information relating to an identified or identifiable natural person’, including an online identifier that identifies the person directly or indirectly. Like an account identifier created just for that person that persists across IP addresses? I still think it's a lot of work to have gone through just to have communities disable IP/anon editing entirely. ScottishFinnishRadish (talk) 10:48, 16 September 2025 (UTC)[reply]
I think the defense is that it is the equivalent of a anonymized, randomly generated username. The data is (for all intents and purposes) anonymized and after 90 days, and a "random party" will not be able to map your TA to you with any level of certainty. Sohom (talk) 16:01, 16 September 2025 (UTC)[reply]
@Seraphimblade, You are framing the events in the wrong order: "We're legally required to do this" (WMF does nothing for a while) -> "We had some light regulator scrutiny" -> "WMF scrambles to implement IP Masking" -> "Community outrage at the initial idea" -> "WMF slows down, spends a lot more time building some anti-abuse tooling around it" (and now here we are). Also, the reason the WMF is cagey about why they need to implement it is because it's typically bad legal strategy to publicly proclaim "we are currently breaking this exact provision of GDPR". (And, yes we are probably flouting multiple privacy laws including but not limited to GDPR's absolute stance on IP addresses and CCPA's slightly more nuanced take on IP addresses) It's frustrating as a volunteer but I think understandable from the point of the view of the WMF. Sohom (talk) 16:16, 16 September 2025 (UTC)[reply]
It’s also bad legal strategy to publicly proclaim that you’re going to violate the ePrivacy Directive instead of the GDPR, by openly admitting in an FAQ that your cookies are not strictly necessary. But here we are. 98.97.4.79 (talk) 02:35, 17 September 2025 (UTC)[reply]
This cookie is necessary iff you chose to edit. (If your argument is somehow "we should not ever set a cookie", I'd like to see you defend the concept of a session identifier.) Regarding the ability to refuse the cookie, you are welcomed to refrain from editing and the cookie will not be set at all. (And if you clear your cookies regularly, a new one will be set, every session). If you do edit, you will be given a anonymous identity that will be destroyed/expired after 90 days. I don't see how any of this violates the ePrivacy Directive. Sohom (talk) 02:55, 17 September 2025 (UTC)[reply]
The cookie is not “strictly necessary for the delivery of a service requested by the user”, because the FAQ admits that editing will work just fine even if a browser discards the cookie. The purpose of the cookie is apparently to reduce the number of extra database entries created by the WMF’s own software, which is not a service requested by the user, so users must be presented with the option to accept or decline it. Sites can’t just say that cookies are “necessary” for their own private reasons; the law would have no effect if that were the case. 98.97.4.79 (talk) 03:14, 17 September 2025 (UTC)[reply]
Again, you have the explicit ability to click cancel on a edit or not edit at all which would be a declination to the cookie (and a declination does not adversely affect your reading experience). Also, the cookie is required not because of "the number of extra database entries" created, but rather for attributing the edit to a user, a service you request and agree to by clicking the big blue "Publish changes" (or the large "Reply" button). By doing that you are agreeing that the cookie essential for attribution is set on your device. Your argument does not make sense in this context. Sohom (talk) 03:29, 17 September 2025 (UTC)[reply]
Also, to put things into context Wikimedia's infrastructure is largely open-source in a way that no other top-10 website is. The Foundation does not share any identifiers, and has a privacy policy that is much more detailed than any other top-10 site. If you are looking for technical privacy violations, you are barking up the wrong tree here. The search engine you used to get to this site probably collects a order of magnitude more data about you than Wikimedia will ever get from it's temporary account rollout. Sohom (talk) 03:38, 17 September 2025 (UTC)[reply]
Access to specific website content may still be made conditional on the well-informed acceptance of a cookie or similar device, if it is used for a legitimate purpose.
Surely "the service as can be provided with a specific amount of labor" is the service? We could, in a strictly literal sense, serve pages as printed paper via FedEx, employing millions of clerks and envelope-stuffers, and this would require no cookies at all, but I scarcely think this would prove they were unnecessary all along. jp×g🗯️09:09, 17 September 2025 (UTC)[reply]
@Sohom Datta I wonder if the cookie would be unnecessary if it was technically possible to store all the device-identifying info at the host. Or is that even worse from a data collection standpoint? If course, the mechanism won't change this late in the game. David10244 (talk) 06:34, 11 November 2025 (UTC)[reply]
So the take away here is that despite claims to the contrary, there is no evidence at all that the disabling of IP editing at Portuguese Wikipedia had any actual negative consequences (i.e. results not also felt at languages which didn't disable IP editing or which weren't present at Portuguese Wikipedia before the disabling)? It seems that Portuguese wiki flourishes just as well (or as badly) as other languages in all meaningful statistics, that they are not considering reversing their choice, and that they have a lot less vandalism to revert. I suppose the WMf will adapt their FAQ and other documentation to correctly present this? Fram (talk) 10:26, 22 September 2025 (UTC)[reply]
The "Portuguese wiki flourishes just as well (or as badly)", I would not term a "reduction in good faith unreverted edits" in such a manner. Yes, editor morale is up, but there are less contributions overall potentially having less vandalism to revert but also potentially hurting the readers in terms of how updated the information is (or not?), make of that what you will. The answer is up for debate and to my understanding the WMF has decided to take the more pessimistic interpretation of data here (which is still valid within this context and does not constitute a misrepresentation). From your POV, you want to take the more positive interpretation due to your entrenched position/expected outcome of "turning IP addresses should not cause problems and instead will improve morale". What you have identified are a bunch of threats of validity, but these threats of validity are coming from a position of "I expected to see a different result" and the real answer is "there are indicators of a reduction in the number of edits but we don't really know for sure". Sohom (talk) 12:36, 22 September 2025 (UTC)[reply]
They have taken the one metric which vaguely supports their position if you don't consider that the same trend was visible before IP editing was disabled. And from that, they decide "Would disallowing or limiting anonymous editing be a good alternative? Unlikely." But sure, my "entrenched position", which is not the "real answer", is the issue here. Your "we don't really know for sure" is not the same as stating "unlikely".
I do wonder how many of the "non-reverted edits" prior to the disabling of IP edits were just unconstructive edits which were not found because the other editors couldn't catch them all. When I e.g. think back to the time IP article creation was allowed on enwiki, I recall that while many poor creations were found quickly, we still had a much larger number of unacceptable new articles which lasted for longer than 48 hours. If the same applies to "non-reverted edits" on ptwiki, then the decline in that number is even less of a sign of a problem. It's too bad that this metric happens to be the one we can't compare for ourselves (unlike the other stats, which turn out to indicate no problems at ptwiki compared to other wikis). Fram (talk) 15:36, 22 September 2025 (UTC)[reply]
I'm saying is that I think the data is up for interpretation, you are interpreting the data in a very specific way (that reflect your biases) and then heavily implying/making loaded assumptions about the WMF intentions based on that and trying to strong-arm that conclusion. (to be blunt) I think the WMF's interpretation of the data is also a valid perspective on the data (which does not invalidate other perspectives including yours). While I disagree with your heavily implied conclusion of "they cherry picked data", I agree that the WMF should have done a better job of distinguishing between subtle vandalism and good-faith edits, but I view that as a much more subjective metric that can be infinitely bikeshed and argued about, so I do understand why the WMF went with the specific parameter that they did. Sohom (talk) 16:06, 22 September 2025 (UTC)[reply]
You should read again the FAQ entry. WMF wrote that "The results have been largely harmful", and "we cannot say that disabling logged-out editing on any project is a beneficial solution". Such strong conclusions simply do not follow from this ambiguous data. And yes, it does reek of ideological blindness. Tercer (talk) 17:20, 22 September 2025 (UTC)[reply]
I have read the FAQ, you are quoting editorialized text out of context. Most studies/report/research present a broad conclusion ("we found X"), while underlying that are always caveats and assumptions about other factors (X, Y, Z) possibly being (ir)relevant. If we decided to demand the level of rigour that you demanding from the WMF, such that no statement can be ever be stated unless every possible confounder (X, Y and Z) was fully resolved, we'd need to start revising a large majority of academic literature. Yes, the WMF should have done a better job of representing the other relevant factors but that does not detract from the fact the interpretation is valid within the data they had and you are within your right to disagree with that conclusion since you interpret the data differently. Sohom (talk) 17:55, 22 September 2025 (UTC)[reply]
Trying to get my head around the WMF claims about why the Portuguese experiment is not successful. Their 2024 study[10] claims:
Revert rate decreased by 47%
Non-reverted edits is 20% lower
Non-reverted mainspace edits 22% lower
They compare 2019/2020 with 2023/2024, which is partially a bad fit because 2020, the Covid year, was an outlier in nearly all statistics. So let's compare 2019 to 2023. This[11] is the total number of edits by editors per month. Comparing 2019 to 2023, we get
January: 155613 vs. 183959
February: 137478 vs. 156183
March: 155340 vs. 174412
April: 139152 vs. 144277
May: 169299 vs. 155512
June: 160814 vs. 150569
July: 175301 vs. 148916
August: 162330 vs. 151748
September: 158192 vs. 146822
October: 151785 vs. 156850
November: 158451 vs. 139514
December: 139242 vs. 147410
Total: 2019 = 1862997, 2023 = 1856172. I hope I have not miscalculated anything, please check!
So 6 of the 12 months show an increase in edits, 6 show a decrease. In total we have an extremely feeble decrease of 6825 edits, or less than 0.5%!
But we have a 47% "revert rate decrease", which are at least 2 edits each time which are no longer being made (1 or more edits to revert, plus the revert), for which we sadly only have a percentage, but which dropped from 10% of the edits to 6% of the edits. Meaning that (4*2) 8% of the edits being made in 2019, some 150000 edits, no longer need to be made in 2023 (and of course this also means that 75000 vandal revert edit, which are "non-reverted content edits", no longer need to be made: perhaps these are the "missing" edits in the WMF reasoning?)
Overall, it seems that we have an actual clear increase in good edits on ptwiki between 2019 and 2023, instead of the decrease the WMF claims and uses as its basis to declare the ptwiki disabling of IP editing unadvisable. Fram (talk) 16:58, 24 September 2025 (UTC)[reply]
Edits reverting vandalism were not counted as "non-reverted content edits":
Net non-reverted content edits are defined as the number of content (main-namespace) edits that were not reverted within 48 hours, excluding bot edits, reverted edits, and edits that reverted other edits.
Thanks. Then I understand even less where they have found such a drop, when the tital number of human edits is nearly the same and the number of vandal-revert couples clearly dropped. Fram (talk) 17:38, 24 September 2025 (UTC)[reply]
Hello again, on behalf of the Product Safety and Integrity team. First, thank you for all the comments above and all the effort you are putting into making this a smooth change. We wanted to acknowledge all the discussions here and on Discord, changes to existing tools, updates to meta-pages, the mention in yesterday's Signpost, and other steps you've taken. We are grateful for your openness and curiosity about temporary accounts and new tools.
Technically, everything appears to be ready for deployment next week. However, we have decided to postpone the deployment to October 21st (by two weeks). We are going to take this time to hold more discussions – we want to meet with you to discuss the deployment and clarify anything about the tools you may still be unsure about. We will also put together some additional guidance and documentation to help you prepare to use the new system.
Taking this opportunity to look back at all the discussions, we wanted to comment on a couple of points:
Users who currently can block IP addresses will still be able to see and block IP addresses from temporary accounts.
From our deployments so far, we do not see evidence that volunteers are experiencing increased burden in managing abuse from logged-out editors. Since 2023, we've been working with stewards and other trusted volunteers to figure out what is needed to effectively handle abuse from temporary accounts. This appears to have been successful on other wikis, and we would not be proposing deployment if we were seeing evidence that this was going to increase community burden.
Since this project was first announced years ago, our approach has changed. Initially we called it IP Masking, which focused on just one problem – IP addresses being so visible. Now, it's called Temporary Accounts, which is not only about hiding IPs – it's an additional and separate layer, with new tools built specifically to allow more precise actions (per Wikipedia:IP addresses are not people).
Some tips on the tooling:
We updated AbuseFilter to support matching against the IP address of a temporary account, though this isn't technically bi-directional support.
Special:IPContributions allows viewing all edits and temporary accounts connected to a specific IP address or IP range. (Bear in mind that a temporary account may be using multiple IPs though.)
We expect that IP reputation AbuseFilter filters will be useful in mitigating abuse from logged-out editors, without needing to target a specific IP address.
The User Info card makes it possible for anyone to see the bucketed count of temporary accounts active on the same IP address range.
If you'd like to test some of your workflows with temporary accounts enabled or learn more:
We have set up a Patchdemo. Log in as user: IP Viewer, password: password321!. You may also patrol temporary accounts via Test1 and Test2 history pages.
We invite you to read the Access to IP page and suggest changes to it.
My primary ask is that you seriously consider extending the duration IP addresses are available (currently will be set at 90 days). Please monitor this experience closely, as I believe that erasure will cause us to lose some control over persistent threats. Among other things, we'll be unable to assess collateral damage from blocks as readily as we currently do, and we'll lose the ability to track periodic IP hoppers to identify the proper breadth of a range block. — rsjaffe🗣️21:01, 3 October 2025 (UTC)[reply]
It seems highly unlikely that will happen. However, I could see it making sense to spin up a TAIV wiki, similar to checkuser-wiki, where TAIVs could maintain data on an as-needed basis. I suspect there will be some pushback to that idea, but consider that if we provide people with a secure and convenient way to store the data, they will use that. If we don't provide that, the data will still get stored, except now it'll be on post-it notes, files on people's laptops, Google Docs, and all sorts of other places where we have less control over it. RoySmith(talk)22:43, 3 October 2025 (UTC)[reply]
I agree. Most permanent accounts have little to no edits. Of the almost 50 million accounts we have on Wikipedia, only 2,5 million are autoconfirmed, and even then, the vast majority of them are inactive. The original reason why I wanted to create an account was so that I don't reveal my IP address, but I didn't notice I have other benefits like editing semi-protected pages (although I almost never edit protected pages even if I have the ability to), moving/renaming pages directly and gaining additional permissions (I have page mover and template editor, both of which have <500 users). I only made a few edits on the month I created the account, before properly editing from 2023. JuniperChill (talk) 17:50, 5 October 2025 (UTC)[reply]
We've said why multiple times in this thread, if you didn't take the time to read through it, please do before commenting. Sohom (talk) 02:05, 4 October 2025 (UTC)[reply]
I have an idea to help track IP hoppers while still preserving privacy. My initial thoughts are that, when a temporary account is blocked, to add a block log entry to the underlying IP(s) as well, so that retrospective analysis could detect the amount of disruption occurring from a specific IP. To protect identity, the log entry could have a different time (e.g., rounded to the hour or to the day), and would only list the type (partial vs regular) and duration of block. Omitting the text entry from the original block prevents leakage of any identifying info in the narrative the blocking admin added. Any thoughts? — rsjaffe🗣️18:52, 12 October 2025 (UTC)[reply]
A minor addendum to the list of feature changes - we also updated Nuke so that when temporary accounts are deployed, administrators entering an IP in the tool will fetch all pages created from any temporary account which used that IP. Samwalton9 (WMF) (talk) 07:14, 6 October 2025 (UTC)[reply]
Ah yes, that FAQ, where you still use the debunked claims about Portuguese wikipedia to dismiss calls to simply disable IP editing instead. Please see the section right above this one on the discrepancy between the numbers used by the WMF (from the sole metric which supposedly supported tjhis), and the actual numbers from this metric, and the evidence from other metrics. If you can't present this fairly, then why should we believe any of your other claims about experiences with temp accounts on other wikis? Fram (talk) 09:43, 6 October 2025 (UTC)[reply]
What’s even the point of all this? Wouldn’t it be objectively more efficient, and far less time and energy consuming when it comes to fighting vandalism, to simply allow only registered accounts to edit? The way this entire process is being handled feels like the WMF is forcing temporary accounts on everyone without genuinely considering the many meaningful and well-reasoned concerns and proposals raised by numerous editors. Based on evidence from the Portuguese Wikipedia, it seems clear to me that disabling IP editing had no negative consequences and actually freed up a significant amount of time and energy for editors and administrators there. I genuinely don’t understand the rationale behind the WMF’s refusal to consider proposals allowing only registered accounts to edit. — EarthDude (wannatalk?) 14:58, 6 October 2025 (UTC)[reply]
A very minor counter-vandalism consequence is that you now have to use regex search if you want to monitor talk pages by individual IP range (or do any other kind of searching-based review of temporary account edits), since the only searchable identifier unique to temporary accounts is a tilde character. Temporary account viewing permissions won't do anything to help there. Monitoring all new talk page edits by date still seems to work, though. Gnomingstuff (talk) 20:20, 11 October 2025 (UTC)[reply]
I'm really late on this (but still aware that this has been going on for a while), and I honestly think that this change, while probably necessary, basically kills my motivation to continue tracking LTAs on Wikipedia (I've already been inactive due to real life stressors, but I still sometimes have a few LTAs/anon vandals I look at).
As one example, I often check multiple IP ranges for evidence of a specific LTA or vandal, and with the hiding of IPs, I'll have to make way more assumptions about a particular anonymous user rather than saying "yeah, they're editing these pages + I know they've used this IP range before, so this is probably X vandal." This especially will happen when I talk to admins and "vandal fighters." I'm not sure if I'll be able to use the TAIV right to keep checking specific ranges for vandals. wizzito | say hello!16:05, 1 November 2025 (UTC)[reply]
e.g. I check the range 50.48.0.0/16 (block range · block log (global) · WHOIS (partial)) pretty regularly, because I am aware of two disruptive editors on there - one (actually active right now) makes bad copyedits to racism and hate crime-related articles (see User:Beyond My Ken/Bad copyediting IP) and the other makes unsourced edits to mostly voice actor, Pokemon, and political articles (although they did acknowledge their behavior relatively recently). I guess I won't be able to look at that /16 anymore and have to monitor specific pages for specific behavior, which is hard but somewhat doable. wizzito | say hello!16:10, 1 November 2025 (UTC)[reply]
Nope, they won't yes, looking at the range will be logged (for compliance purposes), but a reason will not need to be provided. Sohom (talk) 16:22, 1 November 2025 (UTC)[reply]
Well, I mean, you have a pretty good justification, and they're not going to check on every single person accessing IP addresses unless they detect bot-like behavior or something like that. This is all security theater for legal purposes, not something actually meant to protect the IP addresses of anonymous contributors. ChildrenWillListen (🐄 talk, 🫘 contribs) 16:22, 1 November 2025 (UTC)[reply]
@NKohli (WMF), EMill-WMF, SGrabarczuk (WMF), and Samwalton9 (WMF): we have tried to duplicate the figures you (WMF) have provided to justify why the ptwiki example shouldn't be followed, but no matter how hard we try, we don't come anywhere near the given reduction in non-reverted content edits which is used as the sole justification for this. Depending on how we count, we get no reduction at all or a very minimal one, not the 20%+ one you use (see the latter parts of the above section, with calcs by me and by User:Aaron Liu). I (and judging from the above discussion quite a few others) really would like a better answer to this before proceeding with this. Fram (talk) 08:29, 8 October 2025 (UTC)[reply]
I wasn't involved in that experiment, just the work to ensure Nuke would continue to work & expand its capabilities for temporary accounts. Hopefully someone with more insight can get back to you soon, though it may take some time since this is about the details of data analysis. Samwalton9 (WMF) (talk) 09:55, 15 October 2025 (UTC)[reply]
@Fram, Tercer, and EarthDude: You're experienced editors, and I'm an intermediate editor. Beginner editors can't find this thread. If IP editing gets disabled, what stopping experienced editors from demanding that registration also get disabled and put behind a referral system?
Why is the top 0.01% of editors ignoring the curse of knowledge and speaking for the bottom 99.99%? When impatient new users face the user friction of mandatory registration, they also become unhappy[,] leave and the project dies. On the internet, there are many existing projects that frustrate power users, but projects that frustrate new users are dying.
@Graham87:Reputation-wise, vandalism and partisanship facilitated by anonymous editing is a relatively minor criticism of Wikipedia. Immediately after, the lead section criticizes clique behavior (from contributors as well as administrators and other top figures), social stratification between a guardian class and newer users, excessive rule-making, ... and ..., which would be worsened by disabling IP editing. Most vandalism isn't the sneaky kind that would affect our factual reliability. Furthermore, opponents of TAs appear mostly male, so how would disabling IP editing affect women wanting to start editing, and the systemic bias along gender ... lines? 173.206.134.138 (talk) 00:50, 9 October 2025 (UTC)[reply]
(edit conflict) With respect, I don't believe that your comparison to Nupedia is relevant. Nupedia was not a wiki and was written predominately by SMEs. Wikipedia and its sister projects are by nature collaborative, so I don't think that anyone will demand...that registration also get[s] disabled. The disabling of IP editing on ptwiki was a choice by that community and they have seen a reduction in vandalism on that project. Keep in mind that ptwiki is a lot smaller of a project than enwiki. I concur with CWL in that your accusations of gender bias in the opposition of IP editing here also appear to be unfounded; opponents of TAs appear mostly male is roughly in line with the overall gender bias of the project, which is mostly male, though in recent years involvement by female and LGBTQ+ editors has steadily increased. Aydoh8[what have I done now?]01:01, 9 October 2025 (UTC)[reply]
To answer the direct question, there is nothing stopping experienced editors demanding anything. Self-selection towards experienced users is always going to happen naturally. However, experienced editors are the group who have developed a variety of onboarding or outreach tools, so the potential that they would decide to end registration seems a small concern. As for the idea that social stratification would be worsened by disabling IP editing, that seems quite back to front. Disabling IP editing means there won't be a "class" of users flagging themselves as new and/or unwilling to be a recognised member of the community. CMD (talk) 03:42, 9 October 2025 (UTC)[reply]
Oh no, Wikipedia is going to die if we require users to create an account. Like almost every single website on the internet. That's why the internet is dead, right? So much friction! One has to think of a username... and a password. No, that's too much effort we would be demanding, clearly our very survival depends on implementing temporary accounts. Tercer (talk) 09:05, 9 October 2025 (UTC)[reply]
I am an experienced editor, but I will oppose any proposal demanding that registration also get disabled and put behind a referral system and I would expect others to do the same whatever happens to IP editing. That's what stops it happening. Phil Bridger (talk) 17:53, 9 October 2025 (UTC)[reply]
With the rollout of temporary accounts in just over a week, I think it would be a good idea to send a mass message to the user talk pages of all administrators of this imminent substantial change. We can use Wikipedia:Administrators/Message list for this purpose. For reference, in the past, we have used the list to inform administrators about the extended-confirmed protection level back when it was brand new, see e.g. Wikipedia talk:Protection policy/Archive 17#Draft mass message to administrators. If we sent one for that, then I think it makes sense to send one for this as well. I'm thinking we could send something like this, much of which is copy-pasted from above (see above for attribution):
Hello, {{subst:ROOTPAGENAME}}. This message is being sent to remind you of significant upcoming changes regarding logged-out editing.
Starting 4 November 2025, logged-out editors will no longer have their IP address publicly displayed. Instead, they will have a temporary account (TA) associated with their edits. Users with some extended rights like administrators and CheckUsers, as well as users with the temporary account IP viewer (TAIV) user right will still be able to reveal temporary users' IP addresses and all contributions made by temporary accounts from a specific IP address or range.
How do temporary accounts work?
Editing from a temporary account
When a logged-out user completes an edit or a logged action for the first time, a cookie will be set in this user's browser and a temporary account tied with this cookie will be automatically created for them. This account's name will follow the pattern: ~2025-12345-67 (a tilde, year of creation, a number split into units of 5).
All subsequent actions by the temporary account user will be attributed to this username. The cookie will expire 90 days after its creation. As long as it exists, all edits made from this device will be attributed to this temporary account. It will be the same account even if the IP address changes, unless the user clears their cookies or uses a different device or web browser.
A record of the IP address used at the time of each edit will be stored for 90 days after the edit. Users with the temporary account IP viewer (TAIV) user right will be able to see the underlying IP addresses.
As a measure against vandalism, there are two limitations on the creation of temporary accounts:
There has to be a minimum of 10 minutes between subsequent temporary account creations from the same IP (or /64 range in case of IPv6).
There can be a maximum of 6 temporary accounts created from an IP (or /64 range) within a period of 24 hours.
Temporary account IP viewer user right
How to enable IP Reveal
Administrators may grant the temporary account IP viewer (TAIV) user right to non-administrators who meet the criteria for granting. Importantly, an editor must make an explicit request for the permission (e.g. at WP:PERM/TAIV)—administrators are not permitted to assign the right without a request.
Administrators will automatically be able to see temporary account IP information once they have accepted the Access to Temporary Account IP Addresses Policy via Special:Preferences or via the onboarding dialog which comes up after temporary accounts are deployed.
Impact for administrators
It will be possible to block many abusers by just blocking their temporary accounts. A blocked person won't be able to create new temporary accounts quickly if the admin selects the autoblock option.
It will still be possible to block an IP address or IP range.
Temporary accounts will not be retroactively applied to contributions made before the deployment. On Special:Contributions, you will be able to see existing IP user contributions, but not new contributions made by temporary accounts on that IP address. Instead, you should use Special:IPContributions for this (see a video about IPContributions in a gallery below).
Rules about IP information disclosure
Publicizing an IP address gained through TAIV access is generally not allowed (e.g. ~2025-12345-67 previously edited as 192.0.2.1 or ~2025-12345-67's IP address is 192.0.2.1).
Publicly linking a TA to another TA is allowed if "reasonably believed to be necessary". (e.g. ~2025-12345-67 and ~2025-12345-68 are likely the same person, so I am counting their reverts together toward 3RR, but not Hey ~2025-12345-68, you did some good editing as ~2025-12345-67)
Excellent idea, thanks @Mz7 for working on this! Tbh I had the same idea and was going to start a draft today :D I was/am going to send this message to CUs, TAIVs, basically anybody with access to temp account IP addresses. SGrabarczuk (WMF) (talk) 14:56, 13 October 2025 (UTC)[reply]
Agree that this should be a MassMessage (in addition to a watchlist notice). That MassMessage should give a brief rundown of Wikipedia:Temporary account IP viewer#What can and can't be said. If you can be desysopped for sharing information with unauthorized parties, you should get a clear warning; not all admins are active every month of the year, so a watchlist notice would be insufficient in my view. On the other hand, to alert non-admins, a WLN would be great. Maybe include do one nowWP:PERM/TAIV applications, hopefully decreasing the rush? HouseBlaster (talk • he/they)16:58, 15 October 2025 (UTC)[reply]
This is a good idea. I am a little worried the mass message might be getting a little too long, but I do think it is important to note that directly connecting IPs to temp accounts is going to be against the rules. Mz7 (talk) 02:19, 16 October 2025 (UTC)[reply]
I'm trying to get my head round the "Guide to temporary accounts" that we have now received, and what I see is that it just got a lot harder to be an admin. I haven't noticed this question being put above or below: isn't there any concern that the new system will lead to a drain of active admins present and future? Especially of the not-very-technically-minded admins such as myself. (We exist, and we even have some uses.) I'm really not sure I want to be an admin any more, with this tricky roundabout method for avoiding the disallowing of IP edits. Compare the discussion of Portuguese wikipedia above. Bishonen | tålk14:51, 31 October 2025 (UTC).[reply]
Same for non-admins with TA access, the chances of e.g. inadvertently "outing" someone (by e.g. linking temp accounts through stating their IP addresses where it is no longer allowed) seem to have increased significantly, and I will not ask for that right to avoid just such issues. I still see zero benefits from this whole system over disallowing IP editing completely (or in the mainspace at the very least). Fram (talk) 15:10, 31 October 2025 (UTC)[reply]
Per the comment below there are some improvements on the way to reduce the amount of clicks required to reveal the IP information. The IP auto reveal should be on for 3 months at a time which for all intents and purposes should mostly return the state of things back to normal-(ish) for 3 months at a time. My personal thought is for us to atleast give the feature a try. Sohom (talk) 15:12, 31 October 2025 (UTC)[reply]
Bish, you can just ignore them or post it to someone else to deal with, eg me while I'm around! Not sure where the tools menu to turn it on permanently is meant to be.
I don't know from trick or treaters, but I did see an orange T-Rex shuffling down the street this afternoon. Which is kind of weird because I thought T-Rex season was over by now. RoySmith(talk)01:00, 1 November 2025 (UTC)[reply]
Personally, I'm planning on not enabling the ability to view the IPs, and leaving it all to people who're comfortable being mini-checkusers with all the restrictions that implies. I don't do much work in the areas of adminship that deal with IPs as anything other than just-another-identifier anyway. Anomie⚔17:40, 31 October 2025 (UTC)[reply]
That discussion is disappointing to me. There was all this talk about sending out a mass message to all admins, making a guide for this, discussion about changes before this happens, and even videos to help guide people with using the system. But yet, the same users avoided the questions asked to them, with one exception who said they were not involved.
Personally, that is making me distrustful of this whole thing. Hopefully things go smooth as there seems like there is the potential for it to be a problem. --Super Goku V (talk) 23:09, 1 November 2025 (UTC)[reply]
The mass message was sent out, the guide was community driven (there is a bunch of WMF docs and those are being improved) and the changes below are being worked on. Sohom (talk) 00:13, 2 November 2025 (UTC)[reply]
Yep. My point was that so much was done here by certain editors, except answer the questions regarding the Portuguese Wikipedia numbers. That is why I am starting to be distrustful as the claims from the FAQ are not being backed up. --Super Goku V (talk) 03:08, 2 November 2025 (UTC)[reply]
There have been many questions and I believe many people have been doing their best to answer them. @Super Goku V: Is there a specific question that you want to be better addressed? jlwoodwa (talk) 01:09, 2 November 2025 (UTC)[reply]
There is a question, but it can only be addressed by certain users. The question is to the WMF employees about how they got the 20% reduction in edits for the Portuguese Wikipedia. There was one employee who did answer, but only to say that they were not involved with that. --Super Goku V (talk) 03:24, 2 November 2025 (UTC)[reply]
This does seem helpful. Thank you very much for including it, Sohom.
(I will need more time to fully read it, but having done a quick read I find the line We find evidence for this tradeoff even within the editing activity of editors registered prior to the cutoff, demonstrating how participation by unregistered editors stimulates activity across the board to be the most significant so far.) --Super Goku V (talk) 15:01, 3 November 2025 (UTC)[reply]
Chiming in here because I got the admin mass message, I wanted to share a few things that are relevant I think. Many years ago at the Foundation, I did some work with data scientists to measure anonymous editing and experiment with inviting (not requiring) them to log in. I had this hypothesis that many anonymous editors simply didn't realize or hadn't even considered signing up. It essentially didn't work. It increased registrations, but resulted in a net loss of total unreverted edits. We even tried several different approaches, like both before and after someone saved.
Very interesting to note as well is that the results differed slightly across English, German, French etc. (though none of them worked overall). This is the most important lesson to me, because it reinforces that there are significant differences in how policy or software changes work on different Wikipedias. For context, ptwiki is heavily dominated by Brazilian editors. In Brazil, culture is extremely social and it's the number two country by total time spent online per person [12][13]. When we talked to Brazilian editors, many experienced editors said that they wouldn't even mind if we offered Facebook login to make signing up for Wikipedia easier (obviously this wouldn't be allowed by the privacy policy and we never even considered doing it).
TL;DR: Even if you think disabling IP editing was good for Portuguese Wikipedia, it might not have the same impact on English-speaking readers and editors. In my view, it is pretty likely to be more negative here, given the cultural dynamics of ptwiki in general. Our past experiments indicate that even optionally asking people to log in just distracts them and doesn't increase high quality edits. Steven Walling • talk02:48, 3 November 2025 (UTC)[reply]
Which may all be true, but it doesn't explain why the WMF needs to make apparently false claims about ptwiki and the results to justify their decisions. Not the first time their "research" and "claims" turn out to be incorrect and skewed to support the WMF narrative. And then they wonder why some people are so negative and distrustful about the WMF... Fram (talk) 10:17, 3 November 2025 (UTC)[reply]
I think you've just done the same thing you're critizing the WMF for, which is also harmful. The WMF hasn't made false claims it's made incomplete or if one wants to reach for the maximally strong word misleading claims. Best, Barkeep49 (talk) 12:39, 3 November 2025 (UTC)[reply]
They claim a 20% reduction in productive edits, but this isn't true. When asked about this, no reply, and no change to their claims. There is nothing "incomplete" about these claims, and yes, they are misleading, because they are wrong. And the longer they remain silent about this, the more it looks as if they are deliberately wrong. But if it makes you feel better to claim that pointing this out is the same thing as making these claims, be my guest. Fram (talk) 13:08, 3 November 2025 (UTC)[reply]
Thank you for providing the link to the report and for trying to answer this Barkeep49. However, this was already discussed above in the same areas I was talking about.
If the WMF editors asked would be able to answer the questions asked or explain why they cannot, then I would appreciate it as it would at least attempt to address my concerns. --Super Goku V (talk) 14:37, 3 November 2025 (UTC)[reply]
Hello all, sorry about the radio silence here. We are taking some time to review the different points being made in this thread and asking our research analysts to evaluate some of these questions, on top of their existing work. Our apologies that this is taking a bit of time but we do still plan to post some substantive thoughts here once we have them. --
I appreciate the acknowledgement of this. While this isn't an answer, it does explain why there hasn't been one so far. (As an aside, thank you to the analysts for reviewing this.) --Super Goku V (talk) 19:24, 7 November 2025 (UTC)[reply]
Update: Removing clicks and tightening rate limits
Hey again! This is another update from the Product Safety and Integrity team. We took the time to meet with functionaries about how to make the temporary accounts deployment go smoother for your community.
A big theme of these discussions was that requiring users to make even small amounts of clicks and choices can add up to real time and cognitive load being piled on top of a community's anti-vandalism work. We also identified some relatively low-lift technical improvements to make it a little harder for vandals to engage in common block-evasion techniques.
Based on our talks with functionaries, we made two decisions:
We are introducing technical changes to significantly cut down clicks and choices needed to show IP addresses, and to tighten up how temporary accounts are rate limited.
To avoid these last-minute changes creating bugs or instability, we will delay deployment one final time, to November 4th. This lets us deploy these changes through our normal processes.
The biggest change is that we will allow IP auto-reveal to last for up to 3 months to reduce the practical and cognitive load involved in showing IP addresses. (T407222) This doesn't change who can see temporary account IP addresses, but should make the work easier for many of those who do.
We're also updating the onboarding dialog to allow users to turn on 3-month auto-reveal at the same time as they opt into generally having access to temporary account IPs. (T407257) This dialog is displayed to all users who can view temporary account IP addresses, the first time they visit relevant pages.
For rate limiting, we added a 10-minute limit to temporary account creations on top of the existing rate limits of 6 accounts per IP per day. (T405565) We are also now applying IPv6-based rate limits to an entire /64, rather than a single unique IPv6 address. (T406710) These changes are already deployed, so please do let us know if you see any issues.
These are the last changes we will make before deployment. We know that last-minute changes and delays are not ideal, but we felt that on balance it was worthwhile to take this bit of extra time to remove more friction and respond to community feedback.
We have also edited Mz7's draft of a mass message for admins to help introduce the feature and these changes. We'll coordinate on who will send a similar message for other users with access to temporary account IP addresses.
Finally, we've also created some instructional videos, to better explain how to work with temporary accounts:
10-minute limit to temporary account creations Should there be an exemption for the second account of the day? MediaWiki bugs gave me multiple TAs. Using Firefox, I received different TAs for frwiki and mediawiki.org. I also got blocked on zhwiki as a bot for clicking "Show preview" too many times in Firefox. After switching to Chrome, my first TA had an error with SUL cookies in incognito mode. 66.49.187.185 (talk) 04:00, 17 October 2025 (UTC)[reply]
SGrabarczuk (WMF), aside from the five projects who are converting from LiquidThreads to read-only Flow and from November 4 being the TA deployment date for this project, there is no specified date for the implementation of temporary accounts for the remaining projects (Wikimedia Commons, Wikidata, etc.) on phab:T340001. Codename Noreste (discuss • contribs) 04:50, 17 October 2025 (UTC)[reply]
Hey @Codename Noreste, that's correct, Commons and Wikidata must go after most large Wikipedias, and Spanish and Russian had their reasons to be excluded from the earlier deployments. We'll talk to these communities soon; we're just focusing on English now. Do you have a specific question about the remaining deployments? SGrabarczuk (WMF) (talk) 21:47, 17 October 2025 (UTC)[reply]
And it seems like according to the Phabricator link you posted, TAs are coming to the other WMF sites by the end of November (after English Wikipedia's introduction in five hours), with the notable exception of Russian Wikipedia. JuniperChill (talk) 19:02, 3 November 2025 (UTC)[reply]
I was gonna ask the same question (but say 00:01 to reduce the confusion between the start/end of day). But anyway, I would assume so given that computers (as well as Wikipedia itself) use UTC due to issues with DST in some regions. If so, TA implementation would begin in 4 hrs and 40 mins. UTC is also called GMT, but the latter is not used in the context of computers.
So in the US (assuming it starts midnight GMT), it would begin 3 Nov at 19:00 (ET) or 16:00 (PT). In NZ, its 4 Nov at 13:00.Edited 23:27 GMT: Actually, it turns out that TA implementation is from 4 Nov 08:00 UTC (midnight PT, 03:00 ET), per below comments. JuniperChill (talk) 19:18, 3 November 2025 (UTC)[reply]
That's why I said ET and not EST/EDT (I even checked if NY is 5 hours behind London, which it is). Its even more confusing that in the UK, winter time is called GMT while in the summer, its BST (British Summer Time). So when I see EST, I thought it meant Eastern Summer Time, not Eastern Standard Time (see article Eastern Time Zone for more). Plus the UK changes clocks at the last Sunday of March and the last Sunday of October while the US does it on the second Sunday of March and the first Sunday of November. This means that NY would be 4 fours behind London for a short period of time, until the UK catches up. Australia has three time zones in winter, but five in summer because not all states observe DST. Therefore, this is where the confusion lies regarding DST; hence why UTC exists. JuniperChill (talk) 22:02, 3 November 2025 (UTC)[reply]
Everybody should just use UTC and let people do their own local conversions if they want. This is why I have a UTC clock on my toolbar (in addition to the local clock). Computers are good at adding and subtracting. People, not so much. (Obligatory whine about why my damn car, which has 47 more computers in it than any vehicle should, makes me fix the dashboard clock manually twice a year). RoySmith(talk)22:35, 3 November 2025 (UTC)[reply]
I struggle with the conversion, so I just leave it in local time so at least I know how long ago a comment was. (As an aside, you do not want a device that assumes the time change, in case they change the rules. I had an alarm clock as a kid that I had to change four times a year.) --Super Goku V (talk) 02:04, 4 November 2025 (UTC)[reply]
(I'm the same person as the previous message, but I closed my incognito tab between that message and this one. When I tried to post this in my new incognito tab, I saw the message "Visitors to Wikipedia using your IP address have created 1 accounts in the last 24 hours, which is the maximum allowed in this time period. As a result, visitors using this IP address cannot create any more accounts at the moment." Isn't the limit meant to be 6 accounts per 24 hour period?) ~2025-30907-85 (talk) 08:26, 4 November 2025 (UTC)[reply]
This appears to be a bug. We're looking into it. There is a limit of 1 every 10 minutes with a maximum of 6 temp account creations allowed every 24 hours. -- NKohli (WMF) (talk) 09:30, 4 November 2025 (UTC)[reply]
Yeah, I don't think I would have been aware either if I didn't watch some admin talk pages many years ago. In other issues, I'm interested to see how LTA behavior will change in response to this. For example, will Andrew5 start clearing his cookies or use throwaway accounts instead (as I personally believe he already has, but this isn't a place to discuss that in detail)? wizzito | say hello!13:22, 4 November 2025 (UTC)[reply]
They usually aren't, except if file an unblock request on their user talk page (but in this case they can only edit their user talk page and only as long as the option to block talk page access isn't enabled) -> phab:T398673. Johannnes89 (talk) 17:44, 4 November 2025 (UTC)[reply]
This also adds significantly more time than I originally estimated. As a for instance, you need another page load to go from the temporary user IP contribution page to the IP contribution page if you want to use twinkle to place a block. ScottishFinnishRadish (talk) 16:33, 4 November 2025 (UTC)[reply]
Sounds like something that probably should have been addressed before a major rollout. This isn't a minimum viable product situation, this is the production environment on one of the top 10 visited websites in the world, and this seriously affects anti-abuse efforts which are entirely undertaken by volunteers. ScottishFinnishRadish (talk) 16:45, 4 November 2025 (UTC)[reply]
WP:AUTOBLOCK: There is an internal autoblock expiry time variable, which is set to 24 hours, meaning that autoblocks that are automatically applied will only last for that amount of time and will expire afterwards.That's just another issue, you have to look at the IP to see the history of editing to determine how long a block should be. It essentially adds a "check the IP" step to every temporary account block, which then adds an additional "Legacy IP edits" step to see the history from the IP, as the IP editing history is on a different page than the IP editing history since temporary accounts were created. Luckily this task only has to be completed ~10,000 times a month, so adding 30 seconds to a minute only adds 80-160 hours of volunteer burden a month. ScottishFinnishRadish (talk) 16:52, 4 November 2025 (UTC)[reply]
Why do you need to do that? When you encounter a vandalizing account you also don’t perform CU to check if there are other sockpuppets. Just block the TA indefinitely like any regular vandal account and only care about their IP / IP range if you observe a pattern of abusive behavior with multiple TA. Johannnes89 (talk) 16:55, 4 November 2025 (UTC)[reply]
The vast majority of reports at AIV were IPs. I look at the history of each to determine the correct block length. The point is to prevent disruption, not to allow someone to vandalize until they are blocked (assuming they're not changing their temporary account to avoid scrutiny and never get blocked) every 24 hours. ScottishFinnishRadish (talk) 17:09, 4 November 2025 (UTC)[reply]
You should treat vandalizing TA the same way as vandalizing accounts. If you would issue an indefinite block for a regular account, do the same with the TA. There's no point looking up the IP unless you suspect long-term abuse. Just as we rely on autoblock when it comes to blocking regular vandal accounts, autoblock is also sufficient in most cases when it comes to TA vandals.
~330x on frwiki (but ~200 of those from a single non-admin patroller who seems to use IP reveal much more often than anyone else on any project I've seen so far)
Those numbers used to be higher when TA got introduced on each project but after some time people realized that they need to look up the IP less often than we thought in the pre-TA time. Johannnes89 (talk) 18:07, 4 November 2025 (UTC)[reply]
You should treat vandalizing TA the same way as vandalizing accounts. If you would issue an indefinite block for a regular account, do the same with the TA. There's no point looking up the IP unless you suspect long-term abuse. That's entirely incorrect. If we're trying to prevent disruption then checking the editing history of the IP is a must. That log is also very inaccurate, I just checked the IPContributions page, revealing the temp accounts, of half a dozen IPs and it logged a single action. As I said, literally the first TA I looked at today was abusing the ability to reset their account to commit personally targeted bigoted vandalism. They had far surpassed the point where they would have been at AIV, but due to the way temp accounts work, they hadn't been reported. ScottishFinnishRadish (talk) 18:42, 4 November 2025 (UTC)[reply]
There's simply no need to check the IP for every TA just to make sure they haven't been operating other TA's on the past – based on your way of thinking you would also run CU on every vandalizing account just to make sure they haven't used other vandal accounts?
I would be curious to see which TA you are talking about (we could also continue discussing the specific example offwiki). Personally targeted bigoted vandalism that sounds to me like a something people could report no matter how many times the TA vandalized. Blocking one TA would have stopped the vandal due to autoblock – no matter how many other TA they created (blocking old TA once the vandal has moved on already is also not needed by the way, they can't re-used old TA once they abandoned them). Johannnes89 (talk) 19:01, 4 November 2025 (UTC)[reply]
Is anyone else getting a weird bug of usernames getting cut across the linebreak in mobile watchlist view? I suspect it might be an issue only for admins and/or editors with temporary account viewer permissions? signed, Rosguilltalk15:46, 4 November 2025 (UTC)[reply]
Is there really no way to see ips short of tracking down the edit on recentchanges or the watchlist? Nothing in history or diffs or Special:Contributions (for the temp account - though at least on that, I get the ipinformation collapsed box, with everything except the ip itself), and even turning on autoreveal doesn't do anything. —Cryptic17:18, 4 November 2025 (UTC)[reply]
Way up above, I was one of several people to express concerns about the fact that IP addresses are only stored for ninety days. I just found and reverted some fairly severe vandalism from May last year; if temporary accounts had been used then, that edit would've been even harder to track down without going to the article in question and checking the page history. Here's what happened; today I came across an IP address on my watchlist that turned out to be part of a problematic school IP range, 168.212.0.0/16. I noticed that the range had been blocked several times. I know many people wouldn't go to the lengths of doing this, but I audited all edits from that range since the expiry of the last block in April 2024, which is how I found that vandalism among other things that escaped the three-month window. I messaged the admin who had previously blocked the range and he re-blocked it. These sorts of problems are why I think that with temporary accounts the way they are now, we should be more severe with blocks of school IP addresses, because by default they'll be firehoses of vandalism. Feel free to move this message if it'd be more suitable somewhere else. Graham87 (talk) 15:19, 8 November 2025 (UTC)[reply]
And some of our worst IP hopping vandals, including this one, are just blasting right through temporary accounts; I hoped this rollout would help stop some of these people, given that cookies are connected to accounts now, but oh well... wizzito | say hello!23:55, 11 November 2025 (UTC)[reply]
One thing we should have done was made people unable to log out of temporary accounts unless they forced it themselves (e.g. clearing browser cookies). This would have probably stopped some vandalism. wizzito | say hello!00:07, 12 November 2025 (UTC)[reply]
Another fun fact: it looks like a TA gets created when you try to make an edit, even if it fails. In my case, I opened an incognito window, tried to edit WP:Sandbox and hit an edit conflict. Ended up creating a TA with zero contributions and zero log entries. RoySmith(talk)02:50, 12 November 2025 (UTC)[reply]
The link shows 15 edits, with 14 of them by one account and 1 edit by another account. Are there other accounts associated with this vandal? For vandals who change IPs, is the activity you've linked to similar to what one would have seen with legacy IP edits, the difference being that the activity is partially obscured because there are two different accounts externally visible, rather than a single IPv6 /64 range? KHarlan (WMF) (talk) 07:18, 12 November 2025 (UTC)[reply]
You are right, sorry about that. Yes, the first edited over the course of ~60 minutes, then a second account edited once ~90 minutes after the first one stopped editing, and a third one created 11 minutes after the second one. KHarlan (WMF) (talk) 07:33, 12 November 2025 (UTC)[reply]
As an aside, long-term I think we will want to move away from using Twinkle for blocks and have everyone use Special:Block. I wrote the Twinkle block module 10 years ago as a way to block and issue a talk page template at the same time. That was the extent of it. Over the past decade, we've painfully been trying to maintain feature parity with Core. Now we're at a point where it's the opposite, and Core is missing functionality that's in Twinkle (phab:T392857). It will still be a "while", but the plan is to continue on with that effort and eventually there will be no need for Twinkle at all.
I guess just keep this in mind. Anything that you think Twinkle does better, please file a task or let me know, and we'll get it tracked. Ultimately I hope that, apart from browsing contributions or checking talk pages, admins will never need to leave Special:Block to do their job. — MusikAnimaltalk19:01, 4 November 2025 (UTC)[reply]
Twinkle's present killer feature are prefills and templates. It's also convenient that it's a dialog rather than a whole separate page. Izno (talk) 19:09, 4 November 2025 (UTC)[reply]
This is one of those things that happens 10,000+ times a month, so seconds add up to hours pretty quick. From the contribs page, it takes about 3-5 seconds to block through twinkle, including selecting the reason filling out the template. Just having to click and load Special:Block would double that time, and that's without filling things out, and then placing the template. ScottishFinnishRadish (talk) 19:25, 4 November 2025 (UTC)[reply]
A dialog is great, but it can't give you all the information you need with such limited space. For example, Twinkle only reports if there was any past block and gives only one set of details (and even then there are bugs!). I suspect most of us want to see the full log if there were any previous blocks. Special:Block does this, and likewise for any active range blocks.
The templates, prefills etc. are part of phab:T392857. That would indeed be a requirement if we were ever to retire Twinkle. Fortunately virtually ever wiki has this or a similar workflow, so it seems it's time to bring it to Core! :) Once we have that, I suspect you'll find Special:Block just as convenient as it will be designed as a "one-stop shop" for all things blocking. Heck, we could even throw in the contributions there in another accordion.
Anyway, fret not, as this is a long ways away. We'd need design and user research, a full product treatment, etc. Besides, Twinkle is a gadget which we as a community are free to continue to use and maintain. I just don't know if I will be able to maintain it, is all! The multiblocks project was a massive effort. I didn't have it in me to parity that in Twinkle. Especially after hearing the affirmation from @Novem Linguae, I figure engineering resources are better spent on Special:Block so that all wikis get the same benefits. — MusikAnimaltalk03:11, 5 November 2025 (UTC)[reply]
Yes, I almost framed it as that big for me also. Special:Block isn't especially slow if it had the parity of prefill/template, but having to make the context switch Sucks. Izno (talk) 19:27, 4 November 2025 (UTC)[reply]
What Izno and SFR said, essentially. Unfortunately for you, the software you wrote is good as hell and everybody finds it more usable than the other thing... jp×g🗯️22:24, 4 November 2025 (UTC)[reply]
Another Twinkle feature for sending a message to IP users is (was) the Shared IP notice. One could use the WHOIS link to fill out the name of the owning org. I guess this feature is no longer meaningful. But if a shared IP is blocked, how would an editor from that IP be able to know this in advance? David Brooks (talk) 22:42, 4 November 2025 (UTC)[reply]
The very, very similar temp account names make it a lot harder to spot the same editor in e.g. recent changes (not always easy with IPs, but at least often a lot easier than it is now). I didn't spot the pattern of edits from here in recent changes, would probably have been easier before today. Fram (talk) 16:15, 4 November 2025 (UTC)[reply]
This seems like a perfect opportunity for some add-on script which assigns colors to TA account names in the various listings. Perhaps as a hash of the account name, so they're stable across listings. I'm guessing it would be a no-brainer for somebody who is good at javascript. RoySmith(talk)16:20, 4 November 2025 (UTC)[reply]
It's not like there's a requirement for only one script though. A person with normal color vision could use a color-based script, one with color blindness but good acuity could use an icon-based script, etc. Anomie⚔15:14, 9 November 2025 (UTC)[reply]
One lunch later: User:Aaron Liu/TemporaPaint.js currently would give a text color. Sometimes the differences are small, though, so I plan to later add an inverted background color (which should also help readability a little) and maybe use a different hash function. Aaron Liu (talk) 17:54, 4 November 2025 (UTC)[reply]
As one of the many colour-blinds :) I've created my own text-based version that gives the temp user a replacement human-readable username. It's deterministic so a user should always get given the same username each time they're seen (although there is a risk of collisions, such that two users might be given the same name, albeit quite unlikely.) User:JeffUK/VerboseTemporaryAccounts.js - WikipediaJeffUK09:41, 11 November 2025 (UTC)[reply]
Yeah, I came back after a break to do a little recent changes patrolling and honestly thought someone had set a few thousands bots on us....!. There needs to be a 'Temporary User' notification somewhere on the Temp user pages, Contribution pages, and Talk pages, to make it abundantly clear that this is a temporary user User contributions for ~2025-32507-53 - Wikipedia, and that this is not. User contributions for -2025-40404-6O - Wikipedia. It should also be clear from the signature that the IP user is a temporary account, or I can easily see people getting very confused about who they're talking to, a load of temporary users with nearly identical names commenting on an article, for instance, is going to be very hard to parse; requiring a user script to be manually installed to patch this is not acceptable, this will confuse new (and returning, source:me) users who won't know they need to do that.. JeffUK10:39, 10 November 2025 (UTC)[reply]
Before temporary accounts were introduced, most IP blocks used to be anon. only, which means they don't affect registered users operating under that IP/range. However, if a temporary account gets blocked, it'll autoblock any registered user using the same IPs for 24 hours (unless the admin unchecks autoblock, which most aren't right now). I'm not sure if this'll cause significant problems, but I'm putting it out here so people can be aware. ChildrenWillListen (🐄 talk, 🫘 contribs) 04:44, 5 November 2025 (UTC)[reply]
The Special:ActiveUsers count (NUMBEROFACTIVEUSERS) which appears on the Main Page has sharply jumped in the last few days, from around 115 thousand on November 3 to 140 thousand on November 7, because temporary accounts are now included, but IP addresses have not been listed. This number will probably fluctuate a lot in the future, because of how easy it is to create a new temporary account, so it could be more consistent with the magic word's previous behaviour to exclude them from the count. Xeroctic (talk) 08:35, 7 November 2025 (UTC)[reply]
For IP users it's quick and easy to tell that you're looking at an IP user, for temporary accounts they're indistinguishable from a normal account, unless you happen to know that a ~2 in the name means temporary. Requiring this special knowledge is a developer hack not a robust user-friendly solution. We need "Temporary User" in big letters on the Temporary Users' User Page, Talk Page, Contributions, and default signature, for this to even be remotely workable. JeffUK10:44, 10 November 2025 (UTC)[reply]
@NKohli (WMF): I know some people hate temporary accounts and the rollout has had some hiccups (which isn't surprising for such a huge technical change), but personally I think this is a change for the better, both from a privacy and legal compliance perspective. Despite the roll-out bugs, I think this feature could easily have been a total disaster if the Trust & Safety Product Team had not spent the past six years carefully planning its implementation, along with all the supporting tools that were needed for mitigating its impact. This is probably the biggest technical change to Wikipedia in the past decade and despite some predictions otherwise, the sky is not yet falling. So I would like to say thank you to the Trust & Safety Product Team for your hard work and collaboration with the community to roll out this monumental change. That is all. Nosferattus (talk) 08:10, 12 November 2025 (UTC)[reply]
Would you prefer banning IP edits instead of introducing temporary accounts?
The discussion above about temporary accounts is quite heated. It's clear that there is some opposition, but I'd like to know if it's a majority of editors or just a couple of loud critics. I don't think it will change anything, as WMF never asked our opinion and made it clear that it will introduce temporary accounts regardless of what we say, but I think it is important to register what our opinion is. Furthermore, I think both alternatives are undesirable, but the legal situation forces us to choose one of these paths, so I'm asking a simple yes/no question to focus the debate and facilitate counting. Tercer (talk) 08:57, 8 October 2025 (UTC)[reply]
How will asking the same question in the same forum, read by the same audience, enable you to determine whether it is "a majority of editors or just a couple of loud critics"? --Elmidae (talk · contribs) 09:49, 8 October 2025 (UTC)[reply]
The question hasn't been explicitly asked before. We have lots of back and forth above, about several different subjects. And yes, I'm interested in the opinion of the editors that participate in this forum, who haven't expressed it clearly or didn't participate in the above discussion (that includes you). If you want to advertise this topic in other forums to get a wider participation that would be great. Tercer (talk) 10:06, 8 October 2025 (UTC)[reply]
Like Elmidae, I have not contributed to the "Temporary accounts rollout" thread and do not plan to. WP:PETITION disfavors such yes/no questions "since they not only encourage the community to avoid meaningful discourse and engagement, but also limit their scope to only one initially-stated opinion or preference with little or no opportunity for discussing and reconciling competing or opposing points of view." Even if you had 60% of a whopping 1000 respondents to vote for banning IP edits rather than introducing temporary accounts, that would be insufficient for our consensus-based model. ViridianPenguin🐧 (💬) 17:09, 8 October 2025 (UTC)[reply]
What is definitely insufficient for our consensus-based model is WMF's imposition of temporary accounts without asking for our opinion or giving us any alternatives.
A cornerstone of our consensus-based model are WP:RfCs, which do involve asking editors what their opinion is. Perhaps I should have started one straight away instead of trying to gather opinions informally. Then at least I wouldn't have had two responses that are only talking about format instead of the subject matter. Tercer (talk) 17:38, 8 October 2025 (UTC)[reply]
I think we're asking this question too early. I think we should let temporary accounts roll out, then if it goes poorly, someone will likely propose an RFC to ban logged out editing at that time. However, WMF has rolled out temporary accounts to most other wikis now, and those wikis haven't imploded. I think that is good evidence that temporary accounts won't create a vandalism catastrophe, and that we can continue to permit logged out editing. –Novem Linguae (talk) 00:47, 9 October 2025 (UTC)[reply]
As a matter of fact I believe that editors should make the decisions about Wikipedia, not WMF. It is not too early, it is too late, because the decision has been made without our input and will be implemented regardless. As for the other wikis, we have seen feedback only from a single editor from a single wiki, and it was very negative. That's not good evidence, but it is evidence of the opposite of what you claim. Tercer (talk) 09:19, 9 October 2025 (UTC)[reply]
Reacting once an implosion has occured is too late. How is a community going to recover from said implosion anyway?
In phab:T364073 the Lithuanian Wikipedia disabled Content Translate because it had so many edits that the admins could not keep up.
Writing that, temporary accounts are not that bad. If an temporary account vandal ip hops without invalidating the account one ban is enough, while one ban per ip, or an rangeblock (if the ip's are close enough together without collateral damage) would be needed now. Tempoarary account vandals become hard when they invalidate their accounts. I checked the Norwegian Wikipedia in June/July and compared ip's in months of last year compared to temporary accounts in the same month of this year. I found out the ratio hovers around 1:1, with occasional spikes to 2 temp accounts per ip. That spike is normal to me, because temp accounts only exist for 90 days maximum. For an IP hopping, temporary account invalidator, there is always IP auto-reveal mode which shows for admins IP's in recent changes as they are shown now for a limited time. Snævar (talk) 13:58, 9 October 2025 (UTC)[reply]
Please stop talking about banning IP edits until the new system has had a six months trial. People have tried banning IPs in the past and it gets quickly shot down. Repeating the half-baked proposal is counterproductive because it biases people such that they reflexively vote no next time, rather than examine the issue yet again. Johnuniq (talk) 00:56, 9 October 2025 (UTC)[reply]
What about "Please stop talking about introducing temporary accounts until we do a six months trial of banning IP edits"? Unlike temporary accounts, that would be very easy to implement, and very easy to reverse, so we could actually have a trial. You know very well that temporary accounts is not a trial, it will not be revisited after six months.
And frankly, there's nothing "half-baked" about banning IP edits. It's technically simple, and has been done already. What else do you need to consider it fully baked? Tercer (talk) 09:23, 9 October 2025 (UTC)[reply]
All discussion prior to implementation will be entirely overshadowed by what actually happens when they're implemented. Either they will work out ok or they will make it to difficult to counter disruptive editing and will have to be limited somehow. Realistically I don't believe there is enough evidence to say for certain what will happen, but given the feedback I've seen from the WMF and the experience of other smaller Wikis I think it should be ok. -- LCU ActivelyDisinterested«@» °∆t°19:52, 9 October 2025 (UTC)[reply]
I don't think the impact will be large, but I'm certain it will be unambiguously negative. And I think that when Wikipedia is under attack from very powerful people, including the US government, WMF should be making the life of malicious actors harder, not easier. Tercer (talk) 19:50, 10 October 2025 (UTC)[reply]
While I’m not a fan of temporary accounts for LTA/sock-tracking purposes (IP geolocation is a cornerstone of linking accts to sockmasters), banning IP edits altogether would be a horrible idea - for every two-bit vandal, there’s a productive contributor that just didn’t want to or hasn’t decided to create an account yet. Hell, half of the recent USHL season pages have been maintained by an IP who’s filling a valuable gap in WP:NHL. TheKip(contribs)02:13, 11 October 2025 (UTC)[reply]
Yes, I am in favor of banning IP edits and temporary accounts. All editors should be required to create an account connected to a verified email address or phone number. Anyone can still edit and vandalism practically ceases to exist. 216.126.35.228 (talk) 17:14, 14 October 2025 (UTC)[reply]
This just defeats the whole point of all Wikimedia projects, in which anyone else can edit. If votes were allowed here, I would be strongly opposed to banning all unregistered edits, and strongly support the introduction of temporary accounts. Codename Noreste (discuss • contribs) 22:26, 14 October 2025 (UTC)[reply]
Let's see how the "temporary accounts" bit works out, first, once the dust settles. If it works okay and there's not a major increase in vandalism and abuse, then the temporary accounts thing is still not good, and it would've been better to keep IPs, but if it's not causing massive headaches, then it is what it is. If it is causing major headaches and we do see a noticeable spike in vandalism, socking, LTA activity, etc., then we'll have to decide on next steps at that point, which may involve restricting or disabling anonymous editing. But let's wait until we actually have the data, rather than just speculation. SeraphimbladeTalk to me22:58, 14 October 2025 (UTC)[reply]
Even if 99% of Wikipedia editors support disabling IP/temporary account editing, I believe the WMF will still have the final say on whether to implement this change (and I believe they've stated before that they will not get rid of IP/temporary account editing). Some1 (talk) 23:03, 14 October 2025 (UTC)[reply]
Some statistics [14] which might be helpful evaluating TA rollout on enwiki. I've checked those stats for my home wiki after TA deployment and everything seemed fine. Johannnes89 (talk) 21:36, 4 November 2025 (UTC)[reply]
Strongest possible oppose to either, frankly. I would not be here if it were not for IP editing, and I know many of our greatest editors started out as IP addresses. I think this whole temporary account thing is dumb, but that is outside the scope of this. We've been doing this for over 20 years and it's worked fine. That's all. Lynch4416:52, 2 November 2025 (UTC)[reply]
Not opposed to the idea, but I currently don't support it at the moment. If I had responded last week, I might have been more supportive to banning IP edits over the temporary account program, but Sohom posted a research article in the discussion above that does indicate with evidence that there are costs to prohibiting non-registered edits, so I do have concerns. --Super Goku V (talk) 15:09, 3 November 2025 (UTC)[reply]
I think this would be a bad idea, anonymous users are , on the whole, a net positive, and adding friction to the "Spot issue with article > Fix issue with article" process is going to reduce the quality of articles on the whole. I would not like "Spot issue with the article > Try to edit it > Get told you have to register > Lose interest" I would much rather see a more integrated, proactive solution to getting people registered, something like, the 'submit' page for any anonymous edit giving you a 'Now select a username and password' page, with a prominent 'skip' option. ("Spot issue with the article > edit it > register or not.") If having something like that in place, we find that the number of temporary users reduces significantly (with an equivalent increase in registrations), then we can review. This is how a lot of e-commerce sites do it, as they too are motivated to get the value (fixing pages/buying stuff) without adding friction, but also would like you to register if you don't mind thank you very much. JeffUK11:38, 10 November 2025 (UTC)[reply]
I’m writing because when I became an admin, and later an arbitrator, it was my intent to do everything possible to protect the community that I belong to and love. I work for that community, not for the WMF. Also, when I ran for the committee I committed to providing transparency whenever possible. The recent incident at WCNA 2025 has pushed me into breaking the ANPDP in order to make sure the community that I serve is safe, and has all the information they need to make informed decisions about their continued safety.
On February 20th, I blocked Gapazoid, who is Connor Weston, the person who brandished a firearm and threatened suicide at the conference. Any oversighter can look at their user page, which I suppress deleted at the time, to verify this. The Arbitration Committee is also aware of his name as he appealed my block to the committee via email. I blocked them for child protection/pedophilia advocacy. I also immediately emailed WMF Trust and Safety, seeking and expecting a WMF ban. The following day Risker pulled talk page access due to continued disruption. They were already blocked on Wiktionary for the same reason.
For the next several months I pressed with every tool at my disposal for a WMF ban. This included discussion on several Arbitration Committee calls with the foundation. My fellow arbs joined me in pushing for this ban. It was such a sticking point between the committee and the foundation that the WMF held a “Process sync” call on June 24th for us to explain how T&S makes decisions about WMF bans.
During this process, on April 25th, Weston sent an email to the info queue saying they were going to travel to the WMF offices to protest my block. The message states, in full:
<information redacted>
This email was forwarded to T&S who verified receipt. I am also aware that information regarding Weston threatening suicide was sent to T&S.
On August 11th they closed the case, along with a second child protection case, with no action. To quote the email sent to me personally in response to my initial report:
Having carefully weighed the evidence, we found no indication that Gapazoid’s contributions amount to advocacy or encouragement of illicit activity.
In their response to the Committee they said:
We recognize that taking no action in these cases may not fully align with what ArbCom expects or hopes the WMF's role to be in situations of child safety concerns, particularly given the importance and sensitivity of child safety matters on the platform and the fact that you, ArbCom, have been trusting the Foundation for years to handle these matters. The fact is, however, that while the community can sanction based solely on its own judgement, the Foundation must be able to legally defend our decisions to take action, including their consistency with our policies over time. This includes the need to have evidence of a risk of harm that violates our policies. We don’t think that either of the above two examples would be successful in meeting that standard.
This decision allowed a suicidal pedophile who threatened to travel in-person to WMF headquarters to protest a block to gain access to an in-person meeting of our community. Even if they didn’t plan on using a gun to end their life in front of all of us, this would still be unacceptable.
In the weeks and months leading up to the convention the committee and other members of the community brought up concerns about event security, and were assured that appropriate security measures would be taken. At the event there was essentially no security. No bag checks and no checks with a metal detector or wand. After the incident there was an increased presence of security personnel and bag screenings, but no additional searching or screening of carried belongings.
Every member of the community deserves, and absolutely must be given, the ability to make informed decisions about their safety within the community. The WMF is responsible for taking every reasonable action to keep our community safe. In this case, they made the unreasonable decision of not banning a suicidal pedophile who had made clear their intent to protest a community block in person, and in doing so explicitly allowed the incident at WCNA to occur. The foundation’s actions put everyone attending the conference in life-threatening danger. Thankfully, due to members of our community, the worst case was avoided, but this was in spite of the WMF’s decisions and actions.
From a personal perspective, before I left to attend the conference my wife expressed concern for my safety. She’s aware of the anti-abuse work I do, and the threats of harm and death that come along with that. I told her, based on the WMF’s assurances, that it was safe for me to attend, they planned on having enhanced security, and she didn’t have a need to worry. Days later I would be sending her messages after evacuating the conference due to a suicidal man that I’d blocked from Wikipedia months earlier charging the stage with a gun. As soon as he began speaking, I recognized with horror who it was. I immediately informed WMF employees on-site. I was not informed that Weston would be attending, and either T&S didn’t screen the attendees or screened the list and let this pass. Either situation is completely unacceptable.
Thankfully, no one was physically hurt. Due to heroism by members of our own community, the threat was mitigated, but that doesn’t mitigate the trauma we all suffered. It is essential that nothing like this ever happen again, and because of that the community must be aware of the extent of the failures that occurred. The community did everything right in this situation, from blocking a pedophile, reporting it to T&S, forwarding the suicide threats and intention to protest in person, and pushing in every conceivable way for a WMF ban, and due to systemic failures from the WMF we were almost all party to an incredible tragedy.
Global trends: We are seeing 8% declines in human page views on Wikipedia as some users don't directly visit Wikipedia to get information. Learn about this new user trend, how the Wikimedia Foundation anticipate these changes, and how you can help.
The naming contest for the new Wikimedia project, known until now as Abstract Wikipedia, is ongoing.
Making it easier to say thanks: Users on most wikis will now have the ability to thank a comment directly from the talk page it appears on. Before this change, thanking could only be done by visiting the revision history of the talk page.
Account security: Improvements to account security and two-factor authentication (2FA) features were enabled across all wikis. Another part of the project is making 2FA generally available to all users. Along with editors with advanced privileges, such as administrators and bureaucrats, 40% of editors now have access to 2FA. You can check if you have access at Special:AccountSecurity.
Tech News: Read updates from Tech News week 42 and 43 including the community-submitted tasks that were resolved last week.
Wikimedia apps: The Wikipedia iOS App launched an A/B/C test of improvements to the Tabbed browsing feature into Beta for select regions & languages. Called “More dynamic tabs”, the experiment adds user-requested improvements and introduces article recommendations within the tabs overview, showing “Did you know” or “Because you read” content depending on how many tabs are open.
CampaignEvents extension:Campaignevents extension will be deployed to all remaining wikis during the week of 17 November 2025. The extension currently includes three features: Event Registration, Collaboration List, and Invitation List. For this rollout, Invitation List will not be enabled on Wikifunctions and MediaWiki unless requested by those communities.
Event registration tool: Autoconfirmed users on small and medium wikis with the extension can now use Event Registration without the Event Organizer right. This feature lets organizers enable registration, manage participants, and lets users register with one click instead of signing event pages.
Digital safety: Explore how you can help make Wikimedia safer by taking our new self-paced course, Safety for Young Wikimedians.
Wikimedia Core Curriculum: The Wikimedia Foundation has developed seven online video learning modules covering the core English Wikipedia policies. You are invited to use, adapt, and translate the course.
Advocacy: The Wikimedia Foundation has signed onto a statement that calls on governments and UN bodies to keep discussions about the future of internet governance accessible to non-government actors like industry and civil society. This statement is part of ongoing joint advocacy with affiliates to influence UN discussions about the future of internet governance such as the Global Digital Compact campaign and WSIS+20 deliberations.
GLAM: The Wikimedia Foundation and several affiliates have signed onto the Open Heritage Statement, which supports galleries, libraries, archives, and museums (GLAM institutions) to have the legal rights they need to collect, preserve, and provide access to cultural heritage.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
wikimedia.org for advice.
.jpg)
Enable the user info card
Resolved
wikimedia.org know if you have any feedback or suggestions for improvement!