The IP Masking Program

Anti-Harassment Tools Team

May 2023

Agenda

• IP Masking: Background
• Rationale for IP Masking
• The History of the Project
• Current State of IP Masking
• MVP (Minimum Viable Product)
• Design: Mockups of changes involved
• Roadmap
• Work with us

Rationale

01

What is the problem we are trying to solve?

• Problem: we perpetually store IP addresses and publish them publicly when users edit without being logged into an account

​

• Why is this a problem?
• Inconsistent with principles of data protection, particularly data minimization
• Inconsistent with user expectations; despite warnings, we regularly hear from users surprised to see their IP address in history pages
• Creates risks for these users, particularly in locations where governments might target them

​

​

The History of the Program

02

IP Masking: Past

Minimum Viable Product

03

How are we planning to solve it?

1. Build tools to reduce reliance on IPs. As illustrated well in the Impact of IP Masking research report, IPs are crucial for various processes on our projects. The first step to masking IPs is to build the necessary infrastructure to reduce our heavy reliance on IP addresses. Our team built the IP Info feature to help patrollers and administrators work more effectively when IP Masking goes into effect. It’s still a work in progress - we are adding a more reliable data source (Spur) to have better detection for proxies. �
2. Mask IP addresses and replace them with an anonymous identifier. This will happen with the help of temporary accounts. IP editors will receive a new identity that will be tied to their browser session (semi-persistent cookie). This session will last as long as the cookie does. We will roll out the masking gradually across projects to carefully gauge the impact of our changes. Much of this work also involves heavy community education on the changes so we will have to be deliberate about how we push them out. �
3. Migrate existing extensions, gadgets, bots and scripts (collectively “tools”). This work will be dispersed widely. WMF teams will be responsible for updating parts of the software maintained by them. The community will update tools maintained by them. This will be a long tail of work. It will require working in collaboration with other teams and communities to make sure the migrations happen successfully. We will be coordinating with other teams and community volunteers to make this happen.

​

Notable changes

• Who can see IPs?
• IP addresses will be accessible to users who meet the Legal guidelines.
• This includes checkusers (by default), admins (need to opt-in) and patrollers who meet the guidelines (at least 300 edits, account > 6 months old and not blocked on more than one project. Projects may introduce their own more restrictive guidelines.
• No more public access to IP addresses. Users without an account will no longer be able to view IP addresses.
• Cookie-based identity
• Temporary accounts will be linked to an auto-generated username that is based on a cookie on the user’s browser.
• Instead of each edit being attributed to an IP address, multiple IP addresses can now be linked to a given temporary account.
• By default, the cookie is meant to last 12 months.

Mockups

04

Unregistered editors: First edit

Unregistered editors: Temp account creation

Unregistered editors: Subsequent edits

Unregistered editors: Temp account expiry

Admin workflows: Revealing IP addresses

​

Admin workflows: Revealing IP addresses

Admin workflows: Revealing IP addresses

Admin workflows: Blocking temporary accounts

Admin workflows: IP Info

Technical changes

05

Overview

• A temporary account is created on certain actions (e.g. edit)
• Defined by a session-linked cookie on the user’s browser
• Persists across IP address changes
• No login, no password
• Name auto-generated
• Name has prefix, defined in config $wgAutoCreateTempUser
• Name no longer holds IP address

Overview

• Similar to an anon user
• Can’t log in
• Can’t choose name
• No preferences, emails, user groups, etc
• Similar to a registered user
• Has a row in the user table
• Has session cookie / token
• User::isRegistered() returns true
• IP address is stored for 90 days, in checkuser tables only
• Receives notifications (but no access to notification related preferences)
• Unlike anon or registered user
• IP addresses are visible by trusted users who are not checkusers, for 90 days

How should I update my code?

• You may need to rethink what it does if it:
• Gets IP address from user name
• Does something different for anon vs registered users
• You may not need to update anything if it:
• Gets IP address from request
• Treats registered and anonymous users the same
• You may just need to update a function call or two if it:
• Will treat temporary users exactly like anonymous users
• Will treat temporary users exactly like registered users

How should I update my code?

If access to DB from outside of MediaWiki: user.user_is_temp column

Work With Us

06

The IP Masking Universe

Everything that IP Masking will impact

Discoverable

by WMF

Discoverable

by volunteers

Things to do

Everything that IP Masking will break: plan careful roll-out

Discoverable by WMF: all teams audit and fix�their features

Discoverable by

volunteers: migrate tools that will need to change

We need help!

How does IP Masking impact volunteer-owned tools (bots, gadgets, templates, cloud tools etc)? Help us track down tools that are going to need changing. You can do this by:

• Filing tasks for impacted tools on phabricator. Use the tag #IP Masking so we can find them.
• You can also drop a comment on https://phabricator.wikimedia.org/T337012
• When mentioning a tool please include (if possible): a link to the tool, brief description of what it does and the wiki it is active on.
• Technical Documentation: https://www.mediawiki.org/wiki/Help:Temporary_accounts you can help us expand this to include specific guidance for gadgets, templates, lua modules etc.
• Help us migrate tools that will need migrations to adapt to the upcoming changes.

Resources

Project page on meta with an outline of the MVP and mockups: https://w.wiki/3V8N

​

IP Masking work-in-progress is deployed on German beta wikipedia which can be used for testing purposes. Note that not all workflows have been implemented yet.

​

Technical documentation: https://www.mediawiki.org/wiki/Help:Temporary_accounts

​

IP Masking master task on phabricator: https://phabricator.wikimedia.org/T324492

​

Spreadsheet of IP-related tools that we know about so far

​

Timeline

06

Estimated Roadmap

Thank you!

Access this presentation at: https://tinyurl.com/ipmasking

�Reach out to us: nkohli@wikimedia.org, tchan@wikimedia.org

Appendix

Why choose session-based identity?

• Ties the user-identity to a device browser, offering a more persistent way to communicate with them.
• User identity does not change with changing IP addresses. As IP addresses become less reliable over time, this method offers a better way to keep longer persistent sessions for end users. Also helpful for anti-vandalism patrollers as this lets us build more nuanced blocking capabilities.
• This approach can offer a way for unregistered editors to have access to features which are currently only available to registered users.

“Temporary Account” solution

Current scenario

​

Proposed

​

192.168.1.2

165.28.45.3

220.23.30.40

180.60.42.1

180.60.42.1

220.23.30.40

192.168.1.2

165.28.45.3

A Temporary Account is auto-generated and tied to a cookie on browser/device