Requests for Comment/CheckUser and Oversight
Jump to navigation
Jump to search
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- CheckUser and Oversight privileges are not going to be delegated currently. If this was a request for handling the relevant policies it would be useful to keep open. Since this is just a plain request to "delegate the rights" with no though behind the process or an appropriate use of the tools, this currently serves no purpose. John (talk) 18:44, 10 December 2016 (UTC)
Contents
CheckUser and Oversight[edit | edit source]
With Miraheze's new privacy policy close to its final stages of draft, I think I can address the use of the CheckUser (CU) extension and Oversight (OS). Currently, it is restricted to Stewards. This is something I strongly disagree with. As noted in the RFC on Stewards overall, I personally feel that wiki founders should have access to these tools, but be binded by regulations. Please share your thoughts on each of the following proposals. Please also explain your position when voting support or oppose.
details about the CheckUser extension can be found here:
details about Oversight:
- https://www.mediawiki.org/wiki/Help:RevisionDelete (same as Revdel except Sysops can't view what's been suppressed)
Proposal 1[edit | edit source]
These tools will remain limited to Stewards, even after the new privacy policy officially goes into effect.
Comments[edit | edit source]
Strong oppose Per the reasons for opening this RFC in the first place. Amanda (talk) 22:14, 7 December 2016 (UTC)
Comment I don't mean to be rude or come off as threatening, but I really don't think you understand these tools or what they are for. Neither tool is restricted to Stewards. If you view interwiki rights logs on this wiki, you will see that Stewards grant these rights to themselves as needed, and then immediately remove them when they are done (because the Steward role itself does not actually have any of these permissions you're talking about). These tools can be handed out indefinitely or permanently to anyone else for the same reason, but so far there has not been a demonstrable need for this. If a wiki became so large and has issues that it needed these features often, they would be handed out, but even All The Tropes (our largest wiki) has not ever requested access to these tools. There is no way to globally monitor CheckUser usage, so unless Stewards regularly viewed the CU log on every wiki, they would not even know that 'founders' are abusing the rights. Also, the founder user group does not exist on any wikis unless it has been requested, thus, to make any of the other proposals work, bureaucrats would have to be given the right by default. Also, why do you need oversight? Are you going to suppress every single log on your wiki after you duplicate mistakes or something? Currently Oversight is the highest-level of on-wiki removal, used only for private information or legal removals that non-global staff should never have access to. If you had access to oversight, then the only thing we could do is implement a new form of revision deletion you wouldn't have access to, which, no offense, I assume you would just complain about as well, or we would have to actually delete the information directly from the database (which can only be done by Operations members and is, for the most part, irreversible). Pup (talk) 22:35, 7 December 2016 (UTC)
- I actually don't need oversight - I'm just including it in this RFC since CU and OS are often linked together. Amanda (talk) 23:13, 7 December 2016 (UTC)
- CU and OS are completely different tools whose policies should not be based on each other just because they both require elevated rights. Also why do you think you need CheckUser? Pup (talk) 23:19, 7 December 2016 (UTC)
- I don't necessarily need it - but it may be helpful though. I'm very security-aware, and so chances are I would only use it on myself every month or so to make sure that there are no contribs from an IP which I don't recognize (suggesting a compromised account). However, I could also use it to prevent users who I have revoked read access from ("banned" them) from creating new CentralAuth accounts and then locally logging in. This would allow me to block their IP when banning to prevent evasion. Amanda (talk) 00:56, 8 December 2016 (UTC)
- @Amanda: IMO this is what 'hardblocking' is for. We usually only use checkuser to verify account ownership/access, like you mentioned (I checked your IP address before resetting your user account's password). It is also used to block spamming host IPs across all of Miraheze if multiple spambots (accounts) appear to be editing in the same way. This MediaWiki manual page indicates the ability to "Automatically block the last IP address used by this user, and any subsequent addresses they try to edit from (also called hardblocking)" which appears to be exactly what you want. Pup (talk) 01:50, 8 December 2016 (UTC)
- Imagine the following scenario, which would nullify all of the above:
- A user disrupts my wiki and gets blocked
- That user engages in sock puppetry
- All socks are blocked and the master account is banned (read revoked)
- Autoblocks are set with each block action
- However, the user does not switch IP's at all during this time frame
- I confirmed that autoblocks are 24 hours with the last block that I made
- After 24 hours are up, the IP is unblocked and they can create new accounts
- The cycle starts all over again.
- Great! This is where CU comes in handy - to block the user's IP long-term to prevent evasion.
- Honestly, at this point, I refuse to argue further. I have made my point - you have made yours. Let's see what the rest of the community has to say. Amanda (talk) 02:17, 8 December 2016 (UTC)
- Imagine the following scenario, which would nullify all of the above:
- @Amanda: IMO this is what 'hardblocking' is for. We usually only use checkuser to verify account ownership/access, like you mentioned (I checked your IP address before resetting your user account's password). It is also used to block spamming host IPs across all of Miraheze if multiple spambots (accounts) appear to be editing in the same way. This MediaWiki manual page indicates the ability to "Automatically block the last IP address used by this user, and any subsequent addresses they try to edit from (also called hardblocking)" which appears to be exactly what you want. Pup (talk) 01:50, 8 December 2016 (UTC)
- I don't necessarily need it - but it may be helpful though. I'm very security-aware, and so chances are I would only use it on myself every month or so to make sure that there are no contribs from an IP which I don't recognize (suggesting a compromised account). However, I could also use it to prevent users who I have revoked read access from ("banned" them) from creating new CentralAuth accounts and then locally logging in. This would allow me to block their IP when banning to prevent evasion. Amanda (talk) 00:56, 8 December 2016 (UTC)
- CU and OS are completely different tools whose policies should not be based on each other just because they both require elevated rights. Also why do you think you need CheckUser? Pup (talk) 23:19, 7 December 2016 (UTC)
- I actually don't need oversight - I'm just including it in this RFC since CU and OS are often linked together. Amanda (talk) 23:13, 7 December 2016 (UTC)
(reset indent) My point is don't the new accounts also get blocked (based on the original block, assuming the IP is the same)? and after a 24 hour autoblock expires, a new autoblock can be made against it if the original block is still in place? Feel free to indefinitely hardblock this account on that wiki, as I'm actually curious (and technically unaware). Pup (talk) 02:27, 8 December 2016 (UTC)
- Please make an edit or two first, as there will be no IP to autoblock if no edits have been made. Amanda (talk) 02:39, 8 December 2016 (UTC)
- Strong oppose I don't see any reason we'd need to limit this specifically to Stewards, especially given that Mediawiki-admins has de facto access here. Of course All The Tropes doesn't need access because I'm staff, but in practice when we see repeated abuse we hand that off to Miraheze stewards to deal with. I've never actually checkusered anyone. Labster (talk) 03:01, 8 December 2016 (UTC)
Proposal 2[edit | edit source]
These tools will be available to wiki founders once the new privacy policy is officially in effect, and such founders will be allowed to create local polices binding their use of the tools.
Comments[edit | edit source]
Weak support This is acceptable, but I would prefer to see proposal 3 instead. Amanda (talk) 22:14, 7 December 2016 (UTC)- Strong oppose Founders should not have the authority to create local policies regarding access to nonpublic information. Pup (talk) 22:35, 7 December 2016 (UTC)
- Strong oppose I think this proposal would very likely be illegal, unless maybe wikis were willing to each write their own privacy policies, which we would then need to be aware of? Sounds too complicated to get to the lowest bar of "legal" even. Labster (talk) 03:01, 8 December 2016 (UTC)
Per local policy is good for the wiki in wiki founder. It not legal, IT Office (talk) 10:08, 8 December 2016 (UTC)User blocked for vandalizing this and RfC and other pages Pup (talk) 12:50, 8 December 2016 (UTC)
- Even if I didn't just block you I'd still come here and say that I don't think most wiki founders actually understand the law regarding this. Like Labster said if we gave this access by default to anyone, all anyone would have to do with the Miraheze Single Login is open a wiki while logged in and then that founder could view the users IP address, which we usually consider PI. Also, there is no (reasonable) way to check if it is used. Pup (talk) 12:50, 8 December 2016 (UTC)
Proposal 3[edit | edit source]
These tools will be able to wiki founders once the new privacy policy is officially in effect, and such founders will be required to comply with the global polices that dictate Steward use already. Any local polices cannot conflict with the global ones.
Comments[edit | edit source]
Strong support Per comments above. Amanda (talk) 22:14, 7 December 2016 (UTC)
Oppose The pages (which FYI aren't in the Meta namespace) aren't official policies. Also, like mentioned in my comment on proposal one, there is no central log for use of these tools, so monitoring for abuse would be more or less impossible unless it was reported to us. Pup (talk) 22:35, 7 December 2016 (UTC)- Oppose There's been no particular argument in favor of this, but I'd be open to one if one were given. I used to feel like IPs were not fundamentally private information, because you send it out on literally every packet. But in the current world, it can be used to attack people who disagree with you directly. And so I'm not eager to give that access out to just anyone. And because of centralauth, people only have to view one page on the wiki, and founders automatically get a bunch of private data? No, that's not good at all. I'd like to think that we at Miraheze stand up for user privacy, and against these kind of threats to our users. That's why I've opposed all of the options on this page. because none seem to deal with the Mediawiki threat model, nor with the fact that hosted wikis don't have a common purpose like WMF wikis, and none of them protect user privacy. Labster (talk) 03:01, 8 December 2016 (UTC)
- The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section
