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.

In T126614#2018936, @Ironholds_backup wrote:

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 T126614#2018936, @Ironholds_backup wrote:

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.

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.

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

I agree entirely with Krenair. This is privacy theater, and likely to be moot now that we finally have IP masking

(which was also a stupid idea IMO, but that's water under the bridge)