Jump to content

Community Wishlist Survey 2023/Anti-harassment/Allow checkusers to use user-agent variables in Abusefilters

From Meta, a Wikimedia project coordination wiki

Allow checkusers to use user-agent variables in Abusefilters

  • Problem: With AbuseFilters, there are several ways to target long-term abusers and harassers, including IP adresses, but we lack one which could be powerful: user agent (UA).
  • Proposed solution: Add a user-agent variable to AbuseFilter. This would require first that CheckUser-level abuse filters to be created.
  • Who would benefit: Everyone, especially victims of harassment; sysops, patrollers and anyone that fights long-term abuse (with harassment or not); checkusers who are abusefilters editors.
  • More comments: The only downside that I see is that it would require some CheckUsers to be familiar with Abusefilters and regexes.
  • Phabricator tickets: phab:T234155 and phab:T50623
  • Proposer: — Jules* talk 20:06, 2 February 2023 (UTC)[reply]

Discussion

  • User-agent's design is well-known. Such "Mozilla/5.0 (Linux; Android 6.0; HTC One M9 Build/MRA58K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.98 Mobile Safari/537.3" for HTC One M9's mobile could be handled by a few variables, depends how precise we need to be : kernel from a database [equiset] and inherited from browser, browser = "Chrome 52.0.2743.98" [browser_version ?], device = "HTC One M9", system = "Android 6.0". Even if vars are regex-alike, a Toolforge tool can easily parse and convert an UA's string into regexes (mainly . into \., [0-9] into \d). LD (talk) 20:59, 2 February 2023 (UTC)[reply]
  • phab:T242825 should probably resolved first. The current status from Chrome suggests time is running out, and Firefox is in support so they will likely follow suit. I'm thinking if anything, someone should re-propose Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation. Would you be interested in that, Jules*? I think it's going to be worked on regardless, but the proposal will help ensure it has the urgency it needs. MusikAnimal (WMF) (talk) 02:42, 6 February 2023 (UTC)[reply]
    Maybe @LD or Hyméros could re-propose that, as they better know the subject than myself? — Jules* talk 16:53, 6 February 2023 (UTC)[reply]
    Re-proposing a known whish is irrelevant (at least not recommended). RFC1945's design, or RFC8942's design, doesn't matter much in front end. It's all about matching properties retrieved in Abuse Filter. At some point, SEC-CH-UA might be used instead of UA, but while waiting for the migration, the request seems justified to me. On top of that, SEC-CH-UA seems to not be uncompatible with the purposes of this request [1][2]. LD (talk) 17:44, 6 February 2023 (UTC)[reply]
    Well, as I said, I assume the user agent deprecation will be worked on anyway. And you're right; whether it's client hints or UAs, we can use whatever one is available and expose in CheckUser.
    We just approved Allow checkusers to use XFF variable in Abusefilters knowing it involves phab:T234155 which the more significant amount of work. So I'm going to approve this one, too. According to a blog post from Google, UAs as we know them will largely be gone in just a matter of months, and thus probably not that useful in AbuseFilter. But there other browsers than just Chrome, and automation can still supply a custom UA. So I think there's something to do here regardless of what happens.
    I'll approve this now. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:28, 7 February 2023 (UTC)[reply]
    Hello everybody. I just want to emphasize that in the few cases where we need to track the "agents", it always involves the use of mobile phones, sometimes with the added use of WikiApp. In this case, the phone model is the final discriminant element. The ability to select or sort based on one of the agents would really save us hours. Hyméros --}-≽ Yes ? 17:47, 8 February 2023 (UTC)[reply]

Voting