Proposed behavior
If a user provides an IP range as an input in the 'Muted users' preference, all notifications that come from within that IP range should not be delivered to that user.
https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-echo
This could either be for just IP edits or both IP + user actions within that IP range. But would this be an area for Privacy concern? a way for bad actors to guess + test notification system.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T207659 Allow 'Muted users' notification preference to support IP ranges | ||
| Open | Feature | None | T351091 Allow muting all non-permanent users |
just IP edits
This would be good.
both IP + user actions within that IP range
This would be a privacy violation. Any user could find the IP range of any user that sends them notifications.
Brought up on enwiki village pump recently: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Why_can.27t_I_stop_IPs_using_the_ping_feature_to_abuse_me.3F. Not allowing users to mute IPs enables harassment.
Muting IP ranges would probably add a lot of complexity. T351091: Allow muting all non-permanent users filed today is a slightly different but probably still effective solution.
Change 973858 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/core@master] Add support for IP addresses and ranges in MultiUsernameFilter
It's not too much of complexity as MW already has utilities for parsing and checking IP ranges. The linked alt approach seems too wide, causing too much collateral damage while trying to mute a specific range.
Change 973859 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/extensions/Echo@master] Allow muting IP addresses and ranges
If we want to do this for IPs, we should probably start with temp accounts too - per T344647
Agreed. Luckily muting temp accounts via Echo preferences is still working - have commented at T344647#9333768
The harassment aspect cannot really be addressed by muting in the long term, because once temp users are enabled, it will be trivial to generate new accounts. Can't harassers simply be blocked? Once we have an incident reporting system in place, it will be easier to figure out how to get help from an admin.
One thing to keep in mind is that these mute features use a very loose newline-separated string as their storage format. This means consumers in JS, and via the API, see these as a list of IDs separated by new line (Codesearch shows that echo-notifications-blacklist is, for example, also used by the ConvenientDiscussions gadget). It's not obvious how these callers will react to IPs appearing in the same list. It might make sense for the storage format to eg. use JSON and store the list of IDs as {"ids":[…],}. That would allow you to later add IPs to this. Likewise, it would allow you to not have to validate "just in case" these values every time. I notice that the above two patches duplicate the merging, filtering, and validating of isIPAddress in a quite a few places, each of which has to do it the exact same way or else we produce surprising results. I imagine the chances of external consumers getting that logic exactly right are very slim. This can't be fully eliminated probably for setting values (but we can validate that centrally when saving options). But for reading values it can be fully eliminated if it is stored in a structured way.
On the other hand, doing that additional format migration first might make it cost more effort than worthwhile considering the IP-range feature of "muting notifications" would likely not work under Temp users in the future.
From talking with @SD0001 it seems the main use case is admins who are (un)intentionally harrassed by IPs mentioning their name, to mute this. E.g. in cases where the vandal is hard to block (large/wide IP range), but the damage can be contained if at least it doesn't notify the target. The individual edits can then be dealt with normally by other patrollers. In this case the admin will likely mute "too much" but that's a choice. I wonder how accessible this will be in practice, as it requires the target to understand IP ranges well enough to cast a wide net. It feels like they'd probably just want to set up a really wide range that catches everything (considering it's a case where the source cannot easily be blocked, why would they stay in a narrow range?).
Maybe a more suitable long-term solution, would be for Echo to separate our the "Mention in edit" feature such that you can enable it separately for anons/temps and registered/named users. This would be loosely similar to how on IRC it is possible to disallow private messages by unregistered guests. This would be a personal choice. The admins in questions would then choose to mute "mention" notifs by all IP/temp edits, which is likely what they'd need to do regardless in Temp users. This would also have the benefit of making the feature more accessible. Rather than being gated behind a complex input field where you have to craft a IP CIDR range, you instead go to your Notification preferences and untick the "Mentions in edits from anons" checkbox or something like that.
The other use case is muting notifications from an account that is already blocked, since they can still edit their own talk page and thus write edit summaries where they ping/harras targets. I wonder if muting is the appropiate response there. Why would such editor not be re-blocked without talk page access? In any event, existing mute tools should suffice there for the case of registered/named accounts. In the case of IP ranges, the above idea for muting all anons (not all notifs from anons, only "mentions") would work for this use case as well.