Page MenuHomePhabricator

Add user-agent variable for abuse filtering
Open, LowPublicFeature


One recent example of spam edits has identified the user agent; appid: s~bagswish

in recent usage. It is reasonable to expect that such and similar types of abuse is going to continue to occur, and where it is occurring then it would seem an easy and convenient means to block such user-agent components after they have been identified by checkuser process

Would be useful to have variable_name user-agent, and variable values, with regex that could be applied.

Naturally there are some dangers, however, with the clear inability to be able to checkuser for a specific user-agent, and with such spammers having the ability to operate across so many wikis, the ability to prevent is required. I envisage that at WMF this would be a global filter added by stewards only as required.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:17 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz48623.
bzimport added a subscriber: Unknown Object (MLST).

Adding the User-Agent as a variable would be rather easy to do, the issue is that we don't have a way to make sure only CUs/Stewards could use and see it.

See for a related bug report T40297

@Matanya Hi. I don't think this is a duplicate. This is for AbuseFilter, not for CheckUser :)

DannyH subscribed.

Sorry, closed in error. @MarcoAurelio thanks for the ping.

I think we can close this as a dupe of T40297.

I think we can close this as a dupe of T40297.

That task is restricted.

That task is restricted.

Oh yes, my bad. I'd say topics are the same though.

In T50623#3575038, @Samtar wrote:

T173307 related?

To some degree.

Here, the task requests the UA to be exposed *as a variable* (meaning that anyone who can edit a filter can see its value, or else it would be impossible to debug rules, etc)

There, the task does not ask for it to be exposed as a variable. It only asks for it to be stored along with the *private data* associated with each log entry. We do have a way to control who can see the private details of the log and can restrict it to CheckUsers only, for instance. This, answers the issue raised by Legoktm above (in 2013 for crying out loud).

Another related task is T152934 for which I have already made a patch. Once that goes in production, we have the ability to give the access I just mentioned to the CheckUsers in WMF wikis. (We don't give them this currently, because we don't have a way to keep track of who access what private information).

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM