Page MenuHomePhabricator

Anonymous Contributors IP Masking
Closed, InvalidPublic

Description

Decision Statement Overview: https://docs.google.com/document/d/1YWfvBBYYCdN2sEM3snfrPXEAUYdyg6BgQThXjMs09EY/edit

What is the problem or opportunity?

Currently, anonymous users who make edits to Wikimedia projects are able to do so without creating an account. The problem is that for those edits made, their public IP address is used in place of a username, thus exposing some PII with this given user.

For admins patrolling and protecting projects from vandalism have relied on tools that leverage the exposure of these IP addresses. So the challenge here is to provide privacy to anonymous users while empowering admins to continue to fend off vandalism.

Requirements

IP addresses are no longer viewable to public users
As an anonymous user making an edit, I want my IP address hidden from public, non-authorized users, so that my identity remains private.

IP Data Retention
Remove IP addresses from the database after 90 days.

Create a temporary account for anonymous users
As an anonymous user, I want a temporary account, so that I have privacy and my IP address isn’t available publicly

  • Acceptance Criteria
    • A unique temporary account is reserved. The account is not officially created until an edit is submitted by that anonymous user.
    • The temporary account is associated with the user’s session

What does the future look like if this is achieved?

The privacy of users is protected with no PII being publicly exposed. We also want to continue to encourage contributors who have made anonymous edits.

The role of anti-vandalism is unimpacted by this change and can continue to identify and prevent bad actors from vandalizing projects.

What happens if we do nothing?

User privacy remains at risk for publicly exposing PII such as IP addresses.

Any additional background or context to provide?

IP addresses need to be purged after 90 days in accordance with data retention policy. Likewise, the masking or removing of IP addresses from public exposure are only those anonymous edits moving forward. This does not need to mask or remove the past IP addresses that have been made publicly available.

Why are you bringing this decision to the technical forum?

For contributors feel safe contributing to the movement which aligns to our objective

Our platform and our contributors will be better protected with improved movement management & curation tools (software and practices)

Additional resources

Event Timeline

I'm starting to think, the right framework for this task is given by this clue from the statement of consequences:

WMF could be in violation of GDPR and other data privacy regulations...

Until we can mask IP addresses, we are failing to protect the users' human rights and privacy, causing individuals harm, and biasing who can safely participate in the project.

Can we call this a "High" priority?

I made a document comparing the implications of different solutions from a technical perspective: https://docs.google.com/document/d/1uHCZHt4OMY5U2gBMOPL-BHcvMsOPPGGYhcQVNRaGmNk/edit#

It's great to see these proposals, thank you for the work put into this so far! I had a few questions,

  • For the "IP masking" suggestion, encryption would have to be performed with a salt, most likely one derived from the session ID. Otherwise, multiple editors coming from the same IP would have the same masked IP which I believe is undesirable. Without a salt, there might also be attacks allowing you to unmask an IP by running the encryption routine directly. This doesn't change the proposal, but is a security detail worth mentioning.
  • The three alternatives suggested so far seem to be very similar: user session is mapped to some form of quasi-permanent identity. Have you also considered a wider range of alternatives, such as anonymous editors having *no* on-wiki identity, being truly anonymous? Short-term records would still be kept for privileged auditing of course. Flagged vandalism could still be correlated with a group of edits, by checkusers.
  • Since the masking is dependent on session, what happens when the user's browser does not establish a session, for example when cookies are disabled? Are we creating a new "temporary" user for every edit? Is that helpful or not? How common is this use case?

For reference, the three options that @awight is referring to from the doc I put together are:

  • "IP Masking": Keep using the user’s IP address as their name, but show a masked (encrypted) version of that name.
  • "Anon Actor": Keep using the “anonymous user” concept in MediaWiki as before, but use a randomly generated name instead of an IP address to represent anonymous users.
  • "Temp Account": Instead of modeling “anonymous” users, always create a user account when a user edits, initially using a randomly generated name.

Note that these are a summary of my own understanding of different options I have heard discussed. These may not necessarily be the options that the team driving this proposal has in mind. I am not part of that team. I summarized my understanding here to see in how far it matches other people's thoughts on the matter.

sdkim renamed this task from Temporary Account Creation for Anonymous Users (IP Masking) to Anonymous Users (IP Masking).Jun 9 2021, 3:05 PM
sdkim updated the task description. (Show Details)

IP addresses need to be purged after 90 days in accordance with data retention policy.

Would this include Checkuser data? There's been some (currently private) discussion around that topic recently: T170148.

Additional resources

I assume this was meant to be public.

Jenlenfantwright renamed this task from Anonymous Users (IP Masking) to Anonymous Contributors IP Masking.Jul 12 2021, 7:48 PM
Jenlenfantwright updated the task description. (Show Details)

Withdrawn from technical decision forum as decision on how to proceed wasn't needed in the end, received feedback needed on impact on software/departments which is what was desired.

@Jenlenfantwright can you clarify how/when the decision between the implementation options mentioned in T283177#7134490 if not in the current process?

@Tgr Please consult with @sdkim on your question directly as he can provide more insight into how this will proceed moving forward if at all. Thanks!

Removing inactive task assignee.

Jdforrester-WMF subscribed.

Should this be declined in favor of T324492: Temporary accounts - MVP?

I'd say Invalid, given the TDMP process was abandoned. The work (as opposed to TDMP about the work) continues over there, as you say.