Requests for comment/Adding global abuse filter rights to global sysops

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

The following request for comments is closed. No consensus.


Adding global abuse filter rights to global sysops[edit]

Purpose[edit]

To add the following rights

  • abusefilter-log
  • abusefilter-log-private
  • abusefilter-view
  • abusefilter-view-private

to global sysops group existing rights

Background[edit]

  • In early 2013, or thereabouts, global abuse filters were introduced into the toolkit for Wikimedia wikis, with the rights to create these filters assigned to stewards.
  • These filters were piloted on a small subset of wikis, and later extended to small wikis (2013) and medium wikis (2014) with other wikis able apply these filters where there was a community consensus.
  • The ability to view global filters was enabled through a group Abuse filter helpers with the rights applied as shown in Special:GlobalGroupPermissions/abusefilter-helper, which enable the viewing of local filters, global filters and the abuse log at metawiki (this wiki). The rights being abusefilter-log, abusefilter-log-private, abusefilter-view, abusefilter-view-private. Further detail at mw:Extension:AbuseFilter
  • Global sysops currently have the rights as shown at Special:GlobalGroupPermissions/global-sysop, with the current user set being Special:GlobalUsers/global-sysop. Please read about the role of Global sysops and the process for appointing people to the group, and look at that process at SRGP directly or via the archives.

This proposal comes about as the global sysops, generally those cleaning spam from small wikis and otherwise assisting stewards, will see that an edit has triggered a spam filter, but cannot see the content of the spam filter nor the log of the filter to see the issue. This then requires then to guess at the issue, or to take extra steps to respond to the spam.

Where global sysops have experience at filter syntax they cannot advise stewards on improvements to filters, which is an inefficient process.

Action[edit]

  • To seek the input from the community and to identify any issues that may occur with the extension of the identified rights to this existing user group.
  • Questions, and comments invited.
  • I propose that this discussion is open for about a month, prior to review by stewards and a recommendation (c. mid August 2015).

 — billinghurst sDrewth 06:23, 18 July 2015 (UTC)Reply[reply]

Comments[edit]

  • Support if I'm understanding this correctly. It looks like what we actually want is creating a local GS group on Meta and then adding the abusefilter rights here. If so, could the RFC be ammended? (If I'm wrong, could someone make some clarifications.) --Glaisher (talk) 05:59, 22 July 2015 (UTC)Reply[reply]
  • An easy solution can be to grant "abusefilter helper" rights to users with "global sysop" rights, I think.--Syum90 (talk) 08:00, 22 July 2015 (UTC)Reply[reply]
    • Abuse filter helper is a global group not limited by wikisets. Doing this would mean granting rights to global sysops outside of GS wikis. --Glaisher (talk) 13:10, 22 July 2015 (UTC)Reply[reply]
Yes Glaisher, I know, but I think that it is not a big problem since this flags allow only to view the filters, not to modify, if I'm not wrong. But you're right, they're global rights, not as GS's rights.--Syum90 (talk) 13:31, 22 July 2015 (UTC)Reply[reply]
  • Syum90 proposal do have merit since most people copy big wiki abusefilter to smaller wiki abusefilter, but I don't know if this actually applicable.--AldNonymousBicara? 07:20, 23 July 2015 (UTC)Reply[reply]
I have proposed this solution because I think that's the most simple and easy to apply since there is no need to create any new user group or make any technical change, although as Glaisher says "abusefilter helper" has truly global rights that are out of GS's scope.--Syum90 (talk) 07:42, 23 July 2015 (UTC)Reply[reply]
Per the above/below comments, I think the best way to deal with this issue is for those gs who want to look at the filters to apply for the AF helper right. Ajraddatz (talk) 01:09, 1 August 2015 (UTC)Reply[reply]
  • Another solution is to create a local group on meta much like global renamers that is added and removed by stewards. Ruslik (talk) 15:05, 1 August 2015 (UTC)Reply[reply]
  • @Billinghurst: I think this RFC could finish with a votation.--Syum90 (talk) 12:00, 22 January 2016 (UTC)Reply[reply]

Questions[edit]

  • What I understand is that you want GSes to be able to view private global filters. Is that correct? If yes, I think what they need are the abusefilter rights on Meta (not in the GS wikiset, as Meta is not a GS wiki). --MF-W 09:04, 18 July 2015 (UTC)Reply[reply]
    That is how I read it. If that is the case, meta would need to be added to the gs wikiset, a local group created, or all global sysops would need to be given an additional global flag with these rights. I'm not sure if this change is worth it, especially when I think the gs group is due for a bigger overhaul. Ajraddatz (talk) 18:51, 19 July 2015 (UTC)Reply[reply]
    Adding meta to gs wikiset might be a good idea. --Vituzzu (talk) 17:48, 20 July 2015 (UTC)Reply[reply]
    That'd be problematic. GS passed because truly global permissions were removed. I'll be opposed to that. —MarcoAurelio 09:45, 21 July 2015 (UTC) clarification: enabling meta as gs wiki will have the effect of gs being able to edit spam and title blacklist with global effects.Reply[reply]
  • Private filters are kept secure on specific wikis. If they are promiscuously copied gaining access to these filters becomes much easier. Is there a way of avoiding this issue? Rich Farmbrough 01:40 13 August 2015 (GMT).
    @Rich Farmbrough: Is that a general question or related to the proposal? If we are talking about this proposal this is a small subset of users who predominantly already have a local adminship somewhere, and are considered trusted users. I doubt that they are going to be needing to take filters anywhere, (we are talking global sysops and small/medium wikis). FWIW I would usually give away these filters to the big wikis if they wanted them.  — billinghurst sDrewth 05:09, 14 August 2015 (UTC)Reply[reply]
This problem can be solved if a local group is created on meta as I suggested above. Ruslik (talk) 19:04, 14 August 2015 (UTC)Reply[reply]
The problem with trust is that in terms of knowledge, rather than action, it doesn't scale well, nor is it repairable. Of course this is the reason that "security through obscurity" is bad - when there are better ways to be secure. Rich Farmbrough 12:32 15 August 2015 (GMT).
https://meta.wikimedia.org/wiki/Requests_for_comment/Adding_global_abuse_filter_rights_to_global_sysops
meta.wikimedia.org
CC-MAIN-2023-06
70575
application/http; msgtype=response
sha1:I2UD7C2C5PGKN4IJOKJXYBXA6XEF4YST
<urn:uuid:6a5847ce-01ab-456f-9449-125523090677>
2023-02-08T11:47:10Z
208.80.154.224
text/html
sha1:JH5QRR5TEONABJZIYUWYF22D6SALKS7T
<urn:uuid:bf823f5a-8713-497b-afb9-d20c1099651f>
https://meta.wikimedia.org/wiki/Requests_for_comment/Adding_global_abuse_filter_rights_to_global_sysops
response
<urn:uuid:6f785afa-d0c1-4730-9cb0-13f0dc1c1479>
isPartOf: CC-MAIN-2023-06
publisher: Common Crawl
description: Wide crawl of the web for January/February 2023
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-56
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/