Requests for comment/Exposure of user IP addresses
This request for comments is regarding exposure of user IP addresses.
Exposure of user IP addresses | |
---|---|
Component | General |
Creation date | |
Author(s) | MZMcBride |
Document status | in draft See Phabricator. |
Previous discussions
edit[FIXME: there have been a million wikitech-l, mediawiki-l, Bugzilla, and wiki discussions about this; find and cross-reference here please. See candidates.]
- phabricator:T20981
- mailarchive:mediawiki-l/2009-May/030979.html
- m:Talk:Privacy policy/Archives/2013#Still lacking IP privacy protection.
- m:Talk:Privacy policy/Archives/2013 (2)#Do not save the IP of logged in users!
- m:Talk:Privacy policy/Archives/2013 (2)#Strip Wikimedia Data Collection to the Barest Minimum - Privacy Specifics
- mailarchive:wikimedia-l/2015-March/077341.html
- [Wikimedia-l] Editor safety and anonymity: ending IP address exposure? (started by Brion)
Related discussions
editBackground
editCurrently within MediaWiki, if a user chooses not to log in, MediaWiki uses their assigned IP address as the user identifier. If a user edits while logged out, the IP address is recorded and stored in perpetuity as a username would be.
If a user edits whiled logged in, the associated address is privately stored for 90 days and only accessible by system administrators, or in the case of Wikimedia wikis and other wikis using the CheckUser extension, a small group of trusted users. After 90 days, the information is purged from the system and no longer accessible.
Advantages to using IP addresses
edit- Knowing whether an IP address belongs to a school or the U.S. Congress or whatever can be helpful information.
- IP addresses are relatively difficult to change for an average user, helping prevent vandalism and other repetitive harm to the projects.
- IP address ranges can be blocked.
Disadvantages to using IP addresses
edit- Privacy concerns!
- Users can be unknowingly and unwillingly identified when editing while logged out.
- Information about underlying IP addresses used with user accounts can be subpoenaed by law enforcement during the retention period.
- Privileged accounts such as shell user accounts or CheckUser accounts with a compromised password can expose IP address information to unauthorized parties.
Use cases of unregistered users
editWhen it comes to unregistered users, it's not entirely clear what's a requirement/feature and what's an implementation detail. This matter is discussed in more detail at m:Musings about unregistered contributors.
- Some unregistered users edit from static IP addresses, preferring not to have an account but also preferring to be semi-permanently identifiable. Some also have a stable user talk under a placeholder username, to have a single inbox.
Proposals
editRelated to the previous discussion above. Usually some kind of salting, random name thing.
Most/many sites solve this problem by requiring all users to log in. IP addresses are never exposed in the public user interface, but are often available to administrators or other privileged users in the user interface.
In wikis, unregistered users can edit simply because in the original UseModWiki implementation anyone can edit, without authentication, and no other solution has been implemented in the meanwhile which is both effective and equally inclusive. We want a fast and lightweight option, similar to what unregistered editing provides, for drive-by improvements. We could add a username field to the edit screen and auto-register the user with a unique username derived from the chosen one and without an email address.
Comparisons
editStackExchange autoregisters self-mergeable ghost users named like "user123456", moderators can see IPs and merge accounts. Note, it's not a wiki: they gatekeep every edit with voting/karma systems, changes are less atomic and harder to track, there is no complete log of actions. They also monitor sockpuppets and have permanent automatic IP address and IP range blocks as well as manual IP blocks by sysadmins; unregistered users have various limitations even on read-only activities. A suppress/redact feature was introduced in 2016.