Help:Temporary accounts/How it works/en

This page describes some of the technical aspects of. It may be useful to people who are updating user scripts, bots and other tools.

What's the change from a technical perspective?
Since its creation in 2002, MediaWiki has allowed users to contribute without logging into an account. The users' IP addresses have been recorded in the page history instead of a username. This will change in 2024. In the future, MediaWiki will create a temporary account, with an automatically assigned username. This automatic username will be recorded in the page history instead of the IP address.

Any time an anonymous/unregistered user, also known in this context as an IP Editor, successfully completes an edit, a temporary account is created for them. This account is in the user table, and is for all intents and purposes a regular account, but for a few differences:


 * 1) A cookie will be set on the user’s browser when the account is created. This cookie will be used to attribute all subsequent edits performed by this user even if the user’s IP address changes. Essentially, there are no more edits that are attributed directly to IPs. The temporary account exists for as long as the cookie exists. The cookie is set to expire after one year from the first edit.
 * 2) There is an automatically generated username assigned to this user, and no password. As such, it is impossible to log in to this user account. The only way to be logged in as this user is to simply have an unexpired cookie that was set when the account was created.
 * 3) As for the code:
 * 4)   will return true for all registered accounts, including temporary accounts.
 * 5)   will return false for such temporary accounts.
 * 6)   will return true exclusively for temporary accounts.
 * 7)   will return true exclusively for registered accounts that are not temporary accounts.
 * 8) Temporary usernames will begin with an asterisk and take the general form of : ~12345  (the format is defined by the config  ). This format will undergo user-testing and is subject to change.
 * 9) A temporary user will be represented by a row in the user table. A row can only be determined as representing a temporary (as opposed to registered) user via the name  stored in user.user_name. A temporary user name will match the config.

Why are temporary accounts being used?
The Anti-Harassment Tools team compared a few different technical approaches to the project. For example, we could have chosen to obscure the IP address without creating a temporary account. After discussing these with the Legal team and volunteer editor community through the IP Masking project page, and after considering the ease of implementation and impact on community workflows, we settled on using temporary accounts to hide IP addresses.

The temporary accounts pathway was the one of least resistance as far as implementation choices go. There are a minimal number of changes in the architecture and code which makes it less likely to be disruptive in unexpected ways. Also, creating a temporary accounts helps address some other problems, such as communicating with people whose IP address changes frequently.

Why were temporary accounts implemented as registered accounts?
We have encountered a few questions about the implementation of temporary accounts, which we’ll answer here. For more details you can also read discussions on Phabricator and gerrit, associated with the RfC task: https://phabricator.wikimedia.org/T326816 and the task that added temporary accounts: https://phabricator.wikimedia.org/T300263


 * Why are temporary accounts implemented so similarly to named user accounts, if the users themselves are more similar to anonymous users?
 * CentralAuth integration was a product requirement. After saving a revision, the user is logged in on all wikis. Implementing this without creating a user row would have been very challenging.
 * Creating a user row allows us to share session management infrastructure with logged-in users. The long-lived cookie which keeps the temporary user logged in is identical to the “remember me” feature for regular user accounts.
 * Temporary accounts are meant to represent the actions of a particular person, much like a named account. On the other hand, anonymous (IP address) actors can represent many different people, and it is expected that one person may act via several IP address actors at once.
 * Why does  return true instead of false for a temporary account? Shouldn’t temporary users mostly be treated like anonymous users?
 * A temporary account behaves like a named account internally and represents a similar real-world entity (i.e. a person). This concept - and the software - would become muddled if  returned false.
 * Many features need to treat temporary accounts the same as named users: for example, temporary users can request tokens and use these as identifiers when editing via the API, e.g. in order to build an edit history via mobile apps.
 * Features can be updated on a case-by-case basis to treat temporary users like anonymous users or named users (or in a different way to either).

How should I update my code?
There is no single, simple answer to this question. Temporary accounts are a new way of representing anonymous editors, which could have enormous impacts on some parts of software but barely make a difference to others. Solutions might involve a lot of product research, but a straightforward technical fix. Or a technical fix might be complicated and require domain expertise and judgment.

Examples of ways code might be affected and how to consider fixing it (disclaimer: this is not exhaustive):


 * A feature is unavailable to anonymous users. Should it be available to temporary users?
 * A feature works differently for anonymous vs registered users. How should it work for temporary users?
 * A feature assumes anonymous users are less trustworthy, and registered users are trustworthy. How should it treat temporary users?
 * A feature displays different UI messages for anonymous vs registered users. What should it display for temporary users?
 * A feature assumes registered users have preferences. It now needs to check for named users instead, since temporary users don’t have preferences.
 * A feature assumes registered users have a watchlist. It now needs to check for named users instead, since temporary users don’t have a watchlist.
 * A feature assumes registered users have rights. However, temp users will have no more rights than anonymous users, so code should be updated accordingly.
 * A feature looks for the IP address in the user name (it will no longer be found). If the feature doesn’t leak the IP address (or related information, e.g. geolocation data), look in the request data instead using . Otherwise, the feature should be discontinued or only available to checkusers, admins and users in a new “temporary account viewer” group.
 * Statistics are gathered separately for anonymous and registered users. How should temporary users be bucketed?
 * A user is flagged as anonymous or registered (e.g. in logs or API results). How should temporary users be flagged? What would features checking these flags like to know?
 * Some feature or part of the infrastructure assumes that the user table will keep growing at its current rate. This assumption won’t hold after IP Masking is enabled: the user table will grow more quickly.
 * Some feature or part of the infrastructure assumes that the ratio of registered to anonymous users accessing Wikimedia sites will stay roughly the same. This assumption won’t hold anywhere that temporary users are treated as registered users.
 * A feature that relies on looking at the user’s ID to identify if the user is registered or unregistered. Temporary accounts will not have a  of 0. An example of this might be instrumentation.

In the simplest scenario, you may only need to update a check for the type of user: The  service has the same methods and should be used when the name is available, but not a full   (or  ) object.

Similar methods are available in JavaScript via the  and   modules:



However, we have encountered more complex examples where more complicated product and technical solutions are needed. For example, when an IP address is blocked from editing, there is an option to block anonymous users only. Should this block temporary users too? Should there be a separate option? Code updates could include changes to core PHP classes, UI forms, site configuration options and the database schema. Similarly significant updates may be needed to other products.

It’s important to emphasize checking your products carefully, since they may need to be re-conceived for temporary accounts.

How and when can the account expire?
The following are the most common scenarios where an account can expire in an irretrievable manner:


 * 1) A user clears cookies on their browser.
 * 2) The user deletes a profile on their browser that they used when the temp account was created.
 * 3) The user was using a private (incognito) window in their web browser, and closed the window.
 * 4) The cookie expires.

Furthermore, given that these accounts cannot be logged into, the user will not be able to access their temp account from a device or a browser other than the one it was created with.

Features of temporary accounts

 * See also User account types

Temporary accounts do not have all the features of registered accounts. Temporary accounts can have. They can receive and see. The IP address used with a temporary account can be seen by trusted users, such as.

Design guidelines around this change

 * Parity with IP editor rights, at first. Initially, the IP-masking experience should minimally have parity with the legacy IP experience in terms of what capabilities are available to such editors. Though the architecture of IP masking affords opportunities to open up richer and persistent experiences to logged-out people, these opportunities should be deferred until after the initial launch so that communities have as little change as possible during this major shift.
 * Temporary accounts should feel ephemeral. People should not think they have an account when they do not, and there is space for education to include highlighting the incentives of creating an account as opposed to remaining logged-out (similar to the prompts that appear for IP editors).
 * Clarity that anyone can edit. Equally, it should also be clear to the person with a temporary account that it is still not required for them to create an account to continue editing. Maintaining one of the five pillars of Wikipedia.
 * Guidance and education incorporated in the new experience.
 * People should not be jarred or confused when the account disappears.
 * People should not perceive that their privacy is reduced with a temporary account compared to an IP-edit. On the contrary, consider opportunities to highlight that privacy is improved as a temporary account editor compared to an IP edit, since the IP address will no longer be shown except to privileged users.