Help:Temporary accounts/en

A temporary account is an automatically created account. It is an alternative to using the user's IP address as an identifier in the page history.

What does IP Masking change from the end-user perspective?
IP addresses would be hidden from end-users except for those who need it for patrolling purposes. Upon successfully completing an edit without having logged in first, users will be warned that they will be provided a temporary account. This temporary account will follow a standard pattern with an incrementing number for each new temporary account. The temporary account will be tied to a cookie that lives in the user's browser. As long as the cookie persists, the user will retain the temporary account and all their edits will be attributed to the same temporary account. The user may change IP addresses under the hood but the temporary account will not change as long as the cookie persists. Temporary accounts will be available globally. A temporary account generated on one wiki will also be valid on other wikis that user may contribute to. This is similar to the experience for registered accounts.

After a certain period of time (tentatively one year), the cookie will automatically expire and the user will be granted a new temporary account for subsequent edits.

Note: Temporary accounts holders will not be able to convert their accounts to a permanent registered account. This means that when a temporary user decides to create a proper account, their edit history, notifications etc will not carry through to their new account. This is another reason to not expose preferences for temporary accounts.

What’s the change from a technical perspective?
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 : *1345  (the format is defined by the config  ). This format will undergo user-testing and is subject to change.  The asterisk will not be changing however.
 * 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. 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.

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.

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

Who will be able to see IPs after IP Masking is in effect?
Exposure of IP addresses will be limited only to users who need to see IPs for effective patrolling. This includes:


 * Stewards
 * Checkusers (on their respective wikis)
 * Admins (on their respective wikis)
 * Patrollers who meet qualifying thresholds
 * WMF T&S staff

How should someone update their code?
There is no simple answer to this question. Temporary accounts are a whole new way of representing anonymous editors, which could have enormous impacts on some parts of software, and 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.

Features of temporary accounts
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.

How long will a cookie last by default?
12 months.

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 an incognito window and closed it.
 * 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.

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.