Page MenuHomePhabricator

Remove IP addresses from watchlist notification emails
Open, Needs TriagePublic

Description

Watchlist notification emails contain the username/IP of the person who has edited the watched page. This means that in cases where an editor has accidentally edited logged out, any user receiving watchlist notification emails for that page now has a permanent record of the IP address of the editor, even if the editor immediately realizes their mistake and has their IP address suppressed onwiki.

IP addresses are listed in two places in these emails: first, the prose summary ("The Meta page $pagename has been changed on $date by anonymous user 12.34.56.789, see $link for the current revision."), and second, the "contact this editor" links later in the email ("Contact the editor:
mail: No email address
wiki: https://meta.wikimedia.org/wiki/User:12.34.56.789")

While release of an IP in this way is a low-priority issue in many cases, in cases of hotly contested or highly-watched pages (for instance, Gamergate articles, which involve an internet-wide dispute that has gone offline into real-world threats in the past), this is potentially a significant issue for users concerned about their privacy and security.

Please consider anonymizing IP addresses in these emails in some form - possibly by changing the email text to "has been changed on $date by an anonymous user" and removing or obfuscating in some way the link to the IP's talk page.

Per Quiddity, the current wiki-config variables for these emails are listed at https://www.mediawiki.org/wiki/Manual:Configuration_settings#Email_notification_.28Enotif.29_settings

Event Timeline

Kbrown created this task.Feb 11 2016, 4:02 PM
Kbrown raised the priority of this task from to Needs Triage.
Kbrown updated the task description. (Show Details)
Kbrown added subscribers: Kbrown, Quiddity, Catrope.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptFeb 11 2016, 4:02 PM
Krenair closed this task as Declined.EditedFeb 11 2016, 4:19 PM
Krenair claimed this task.
Krenair added a subscriber: Krenair.

The emails reflect what the user can see at the time, and on wikimedia sites (among others) are actually broadcast publicly instantly (RCStream, IRC feeds), capable of being logged by anyone before any revdel can take place. You'll also often find edit summaries containing IPs, and those definitely aren't going away from email notifications.

The issue you'd like to solve (people can get their own record of page history before someone else comes along and revdeletes stuff from it - this does not just cover IPs but any username and anything else deletable) cannot be solved by not sending out copies, as ultimately a user can just go to the site and download a copy (and then keep it forever regardless of revdeletion) if they want. If you're worried about IP privacy specifically, you could theoretically come up with an alternative to storing IPs in page history. Or, change usernames/IPs to be hidden by default and only made public after trusted user review (needless to say, not going to happen for so many reasons).

There is a big difference between "theoretically it's accessible" and "it's broadcast without user intervention".

Yes, even with this change, IPs and edit summaries will still be broadcast for edits later oversighted. But there is a vast difference between "could" and "automatically does". Most users do not have the technical ability or interest to follow the RC streams. Most people do not even know the IRC feed exists. These emails, on the other hand, are sent to watchers as a system default. I can't count the number of times, as someone who follows neither the streams nor the feed, I've received emails with later-oversighted summaries or IPs in them. "It is inconsistent" does not matter; it is absolutely consistent to what most users see because what most users see are these emails.

In any case, as a process question I would ask (for future bugs) what is the Collaboration's team's process around feature requests or changes? On my team, at least, while myself or engineers can jump in with opinions it's the Product Manager who makes a final call about whether a request should be declined or not, since they are the person ultimately responsible for product decisions.

Krenair added a comment.EditedFeb 11 2016, 4:39 PM

There is a big difference between "theoretically it's accessible" and "it's broadcast without user intervention".
Yes, even with this change, IPs and edit summaries will still be broadcast for edits later oversighted. But there is a vast difference between "could" and "automatically does". Most users do not have the technical ability or interest to follow the RC streams. Most people do not even know the IRC feed exists. These emails, on the other hand, are sent to watchers as a system default. I can't count the number of times, as someone who follows neither the streams nor the feed, I've received emails with later-oversighted summaries or IPs in them. "It is inconsistent" does not matter; it is absolutely consistent to what most users see because what most users see are these emails.

This changes nothing security-wise. Let's not give users a false sense of security please. The username (logged in account or IP) is public for all to see as soon as the edit goes into the database.

In any case, as a process question I would ask (for future bugs) what is the Collaboration's team's process around feature requests or changes? On my team, at least, while myself or engineers can jump in with opinions it's the Product Manager who makes a final call about whether a request should be declined or not, since they are the person ultimately responsible for product decisions.

It doesn't matter - despite this being tagged against a WMF team project, it has a MediaWiki core project attached. I don't need to go through WMF to decline it. I believe there are two people who happen to be on that team who are able to try to reverse this (they are MediaWiki developers in their own individual right), and neither of them is a product manager.

For the record, Roan asked me to file this so that it existed in a reviewable format for him/his team. How priorities are hashed out among phab users is not something I'm familiar with, so I don't know if "he asked me to" matters, or whether he wanted to review it because he thought it was workable or because he just wanted to wontfix it officially or what.

As far as my reasoning in asking for this fix, my thoughts are similar to Ironholds's: I see a difference between "this information is accessible to someone who knows how to pull it from various feeds" and "this information is served directly to people interested in who is editing this particular page, without them even looking for it". It would be misleading to represent fixing this as "...and therefore, IPs of logged out editors are protected from ever being seen!", but my goal here is not to protect everyone from everything, just to close a loophole that directly serves IP data to watchers of a particular page.

scfc added a subscriber: scfc.Feb 11 2016, 6:17 PM

There are a number of tools that directly process the feeds to broadcast such edits in real time (cf. for example https://en.wikipedia.org/wiki/CongressEdits), so the technical barrier is very low.

But for example in Germany, if I have an IP address and a time, I would need a court order for the provider to release the associated name and address, and "wanting to commit a crime" isn't one of the reasons why a court would issue such an order, so an IP isn't that meaningful to me.

I think the basic problem that should be addressed is users editing while logged out. If someone does that unintentionally, the solution should be in making it harder for them to do that, not to insinuate that someone else will turn back the time if needed. If outside of Germany people are risking their lives when they edit while logged out, they should have to explicitly state that they want that.

I agree that the data is broadcast over several non-email mediums as soon as the edit is made, so I don't think this is a sudden security issue.

However, what benefit is added in the notification by adding the IP, instead of just saying, "A logged-out user..."? I don't think there's much benefit, so I would support cutting it out on those grounds.

This problem would go away if we can ever find a way to not label logged out edits by IP, but that's a long ways off.

Catrope reopened this task as Open.Feb 18 2016, 2:53 AM
Krenair closed this task as Declined.Feb 18 2016, 2:35 PM

However, what benefit is added in the notification by adding the IP, instead of just saying, "A logged-out user..."? I don't think there's much benefit, so I would support cutting it out on those grounds.

I don't see a particular benefit in changing it to "A logged-out user" - if it had started like that and someone requested we make it consistent with logged-in users by giving the IP, I would write that commit without question. I'm not sure why logged out users should be treated differently in this respect.

This problem would go away if we can ever find a way to not label logged out edits by IP, but that's a long ways off.

Yes, and also covered in different tasks, I think.

@Catrope: I don't know if you're reopening per Chris' comment or for other reasons, also please unassign tasks upon reopening.

Ironholds reopened this task as Open.EditedFeb 18 2016, 3:00 PM
Ironholds removed Krenair as the assignee of this task.
Ironholds added a subscriber: Ironholds.

Krenair, it doesn't _matter_ why he's reopening. The manager/task-setter of the team that is tasked with this class of problem reopened it. Making the determination of if it gets worked on is his job, not yours. You should read Karen's comments above.

But, sure, I've unassigned you from it, if that's the blocker.

Krenair closed this task as Declined.Feb 18 2016, 4:18 PM
Krenair claimed this task.

The question about teams was already addressed, please see above. You are not a MediaWiki core developer and should probably not be reopening this. That comment was read.

Ironholds removed Krenair as the assignee of this task.Feb 18 2016, 4:35 PM
Ironholds removed a project: MediaWiki-Email.
Catrope reopened this task as Open.Feb 18 2016, 6:22 PM

@Catrope: I don't know if you're reopening per Chris' comment or for other reasons, also please unassign tasks upon reopening.

Sorry for not unassigning when I reopened. I didn't realize Phabricator had assigned the task to you when you closed it (thankfully it doesn't do that any more, after last night's upgrade).

I did indeed reopen per Chris's comment.

Re-adding MediaWiki-Email because this task is about enotifwatchlist.