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)

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)

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

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)

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)