Talk:Trust and Safety Product/Temporary Accounts

Overview

Updates

Legal

FAQ

• Leave a comment in your preferred language.
• This page is used by people from a number of communities. Please avoid using acronyms from your home wiki. That will help others participate in the discussion.

Memorable names for temporary accounts

Moving from raw IPs to automatically assigned names will make it possible to grant memorable names, too. A name made up of two words and a year would be ideal for me as a page-history watcher.

Google Docs assigns pseudonyms to anonymous commenters in a similar way and it's great. Following Google's approach would mean usernames like "Avid banana 2024", effective at nudging new editors into selecting a name of their own, but perhaps a bit too silly for an encyclopedia.

To encourage serious editing from these accounts, Wikipedia could generate more-serious names, such as "Aristotle's chinchilla 2024" or "Harold Sowell 2024 (pseudonym)".

Reserving usernames that end in a four-digit year or "(pseudonym)" shouldn't be a problem, right? Jruderman (talk) 17:20, 20 August 2024 (UTC)

I don't like it. It could cause issues with CC-BY-SA 4.0, which states that

If You Share the Licensed Material (including in modified form), You must:

retain the following if it is supplied by the Licensor with the Licensed Material:

identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);

So if the contributor 'supplies' a name or pseudonym, then you have to attribute the contributor. On the other hand, if no name or pseudonym is supplied, then no attribution has to be given.

If a random pseudonym is chosen by the software, then all becomes unclear: has the contributor supplied a pseudonym or not? If the pseudonym was supplied, then it must be used for attribution, but if it wasn't supplied by the contributor (but by software which did this without the contributor's knowledge) then attributing the pseudonym could mean giving incorrect attribution, which I suspect would be a problem.

If no random pseudonym is chosen, then it seems unambiguous that no pseudonym was supplied and so we avoid the problem. --Stefan2 (talk) 17:45, 20 August 2024 (UTC)

Interesting. I hadn't considered attribution.

Does the license explicitly allow not attributing contributors who are known only by IP address?

Mid-seriousness names are probably ideal when attribution requirements are taking into account.

Perhaps having a generated pseudonym should be opt-in at the time of publishing the first edit, with a choice of three generated names and one mostly-numeric name. Jruderman (talk) 18:02, 20 August 2024 (UTC)

Temporary account is not the same as a registered account and the main purpose is to hide the IP address. If users want to choose a more serious username, they can create a registered account. SCP-2000 (talk) 18:08, 20 August 2024 (UTC)

My proposal is more for the benefit of people watching page histories and countering abuse, rather than for the benefit of everyone who edits without creating an account first. Jruderman (talk) 18:11, 20 August 2024 (UTC)

@Jruderman the idea did cross our mind when we were discussing temporary usernames.

One other challenge (besides what's mentioned above) is translation. IP addresses are currently well understood from the format itself. If we choose to go with something like "Aristotle's chinchilla 2024" it would need to be translated to be legible for other projects (since temporary accounts are global). This is quite difficult to do. So we decided to keep using numbers as they are already used for IPs. NKohli (WMF) (talk) 14:42, 21 August 2024 (UTC)

Could use automatic memorable names on some language wikis and the numeric fallbacks on others. Jruderman (talk) 17:27, 21 August 2024 (UTC)

As the username of temporary account is the same and unique across different wikis, it is difficult to use a different username on some wikis. SCP-2000 (talk) 01:26, 22 August 2024 (UTC)

Is it common for users to be active on different language wikis (not just one language wiki and the metas)? Jruderman (talk) 03:13, 22 August 2024 (UTC)

I think there are only a few newcomers who would be active on different wikis. However, as it goes against the current system work, it is unlikely to be possible from a technical perspective. SCP-2000 (talk) 04:00, 22 August 2024 (UTC)

It's probably okay for the first wiki they edit to determine their naming scheme. Jruderman (talk) 04:04, 22 August 2024 (UTC)

@NKohli (WMF) there is a much easier to translate naming scheme that is also more human-friendly, which is to call it "Anonymous Editor 1234567-2024". The use of the tilde prefix and then just raw year + numerals is super confusing and not obvious at all what it is. If you go with that name it is going to make sense basically only to software engineers and no one else. It's likely that we even already have translations for the words "anonymous" and "editor" floating around from UI l10n so that shouldn't be hard. Steven Walling (talk) 23:07, 21 October 2024 (UTC)

Please fix the account naming before rolling this out

I posted this above and got no response so I am posting again. The naming scheme for temporary accounts is extremely unfriendly to non-technical users and needs to be reconsidered. No normal person is going to know what ~2024-1234567 means. IP addresses are also highly technical but at least they have a point of reference outside of Wikimedia. For the love of god please add some kind of prefix like “Anonymous Editor ~2024-1234567“. Steven Walling (talk) 02:36, 3 December 2024 (UTC)

It doesn't look like this Talk page is really monitored by WMF which is odd considering the mass message pointed to it as a place to leave feedback. Liz (talk) 00:19, 4 December 2024 (UTC)

Hey @Steven, thanks for your comment. I will share with the team that you've brought this up. Just to be clear, changing the username format seems unlikely. I don't know the full story, because when I joined, many rudimentary decisions had already been made, so let me just share what I know.

We did user tests (see the results here) and decided to change the format from the initially designed *YYYY-n to ~YYYY-n, even though lexical prefixes were also considered and tested. According to T345251, it is or at least was possible to add a lexical prefix.

It's been a month since we deployed on the first pilots. So far, the members of these communities haven't been asking for this and (afaik) haven't noticed temp users asking for this. We are monitoring the metrics, I don't know of any drops in logged-out activity, which would indicate that the temp account experience may be confusing. This part, about the temporary account experience not being pure future, sounds particularly important, would you agree?

Anyway, stay tuned. I will update you on this. Thanks! SGrabarczuk (WMF) (talk) 02:11, 4 December 2024 (UTC)

@SGrabarczuk (WMF) If you look a few posts up: Suggestion on minor change in temporary name system I have suggested using ~YYYY-MM-n or maybe even ~YYYY-MM-DD-n.

On nowiki, where I am sysop and this feature has been active for a month or so, we saw five digit usernames just after a couple of days. Imagine what n is equal to towards the end of the year when it has been rolled out to all wikis and in use for a full year. I know for a fact that the same temp user already have used several n, even though it was meant to be a user name lasting 90 days. It’s quite easy to renew the number by deleting cookies, or get a new number each time one opens the browser by using Incognito mode in the browser. 1000mm (talk) 20:03, 5 December 2024 (UTC)

Okay, I have an update. Lexical prefixes were indeed considered, but the team found a challenge. There is no good way to make these prefixes play nicely with the global nature of temp accounts. Any solution would be at least confusing, and prefix localization would also be technically difficult to build. SGrabarczuk (WMF) (talk) 23:06, 6 December 2024 (UTC)

If we can localize every other UI string in MediaWiki we can localize a displayed temporary account name. (The stored temporary account ID and the display name don’t need to be exactly the same. That’s why we invented hashes.)

The reason why you haven’t heard feedback about usability is that the people who would find a random number set with a tilde confusing also don’t write on Talk pages. Where is the published result of usability testing that shows normal people know what a temporary account is? Steven Walling (talk) 03:58, 10 December 2024 (UTC)

@Steven, just like you, I'm not a newbie :D I'm not relying on hearing just on talk pages. I can ask for details and the Phab task, but clearly, it wasn't as easy as localizing every other UI srting in MediaWiki. SGrabarczuk (WMF) (talk) 13:31, 10 December 2024 (UTC)

When will this feature be available in all beta cluster wikis?

Some wiki such as the beta cluster wiki of Chinese Wikipedia, still have no temporary accounts (as you can see here). I would like to know when this feature will be deployed on all beta cluster wikis, as it allows testing with local settings. 132.234.228.201 08:17, 18 September 2024 (UTC)

I'm sorry for the delay on this. This is now resolved. Temporary accounts should now be available on all beta cluster projects except for en-rtl wiki. Please test them at your convenience. Looking forward to your feedback. NKohli (WMF) (talk) 14:56, 21 October 2024 (UTC)

@NKohli (WMF): I found that the meta wiki of the beta cluster still cannot create temporary account (as you can see here). I made this edit after when a temporary account (~2024-25308) was created from another wiki, which the temporary account can auto-create in other wikis. 132.234.228.116 02:06, 30 October 2024 (UTC)

You are right. I can reproduce this issue. I will file a task for engineering to fix this. In the meantime you could try out the feature on another wiki. Happy to hear any feedback you may have. Thank you. -- NKohli (WMF) (talk) 18:54, 5 November 2024 (UTC)

Abuse filters II

I wanted to see how abuse filters will work with temporary accounts, but the value for user_unnamed_ip is null (testwiki:Special:AbuseFilter/examine/863786), and ip_in_range returns false when I examine the edit. I also can't seem to find where to check a temporary user's IP address. Is that enabled on testwiki? For all sysops? pon_or (talk) 05:04, 24 October 2024 (UTC)

OK, there are some user preferences that need to be turned on. But even with "revealing IP addresses for temporary accounts in AbuseFilter" enabled, user_unnamed_ip is null (under /examine at least).pon_or (talk) 06:13, 24 October 2024 (UTC)

This is now task T378084. pon_or (talk) 13:27, 24 October 2024 (UTC)

Maybe change the tilde and the minus

OK, I know I'm probably super-late to this party, but I have to try anyway.

Is there still a chance to change the tilde to a Latin letter, for example U, and to remove the minus in the middle?

Here's why I'm suggesting it. According to the current FAQ, temporary usernames will look like ~2024-1234567. In right-to-left (RTL) wikis, the tilde will usually appear to the right of the numbers, and the minus may make the year appear to the right of the seven digits (depending on the language). If the temporary username is ~2024-1234567, it will appear in RTL languages like this:

• Arabic: المستخدم ~2024-1234567 قام بفعل
• Divehi: މެމްބަރު ~2024-1234567 ކޮށްފައިވާ ކޮންމެވެސް
• Hebrew: החשבון ~2024-1234567 עשה פעולה
• N'Ko: ߟߊ߬ߓߊ߰ߙߊ߬ߟߊ ~2024-1234567 ߞߍ߫

My apologies to Arabic, Divehi, and N'Ko speakers who read this. I used existing translations on translatewiki to generate the text. I know only a little Arabic, and I don't know Divehi and N'Ko at all. However, I'm pretty sure that the general right-to-left structure of the sentence is mostly correct and makes the correct point about appearance. If you know these languages, feel free to change what I wrote.

Note that the tilde appears on the right side of the username in all the examples, and the 2024 appears on the right in Arabic and Divehi, but on the left, as in English, in Hebrew and N'Ko. There are technical reasons for these differences, and we may deep-dive into them, but I don't think that it's necessary.

And this is not only a matter of visual appearance. I expect the temporary usernames to be copied and pasted very frequently, for example when administrators and patrolers report vandals who use temporary accounts. Try highlighting the temporary usernames in the examples above for copying and pasting using your mouse, keyboard, or touchscreen. It's not fun.

I tried to think of a character that would match the following criteria:

• Appears on US-English QWERTY keyboard.
• Appears on as many other common keyboard layouts in the world. (Fun fact: The tilde doesn't quite match this criterion! It doesn't appear on common Russian keyboards, for example, and I'm not also not sure about common Arabic keyboards.)
• Is not a letter.
• Is not a problematic character for wiki page titles (e.g. # _ | [ {).
• Will always appear on the same side of numbers in all writing systems.

I couldn't find any character that matches all these criteria.

If we remove the "Is not a letter" criterion, however, we can just use a Latin letter. Yes, it's kind of not-so-universal, but if Q, P, L, and M are good enough for Wikibase entity ids, and Z is good enough for Wikifunctions ids, then why wouldn't U be good enough for temporary user ids? Latin letters can be fairly easily typed on all devices, perhaps even more easily than a tilde.

As for the minus, it can be completely removed, or replaced with a full stop.

Here's the result with a full stop for separating the year (U2024.1234567):

• Arabic: المستخدم U2024.1234567 قام بفعل
• Divehi: މެމްބަރު U2024.1234567 ކޮށްފައިވާ ކޮންމެވެސް
• Hebrew: החשבון U2024.1234567 עשה פעולה
• N'Ko: ߟߊ߬ߓߊ߰ߙߊ߬ߟߊ U2024.1234567 ߞߍ߫

And here's the result with a no separation of the year at all (U20241234567):

• Arabic: المستخدم U20241234567 قام بفعل
• Divehi: މެމްބަރު U20241234567 ކޮށްފައިވާ ކޮންމެވެސް
• Hebrew: החשבון U20241234567 עשה פעולה
• N'Ko: ߟߊ߬ߓߊ߰ߙߊ߬ߟߊ U20241234567 ߞߍ߫

Not separating the year has another advantage, which applies to all languages and not only the RTL ones: the username can be easily highlighted for copying on the desktop by double-clicking and on Android (and maybe iOS) by long-tapping. So I would actually prefer this for this reason, but perhaps some people will find it too number-heavy.

If we don't replace the tilde, we'll have usernames that will always look different on different sites. It happens with some usernames already now, but if we go the tilde and minus way, it will happen to all the temporary usernames. If administrators want to collaborate on hunting vandals across languages, this will make it harder.

So... am I too late to bring this up? Or can we still consider changing it? Amir E. Aharoni {{🌎🌍🌏}} 14:15, 25 October 2024 (UTC)

What are they thinking?

I don’t think the foundation of this whole thing is sound, but I guess that’s fine because the entire tech community seems to be ignoring reality and pushing their idea of reality down our throats.

I wonder if anyone responsible to creating this has ever heard of private windows. Some browsers are even perpetually in private mode (and I’m talking about phone browsers) and the cookie will last only maybe a couple of hours. I browse on a computer but I’m perpetually in private mode so my cookies will only last until the next browser crash (usually between 2 days and maybe a week).

So what will happen if a significant number of users are using phones with private-mode-only browsers?

(I know IP-based blocking is on an even weaker foundation. Maybe this is a slight improvement but still.) — Alıƨsi (talk) 21:05, 28 October 2024 (UTC)

@Al12si: Hello, you can read this FAQ "Can't an abuser just clear cookies?" to know more about it.

@SGrabarczuk (WMF) and NKohli (WMF): Furthermore, as the FAQ mentions a few measures, such as using fingerprinting and trusted tokens, I am curious if there are any future plans to mitigate the problem of users repeatedly clearing cookies? Thank you. SCP-2000 (talk) 06:02, 29 October 2024 (UTC)

Thank you. But I’m not talking about clearing cookies. I’m talking about private windows (a very old feature in mainstream browsers) and the reality of an entire class of new browsers that do not have permanent cookies at all. On a phone, when memory is tight, cookies can disappear in as little as, like, 5 minutes, without the user even wanting to clear cookies.

Sorry, I don’t really know why I wrote my comment, but if the FAQ is written like this, it’s out of date thinking. Private windows have existed since — I don’t know — some 20 years ago? Sorry for the noise.

PS: I did say this is probably a slight improvement over IP-based, which is on even shakier ground. These days most IP addresses are dynamic, and even tech giants can’t tell dynamic from static IP’s because today’s static IP’s are just random holes in a block of dynamic addresses, they don’t even follow CIDR rules. IP blocks were unjustifiable even based on the reality of some 10 years ago so, again, I guess this is an improvement. Alıƨsi (talk) 06:20, 29 October 2024 (UTC)

PPS: Geolocated city location will be unreliable. For one data point, my geolocated city is often wrong , sometimes in the wrong province. In a previous job our office’s IP (or rather, several IP’s in what was theoretically a tiny CIDR block) was consistently geolocated to the wrong country. Alıƨsi (talk) 06:53, 29 October 2024 (UTC)

Private browsing is effectively automatically clearing cookies, maybe with some other stuff that wouldn't impact this. Aaron Liu (talk) 12:50, 14 November 2024 (UTC)

@SCP-2000 @Al12si There are some future plans around fingerprinting (we are calling it account reputation). We'll share more about this in a future update. There is also throttling after 6 accounts have been created from an IP - similar to what exists for registered accounts. -- NKohli (WMF) (talk) 15:11, 4 November 2024 (UTC)

Sorry for the noise again, but I have to make it clear that this is why I said IP-based has an even weaker foundation. Same IP doesn’t really mean anything — not since more than 10 years ago. In the previous job I mentioned, an entire complex shares one IP address (the rest of the CIDR block was for servers) and it was a community centre, so if they held a Wikipedia editathon (not unimaginable especially given the target communities they serve) or similar this means the entire community centre would be throttled? Do you guys even have use cases we can see? This should be considered the norm since we’re literally officially out of IPv4 addresses already.

Also, fingerprinting is itself a privacy concern and the W3C itself has plans to make at least one form of fingerprinting harder (i.e., in the “future” doing this might become increasingly hard). If the FAQ isn’t addressing at least these two points (and talk about private windows instead of “clearing cookies”, and address the RTL issue Amir brought up above — my L1 used to be RTL too) it’s very hard to convince people this thing has been thought through.

(To be fair, I understand tech giants are ignoring these problems, but this just puts WMF on the same low standard as them. Again, sorry for the noise.) Alıƨsi (talk) 19:01, 4 November 2024 (UTC)

@NKohli (WMF) : If someone edits without accepting cookies and their IP address has already reached the limit of six temporary accounts in the last 24 hours, will they still be able to edit Wikipedia? In this scenario, what exactly happens? Will editing be blocked, or is there another mechanism in place? LD (talk) 13:22, 15 November 2024 (UTC)

Hi @NKohli (WMF) / @SGrabarczuk (WMF), I would be glad if you could answer the above question of LD, as I do a short presentation of temp accounts this Saturday for fr-wp patrollers. Best, Jules* (talk) 18:39, 28 November 2024 (UTC)

@LD That person (and anyone else editing from that IP address) would need to create an account after hitting the rate limit. There is a proposal in task T357802 to make this more obvious. KHarlan (WMF) (talk) 08:14, 29 November 2024 (UTC)

Existing IP blocks, especially range blocks

hi, when this comes in, what happens to existing IP blocks especially range blocks. Do they all get reset? WereSpielChequers (talk) 13:20, 31 October 2024 (UTC)

Hey @WereSpielChequers, thanks for the questions! The IP blocks don't get reset and continue to be in force. From this perspective, the deployment of temporary accounts is just an introduction of a new level on top of IPs, and not a replacement. SGrabarczuk (WMF) (talk) 13:40, 31 October 2024 (UTC)

OK thanks, I suspect it is going to be harder for non admins to realize that a particular group of abusive temporary accounts could all be taken out with one range block. But I don't know how many non admins know about range blocks anyway. WereSpielChequers (talk) 13:55, 31 October 2024 (UTC)

Renaming accounts

Will someone with a temporary account be able to get it renamed and turned into a normal account? WereSpielChequers (talk) 13:20, 31 October 2024 (UTC)

Nope, neither of this will be possible. Currently, this is documented on Help:Temporary accounts. SGrabarczuk (WMF) (talk) 13:39, 31 October 2024 (UTC)

Does this mean it is out of scope for this phase, or is there something in the database sign that means this would kill excessive numbers of server kitties? WereSpielChequers (talk) 13:50, 31 October 2024 (UTC)

The latter :D In addition, a temporary account could be used by different people (on shared devices) so legal limitations are also involved. So no, this is out of scope for this project. SGrabarczuk (WMF) (talk) 14:05, 31 October 2024 (UTC)

I get that anyone asking to have their temporary account turned into a permanent one would have to commit that all the edits that account had made had been by them. Though I suppose if the way of doing this was to export/suppress the edits and reimport them under a new account, you could leave some edits behind. My assumption is that creating a path for temporary accounts to become permanent would make it easier to recruit longterm editors from among these temporary accounts. WereSpielChequers (talk) 11:25, 1 November 2024 (UTC)

multi device vandals

I like that this will now be at the device level rather than the IP level. But there are some vandals who have access to multiple devices on the same IP address. Blocking them all is going to be a longer process unless the IP also gets at least temporarily locked when an admin blocks a temporary account. Is this going to increase the amount of abuse received, and if so are we warning vulnerable people about this? WereSpielChequers (talk) 13:20, 31 October 2024 (UTC)

Hm, this is an interesting question, thank you!

I would say, the priority could be to target blocks more precisely and reduce collateral damage done to potential and actual good-faith contributors using the same IP. This is the team's philosophy, and we'll be working on other projects allowing admins to perform precise blocks.

Will this increase the moderation effort, though? Not necessarily, because in addition to the deployments of temporary accounts proper, we are making related, smaller changes aimed at reducing the moderation effort. For example, we had introduced global account blocks, and earlier today, we shipped global autoblocks.

We are monitoring the numbers of blocks and reverts (and more) as metrics of this project, so we will definitely have evidence before we introduce temp accounts on most wikis.

Does this make sense? How does it sound to you? SGrabarczuk (WMF) (talk) 14:03, 31 October 2024 (UTC)

Thanks for your answers. Yes I get that this will greatly reduce collateral damage where two people are using the same IP and both get blocked because one does vandalism. I'm just wondering about the amount of underkill this will cause. WereSpielChequers (talk) 14:43, 31 October 2024 (UTC)

Effect on stats

for those doing research on the project and its community, this is going to change some aspects of the stats. In particular there will be far more temporary accounts than there have been IP editors even if the number of IP edits remains the same. This will partly be because of the three month maximum and partly because where we currently have shared IPs and more than one individual editing from the same IP they will now have different temporary accounts. Would it be possible to have some research into this transition so that researchers have some guidance as to how this effects what they are measuring, and for that to e one more than one project as I suspect the impact on a more IP editor focussed project like JA wiki will be different to EN wiki. WereSpielChequers (talk) 13:46, 31 October 2024 (UTC)

Community criterias for allowing checkuser-temporary-account right

Hello @SGrabarczuk (WMF). There are minimum criterias to view IP addresses used by temporary accounts via checkuser-temporary-account right (6 months old account, etc.). Local communities were encouraged to set additionnal criterias.

On fr-wp, we have a question about that: must the checkuser-temporary-account right be automatically attributed depending on technical criterias? Or is it possible for a community to add a human validation, a manual assignment of the right by bureaucrats or sysops? (In addition to minimum criterias, who always need to be met.)

Best, Jules* (talk) 17:11, 1 November 2024 (UTC)

@Jules* this is undefined at the moment. Very early on we heard from some communities to add manual validation but in subsequent research we didn't hear of it again. If communities want to do this, we will need to implement a mechanism to disable auto-assignment and allow a community to self-assign rights to users.

Is this something that your community would like to do? If yes, what kind of criteria are you thinking? NKohli (WMF) (talk) 15:46, 4 November 2024 (UTC)

Thanks for your reply, @NKohli (WMF). I don't know if this is something that my community would like to do: in fact, I asked the question because this is one of the possibilities we have considered when creating this survey and we wanted to know if this is something that we could propose to the community in the survey, as the community might want to add some human validation (by vote, community consensus, etc., with technical assignment of the right done by sysops or bureaucrats) to existing —or more strict— technical criterias.
In light of your answer, I guess we will add this possibility (manual assignement) to the survey, but we will specify that this feature doesn't exist right know.
Best, Jules* (talk) 18:24, 4 November 2024 (UTC)

Hi again @NKohli (WMF). I see that the previous phrasing "Communities are encouraged to create local requirements. Local requirements must be more restrictive than the general requirements outlined in point three above." on Policy:Access_to_temporary_account_IP_addresses has been removed. Are local communities still encouraged by the WMF to create local requirements? (Imho, the default ones are a bit low for access to personal data such as multiples IP used by a single user, but that's only my opinion.) Best, Jules* (talk) 11:40, 14 November 2024 (UTC)

Hey @Jules*, exactly, because we removed this part from the policy, we aren't encouraging communities to create local requirements. This is how things are now. But soon, we may consult some communities and global groups on how they feel about different options (like whether to have different thresholds, or to disable automatic granting and have it only manual on some wikis, or do nothing). First, we need to make an overview of the upsides and downsides of each scenario. The team will discuss this later this week. SGrabarczuk (WMF) (talk) 15:05, 4 December 2024 (UTC)

Ok, thanks for your reply @SGrabarczuk (WMF). This is a bit confusing for us to be honest, as the 'encouragement' has been published for a long time, and removed without this removal beeing explicitly said (so we didn't see it). Jules* (talk) 14:22, 9 December 2024 (UTC)

Yeah @Jules*, to be honest, I was confused myself when I realized that the policy was changed but the respective part of the FAQ wasn't. This was very odd, and I apologize for that. SGrabarczuk (WMF) (talk) 23:55, 9 December 2024 (UTC)

Greetings. I can't speak for the entire ruwiki community, but I can speak for myself. I believe that such low criteria for access to IP viewing does not provide any privacy, as any member can create an account and get the minimum required, and then view the IP addresses of all temporary accounts. This gives no privacy for anonymous editors. I agree that something needs to be done - either tighten up the requirements, or make it tied to existing rights, such as patroller or someone else. Megitsune-chan (talk) 13:26, 9 December 2024 (UTC)

I do see the same in enwiki. Any thoughts on tying it to rollbacker (if that is there in ruwiki?) @Megitsune-chan Bunnypranav (talk) 13:32, 9 December 2024 (UTC)

A rollbacker is often issued with a patroller rights in ruwiki. Megitsune-chan (talk) 13:44, 9 December 2024 (UTC)

Ah, that is not the case in enwiki, sorry for the confusion Bunnypranav (talk) 13:46, 9 December 2024 (UTC)

But there are times when we issue a rollback right for autopatroller at the request. For example, if user frequently undo vandalism. Megitsune-chan (talk) 13:47, 9 December 2024 (UTC)

Yes, so as the IP will mostly be needed by anti-vandal edit, it makes sense to grant it to rollbackers. Bunnypranav (talk) 13:51, 9 December 2024 (UTC)

That actually sounds logical. I think it would make sense. Megitsune-chan (talk) 13:53, 9 December 2024 (UTC)

Giving the right to rollbackers (révocateurs in french) is one of the options considered (and the one favored by a majority of voters) on fr-wp survey.

I agree with both of you regarding the criteria beeing too low (althought I'm vigilant that criteria don't prevent or complicate vandalism-and-LTA-fighting). Personnaly, I'm OK with all options (tying it to rollbacker; tighting up the requirements; manual attribution of the right by sysops or bubus) but I agree that rollbacker may be the simplest one. Jules* (talk) 14:03, 9 December 2024 (UTC)

Yep. I agree. Megitsune-chan (talk) 14:07, 9 December 2024 (UTC)

Moved from English Wiki Rollout

Is there any consensus or poll regarding who can see the IP addresses of temp accs? Bunnypranav (talk) 15:06, 4 December 2024 (UTC)

Pinging enwiki sysops recently active on this page, who might have an idea on this. @Sohom Datta @Liz. Bunnypranav (talk) 15:18, 4 December 2024 (UTC)

There's the Wikimedia Access to Temporary Account IP Addresses Policy which defines who can see the IP addresses of temp accounts. Currently, our FAQ is a bit outdated in this part, and the most reliable source is this policy.

By the way, we are having a similar conversation about who can see the IP addresses here: #Community criterias for allowing checkuser-temporary-account right. Maybe you'd like to chime in there? Thanks, SGrabarczuk (WMF) (talk) 15:51, 4 December 2024 (UTC)

I see, thanks for your replies! Bunnypranav (talk) 15:51, 4 December 2024 (UTC)

@SGrabarczuk (WMF) is it fine if I start an ideating phase discussion at enwiki village pump for who should have this? Or should I wait for now. Bunnypranav (talk) 12:17, 7 December 2024 (UTC)

Can I ask the same thing for ruwiki? Megitsune-chan (talk) 13:51, 9 December 2024 (UTC)

Hey @Bunnypranav and @Megitsune-chan, I'd like to avoid any unclarities, so let me explain the situation a bit more broadly and step by step. Maybe I'm being Cpt Obvious a bit, but I wanted everyone reading this page to know how the team understands the basic part of the situation. Apologies for not diving into details about specific solutions I mention, though.

Bunnypranav, I'd like you to look at the section Minimum requirements for access. The policy does define who should have access, so you don't need any discussion to have some rules in place.

About Megitsune-chan's "such low criteria for access to IP viewing does not provide any privacy, as any member can create an account and get the minimum required" - currently, everyone has access. Limiting this to some logged-in users already strengthens privacy. To put things in perspective: logged-out users are a tiny fraction of all our traffic 2. according to Template:Registered editors by edit count, on English WP, more than 99% of logged-in users have not made more than 300 edits. On other large wikis, the situation is probably not significantly different, not by orders of magnitude.

In order to actually see IP addresses, a user will need to go to their preferences and agree on the policy's terms. So they need to 1. be active (this rules out some of the <1% of users) and 2. want this right. We will check how many users have actually done this on the current pilot wikis, but it surely is just a part of those who technically meet the criteria.

That said, we totally understand that on the largest wikis 300 edits may be done within an hour if one knows where to fix typos.

If you think the current rules are not the best, and you are interested in changes just for your wikis, the policy does not allow that. It used to ("Communities are encouraged to create local requirements"), but we needed to remove that part earlier this year. We realized that providing different options for different communities would be too complex and challenging to do before the very first pilot deployment.

We also realized that we'd need some investigation and discussion on how these options should be provided technically, what's technically not feasible, and what is the goal, really. Maybe it should be possible to define different thresholds across wikis. But how would that work with permissions of people without global rights tracking cross-wiki abuse? Maybe it should be possible to disable automatic granting and have it only manual on some wikis. And maybe the basic threshold should be increased, in which case local requirements wouldn't be needed. But wouldn't this increase the risk of burnout of those few who would have the permissions?

Last week, the team started to discuss this and consult people from outside the team. We will document our understanding of the possible options, and pros and cons, and then we'll see, maybe we will start a larger discussion with communities, where we would present our understanding of the situation and ask clear, well-phrased questions.

We are not there yet, though. We prefer not to kick off any important community discussions in December, because it's a good practice not to start anything major that shortly before the holiday break. So January at the earliest, if it really needs to be done before major pilot deployments (scheduled for February).

I'm curious if you have any questions. We will keep you updated. Thank you! SGrabarczuk (WMF) (talk) 22:09, 9 December 2024 (UTC)

Thanks for the elaborate response. I personally think it would be better if this was granted to people who asked for it (apart from accepting policy terms). Like bundling it with an existing group, or a separate group altogether. This will probably prevent most abuse and protect privacy. Granting it based on a suffrage basis seems unnecessary.

About the possible burnout, if this is an area that needs patrolling, more people will be willing to apply and help, and the people granting this right will also keep in mind that many can have this right for the various reasons, and accept requests accordingly. Bunnypranav (talk) 12:26, 10 December 2024 (UTC)

Global autoblocks

I saw the next Tech issue and read the global autoblock feature. Will this mean that those autoblocks apply to the underlying ip and therefore the named accounts. I am anticipating a lot of collateral damage as a result of the autoblock and increased requests for global ipbe. ToadetteEdit (talk) 07:24, 2 November 2024 (UTC)

There are already global ip blocks. Autoblocks block the IPs used by the temporary accounts, i.e. those that would already be blocked globally. The only difference is that you do not block the IP directly, but the account and this triggers the ip block. Autoblock = 24 hours. (I assume that they work in exactly the same way as autoblocks for locally blocked accounts.) Therefore, these blocks are not a problem. WikiBayer (talk) 18:02, 2 November 2024 (UTC)

Feedback

I have now made my first experiences. I think it's good that not everyone can see the IP address. However, as an administrator and especially as a global administrator, I am dependent on information from IP addresses. On the one side I need the information to stop vandals, spambots and trolls. On the other hand, I need it to identify trolls more quickly. When I'm posting in languages I don't speak (sometimes without a translator I couldn't even tell if this is the language or a different one) I can't enter every post into a translator because it would take too long, so I use metadata like IP address and origin to filter out the probably good edits. If I no longer had this information, I could no longer (filter) it and would have to check every single edit. But that's not possible because it would be inefficient and would take far too long. Children who play can easily be blocked by blocking the temporary accounts, but with trolls and spambots you still have to block IPs, here it is essential to also query and block the IP address. The fact that in many cases, such as here, I have to make 2 blocks is acceptable, but the retrieval of the information here is catastrophic, first I have to retrieve the IP by click, then I can only retrieve information elsewhere via the IP this is time-consuming. Generally, I think it makes a lot of sense that authors who only write or people who only read no longer see any data here. But I don't understand why not more difference is made here between the user groups. This is roughly how I would design an admin view and how I would like mediawiki to work efficiently and realistically. gitlab:wikibayer/TempAccountInfoTooltip/-/raw/main/TempAccountInfoTooltip.js I also don't understand why you can click on it first. In my opinion, automatic loading makes no difference. Loading (displaying) a IP address is not the same as using it. I also ignore information that I don't need. WikiBayer (talk) 10:29, 2 November 2024 (UTC)

@WikiBayer Note requesting the IP addresses is logged (the log being available to Ombuds, CheckUsers and Stewards). So, if possible, requesting IP only if needed would be useful, to help with auditability.

That being said, a feature to automatically reveal IP addresses (until certain conditions) is currently under consideration, see phab:T358853. It is not yet clear how it will work like, but it is on the list of things to figure out before the next deployment round. I expect it to be restricted to user groups that really need that kind of access, such as global sysops, for pretty much the reasons you mention.

Hope this helps! Martin Urbanec (talk) 23:09, 7 November 2024 (UTC)

Will newly created wikis from Incubator during this period uses temporary accounts?

In case there is new languages approved at m:RFL and created before the temporary account is available in all the wikis, will those newly created wikis use temporary accounts? 132.234.228.209 01:43, 6 November 2024 (UTC)

Great question, thank you! I don't think the team has discussed this, but I believe the answer would be: unlikely, no.

Why? We are strict about the criteria for wikis which may get temporary accounts early. We want to learn how temp accounts work in real life, uncover the unknowns, and this is possible on wikis of a certain size. New ones are too small. So temp accounts will be deployed there in mid-2025. SGrabarczuk (WMF) (talk) 03:04, 6 November 2024 (UTC)

Suggestion on minor change in temporary name system

Temporary accounts have been active for just a couple of days, and we're already into five digits of the account names, ~2024-XXXXX. Imagine the 2025 temporary names in a year from now, they will be just as horrible as an IP address to distinguish from each other. I suggest that starting January 1st 2025, the temporary names should be ~2025-01-XXXX for usernames created in January, ~2025-02-XXXX for February, etc. Maybe even use the full date: ~2025-01-01-XXXX? Of course, it's still a username consisting of a long series of numbers, but the unique ID part of the username will not be as long as it's going to be by using only the year. Regards, nowiki sysop 1000mm (talk) 13:25, 8 November 2024 (UTC)

Hi, That's a sensible proposal. Yann (talk) 19:16, 5 December 2024 (UTC)

Hei @1000mm, thanks for the comment. Let's clarify one thing. I think we didn't start with 1, so we arrived at the five-digit numbers sooner than we could. You can check it yourself by searching for different numbers in Special:CentralAuth. So I'm guessing these numbers are kind of misleadingly high. I will confirm it with the team. SGrabarczuk (WMF) (talk) 23:18, 6 December 2024 (UTC)

Hi @SGrabarczuk (WMF), thanks for your time and answer.

Looking at CentralAuth, ~2024-8000 was a test account created in September, and ~2024-8001 looks like a real user from 1 November. Zero edits by 8001 though, but a user name has been created. I don’t know the details on the tech behind this, but several ~2024-n users without any edits on any wikis must mean that some of the Wiki readers are given temp user names too. If so, the numbers of readers around the world is hundreds of millions (when used on all Wiki projects)!

The highest I find is ~2024-24732. That’s 16,700 temp users in one month, with just 12 (small?) pilot wikis using it.

I still think that, when launched globally and having been in effect for almost a year, we will see some high ~2026-numbers in December 2026. The numbers won’t be that high in 2025, as I doubt this will be used globally in less than a month from now, but by 2026 I assume all wikis will use it?

Of course, going from 10,000 to 100,000 will take 9x longer than from 1 to 10,000 but still. At least ~YYYY-MM-n seems reasonable, only time will tell if ~YYYY-MM-DD-n will be necessary to avoid high monthly numbers. 1000mm (talk) 00:10, 7 December 2024 (UTC)

Let's also take into account that currently, these usernames are supposed to have the numbers grouped in 5-digit series, for example ~2024-10000-1.

(Temp accounts without edit counts may mean that their edits were blocked by AbuseFilter, because strictly speaking, a temp account is not created at the moment of a successful save, but at the moment of any save attempt.) SGrabarczuk (WMF) (talk) 23:28, 9 December 2024 (UTC)

Ah! Groups of five makes it a lot easier to read, than several digits ~2024-1234567890. Good to hear you already thought of that. Therefore, my concern is not so much of a concern anymore. Thanks for explaining what triggers the temp user creation. 1000mm (talk) 00:01, 10 December 2024 (UTC)

When will the temporary account available on Test Wikidata?

As I remembered that the temporary account is available for test in testwiki and test2wiki back in July. However, temporary account is still not available in test Wikidata. Will temporary account be deployed in test wikidata the same day as wikidata or the deployment in test wikidata will be done before wikidata? 132.234.229.162 01:52, 13 November 2024 (UTC)

We don't have any timeline specific to test wikidata other than our general deployment plan. So unless there are convincing reasons to do that earlier, we'll deploy there together with major pilot wikis (late February) or with everyone else (mid-2025, May?). SGrabarczuk (WMF) (talk) 13:53, 18 November 2024 (UTC)

Thoughts/feedback on the temporary account UI

Hi, I was recently testing out the UI for temporary accounts (to make sure a extension worked well) and my first instinct is that the huge black bar at the top is kinda distracting especially for somebody who might primarily be a reader (and a very occasional editor) of a wiki (which appear to be the target demographic for the feature). I think at the very least, the bar at the top (if we do want a bar) should match the aesthetic/style of the rest of the wiki skin and not call attention away from the rest of the page content (which should be the primary focus of the reader). Sohom Datta (talk) 22:51, 27 November 2024 (UTC)

Also, the only way to get rid of/minimize the bar is to log out of the account, which will make it harder to trace edits to a particular person and cause the number of temporary account to unnecessarily increase. Sohom Datta (talk) 22:53, 27 November 2024 (UTC)

Thanks for your input @Sohom Datta. There is a task tacking usability suggestions for the temporary account status bar (task T375712), please feel free to add comments there or create subtasks with specific suggestions. KHarlan (WMF) (talk) 11:57, 17 December 2024 (UTC)

English Wiki Rollout

Is there any tentative date on the rollout of this feature for the English Wikipedia (enwiki)? Bunnypranav (talk) 14:48, 4 December 2024 (UTC)

Yes, May 2025. SGrabarczuk (WMF) (talk) 15:05, 4 December 2024 (UTC)

Thanks! Bunnypranav (talk) 15:06, 4 December 2024 (UTC)

Some comments moved to #Moved from English Wiki Rollout

Recognizability

Temporary accounts have been rolled out on my home wiki for a while now; I find it extremely user unfriendly. Every account looks the same (2024, five-digit number starting with 2). When you see vandalism you assume every single temporary-account edit is vandalism because every single account name looks the same.

This is in sharp contrast to the old IP-based system where IPv4 addresses usually look quite different (ok, I admit IPv6 addresses were also indistinguishable). Sometimes you’d still make incorrect assumptions if you didn’t look closely, but right now even if you look closely you can’t distinguish one user from another.

Is there any way to at least randomize the numbers in the second part? Make them really random like different initial digits, different lengths, etc. Otherwise this is a total nightmare. Alıƨsi (talk) 19:35, 13 December 2024 (UTC)

Thanks, this is really interesting! Let's see what we can do. SGrabarczuk (WMF) (talk) 22:54, 13 December 2024 (UTC)