Wikipedia talk:Village pump (proposals)/suspend sysop rights of inactive admins

It occurs to me that the discussion has been purely about administrators, but the same argument applies to other high-value user groups as well. Some of them also have a particular risk from "silent abuse" (using privileges without leaving any visible sign of damage). Rd232 ^talk 00:42, 10 June 2011 (UTC)[reply]

This is already done for checkusers and oversight. See Wikipedia:Arbitration Committee/Noticeboard/Archive 3#Standard operating procedure: CheckUser and Oversight. --RL0919 (talk) 00:59, 10 June 2011 (UTC)[reply]

Interesting. How is that monitored? Rd232 ^talk 01:06, 10 June 2011 (UTC)[reply]

Since ArbCom controls these rights and there are only a small number of users with them, my assumption would be that an arb periodically checks the logs for activity. If this passes, it will leave crats (another small user group) as the odd ones out among advanced permissions, but that is probably best handled later rather than muddying the issue in the middle of the RfC. --RL0919 (talk) 01:13, 10 June 2011 (UTC)[reply]

Yes. And the minimum activity levels were recently tightened up - see

Wikipedia:Arbitration Committee/Audit Subcommittee/Statistics (diligently maintained by Avraham (talk · contribs)). –xeno^talk 15:20, 10 June 2011 (UTC)[reply

]

Comment: Nuujinn above touched on a point that hasn't been brought into this discussion thus far, and should radically change the balance of costs and benefits when the implications are fully considered. Admins have Viewdelete rights (that is, the ability to access deleted material). It is long established as Foundation policy that only those who have gone through the relative rigours of RFA may access deleted material (for legal reasons, I think - perhaps someone could confirm). The assumption of all in this discussion thus far (including me) has been that the sole risk of hijacking of an admin account is damage. Introducing the role of Viewdelete rights casts this in a very, very different light. An attacker may silently view unknown amounts of deleted material, potentially putting it to all sorts of uses - without their presence being known. This aspect raises the stakes for all aspects of the security being debated, including the suspension of sysop rights, but also of other measures discussed in the section below. Rd232 ^talk 13:57, 2 June 2011 (UTC)[reply]

• I considered that above, and there's really no way to deal with this. I could have my account compromised, and no edits/logged actions made. The "hacker" could simply use it to read deleted pages and no one would be the wiser. (I don't think CU can check to see the IPs where I log in only, without editing.) So desysopping doesn't necessarily solve this—as long as there is one admin account with a weak password, all deleted revisions are susceptible. One way of solving this is for MediaWiki to a) not allow weak/short passwords and b) send an email every time someone puts in the wrong password, say, 3+ times for an account. /ƒETCHCOMMS/ 23:01, 2 June 2011 (UTC)[reply]

  Would it not be possible, hypothetically, for viewing deleted revisions to be a logged action visible to Oversighters or Checkusers? ╟─TreasuryTag►Woolsack─╢ 23:04, 2 June 2011 (UTC)[reply]

  That would require logging the pages that individual users view. It could be done, but I don't know that everyone would be too fond of the idea. There would be very little standing between these volunteers and your browsing information. ▫ JohnnyMrNinja 00:40, 3 June 2011 (UTC)[reply]

  We shouldn't discount the possibility that a disaffected admin could have sold on his account details.  —SMALLJIM  14:16, 4 June 2011 (UTC)[reply]

  I already pointed that out above. --Tothwolf (talk) 18:20, 4 June 2011 (UTC)[reply]

  • Is the bundled viewdeleted bit even that big of a deal? Sensitive things should be oversighted, not revdeleted, otherwise why bother even having the oversight permission bit and all the extra steps required to hold it?

    Perhaps we should consider something along the lines of the system which Gmail has in place? It logs the IP addresses of those who login or attempt to login to an account and that history is maintained for a set amount of time. The access history is visible to the person who operates the account and IP addresses which are out of the ordinary for the history of the account are listed differently. This type of information could even be combined with an email notification to the email address linked to a particular Wikipedia account. --Tothwolf (talk) 18:33, 4 June 2011 (UTC)[reply]

    • Yes it's a big deal. "Sensitive things should be oversighted, not revdeleted, otherwise why bother even having the oversight permission bit" - sorry, that's just ignorance of the history. Oversight has been around a lot longer;
      RevisionDeletion opens up a similar, more accountable and transparent version of oversight to all admins, leaving the old oversight tool for only the most sensitive cases. In addition, oversight is a red herring for pages where the entire content is deleted (AFAIK oversight is rarely used in that instance). Bottom line, repeated proposals to unbundle viewdelete rights have always foundered on the Foundation's requirement that the rights be kept limited - because otherwise, if too many people can see it, the material is arguably not really deleted, with potential legal consequences. Rd232 ^talk 17:38, 5 June 2011 (UTC)[reply
      ]
      • Hey Tothwolf, I thought the same thing before (see Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted). I was so confident that I emailed the WMF's legal council who immediately torpedoed the whole thing and told us what a bad idea it was. It was going fairly well up to that point... ▫ JohnnyMrNinja 17:43, 5 June 2011 (UTC)[reply]
        • If we ever have reason enough to do this, we could always separate the copyvios from everything else... --Tothwolf (talk) 05:19, 6 June 2011 (UTC)[reply]
        • While unrelated to this discussion, I've actually thought of a way we could make this work. --Tothwolf (talk) 06:55, 13 June 2011 (UTC)[reply]
      • Sorry but I'm not buying it. Sensitive material should be oversighted and not simply revdeleted. Anything else (revdeleted vandalism, copyvios, deleted articles, etc) are not that sensitive and are not sufficient for justification for the proposal to remove the admin bit from inactive admins. Besides, as pointed out above, even if someone breached an account which had the admin bit removed, the person who breached the account could as easily just ask for the admin bit back and they could then see revdeleted material anyway. We have a separate election and special requirements for those that hold the oversight permission for a reason. --Tothwolf (talk) 05:17, 6 June 2011 (UTC)[reply]

Incidentally, the actual user right is called "deletedhistory" [1] - I misremembered it. Rd232 ^talk 18:17, 5 June 2011 (UTC)[reply]

I thought a brief summary of the issue might be helpful - cf

WP:Viewdelete. Rd232 ^talk 18:33, 5 June 2011 (UTC)[reply

]

FYI the bundle normally referred to as "viewdeleted" contains three separate rights: deletedhistory, browsearchive, and deletedtext. Only the last one allows you to actually view the deleted revisions. –xeno^talk 15:27, 8 June 2011 (UTC)[reply]

Thanks. I've updated

Wikipedia:Viewing deleted articles to match. Rd232 ^talk 17:15, 8 June 2011 (UTC)[reply

]

Wikipedia:Village_pump_(proposals)/Account_security#Limit_viewdeleted_rights_for_admin_accounts. Rd232 ^talk 11:52, 9 June 2011 (UTC)[reply]

If I understand correctly, a hacker could also exploit the account of an active admin to view "deletedhistory". The only way the admin would know someone is borrowing their account to view deleted material would be that they get logged out for no apparent reason.   Will Beback  talk  00:26, 10 June 2011 (UTC)[reply]

True. If you have any suggestions for tackling that, take them to the RFC. I suspect solutions which are practical (for active admin accounts) will not be easy to come by. Deactivating inactive accounts is "low hanging fruit" - pretty easy, but not a panacea. Rd232 ^talk 08:59, 10 June 2011 (UTC)[reply]

Admin account verification and admin know-how

There are two issues.

Long term inactive admin accounts are not really a problem based on whether or not to desysop. The problem is confirming that the account holder is legitimate after a long absence, and this is so whether or not the account retained the bit in between. Whether they remain a sysop while inactive, or didn;t keep the bit but request its restoration on reactivating, the question is still how to verify the user is the same person who should own the account. This also helps a lot on hijacked account cases too.

Proposal - that the following is added to policy:

Administrator accounts are to be used only by the individual to whom adminship was granted. In circumstances giving rise to concern, the account owner may be asked to verify that they are the legitimate owner of the account. This does not imply any personal identification, rather it implies knowing something that only the original owner would be likely to know. Administrators unable to verify their legitimacy to the community or Arbcom may be required by clear consensus or bureaucrat discussion to reconfirm their RFA. Administrators are therefore advised to ensure that they have a means to verify their account ownership. Suggested methods include: A word, string of characters, or other text known only to the user, submitted to Arbcom or a willing member of the Foundation to be held by them. A committed identity string on their user page or (more secure) sent to Arbcom

With regard to out of date knowledge the issues are - how long does it take for admins to get out of date? Can active admins be out of date as well? Should all admins be required to demonstrate up to date know-how in some way, every 5 years?

FT2 ^{(Talk | email)} 18:39, 1 June 2011 (UTC)[reply]

In my opinion, I don't think we need a fancy way. The discussion above concluded that BN isn't going to be flooded with requests, they'll be quite rare (if at all). So, when one goes to the effort of posting there, you're going to be noticed. And checked. Quite apart from the actual message you leave, it wouldn't be difficult to keep these people "on the radar" for a while. On the second point, it sort of follows that because someone's checking, then they can be referred to an appropriate venue if their timeout is affecting the project, and their ability to use the mop.Grandiose (me, talk, contribs) 18:56, 1 June 2011 (UTC)[reply]

"You're going to be noticed. And checked." Checked how? This point is about making sure we can check, encouraging admins to take measures to ensure their account ownership is verifiable (which is a good thing anyway), and ensuring users are aware that if ownership can't be verified a reconfirmation RFA could be needed as the result of

WP:BN discussion. FT2 ^{(Talk | email)} 19:30, 1 June 2011 (UTC)[reply

]

Checked by observing behaviour. Anything else is, for this type of internet account, just a false sense of security. Rd232 ^talk 20:07, 1 June 2011 (UTC)[reply]

In observing behavoir the biggest hint will be the post to BN. Posting on BN is the least likely thing a person in control of an account would do, and with good reason. It flags them up for special treatment, people notice they're around again, the records will be checked at that instance, and there will be some sort of blurb about the fact they've come up to trip up on. It's also got a deterrent effect. Grandiose (me, talk, contribs) 21:35, 1 June 2011 (UTC)[reply]

We could simply require all admins to send a

If anything committed identities are weaker than passwords. Prodego ^talk 19:08, 1 June 2011 (UTC)[reply]

That seems like (a) hassle and (b) an extra point of security failure, both in terms of having a list that might be misused (and then falsely trusted, because it's "verified"), and in terms of admins losing the relevant data and not being able to get back. At the same time, the risk of admins losing that data raises the possibility of exceptions being made in practice even if theoretically excluded ("I lost my data"), and that possibility might be exploited by a hijacker. Rd232 ^talk 20:05, 1 June 2011 (UTC)[reply]

Unnecessary attempt to fix a problem that doesn't exist. When we have one restoration of rights to a bad user, then we can try to fix the problem. In the meantime, crats are picked for good judgement and if something looks dodgy they can ask questions. No crat can be compelled to do anything they think unwise.--Scott Mac 17:23, 2 June 2011 (UTC)[reply]

I have seen a lot of editors say that this is a problem looking for a solution. Well, that's partly true, that's the nature of preventative maintenance; to stop problems before they become problems. We shouldn't wait until a traffic accident to buy insurance, we shouldn't wait to build a crosswalk until someone gets hit by a car and we shouldn't wait to remove an unused and uneeded permission from an unused account. It has happened and eventually it will happen again, if it hasn't already and just hasn't been noticed. Aside from that it also removes them from associated things like AWB which if used by a rogue could do a lot of damage in a short time. It also removes the privilage so that if someone goes looking for a helpful admin they aren't distracted by one that's been gone since 2006. As was mentioned before if they have been gone for a year their probably not coming back and if they do they can just ask for it back. One last bit of reasoning to do this is that if they are gone for a year a lot of rules have changed and if they just jump back in the saddle one day they could unwittingly mess up something that changed months ago. --

talk) 03:50, 3 June 2011 (UTC)[reply

]

I think you are in the wrong section. I've supported suspending after a year. I'm questioning the need for form-filling additional checks before restoring.--Scott Mac 16:38, 4 June 2011 (UTC)[reply]

Touched field

FYI: the mw:User table stores the timestamp from the last time that a user has performed any action, including logging in. I mention this because there is some discussion here about knowing what the "real count of admins" is, along with all of the other stuff. It would be fairly easy to create an extension which would use this data in some useful manner (or even add to it). I'm fairly certain that there's already an extension or two that does something along the lines of what is being sought for, here. There's no need to recreate the wheel, here. :)
— V = IR (Talk • Contribs) 13:48, 4 June 2011 (UTC)[reply]

As there were no responses here, I brought it here to VPT. With this functionality we would be able to judge by login rather than edits, which is certainly preferable. ▫ JohnnyMrNinja 16:46, 10 June 2011 (UTC)[reply]

Consensus

This has been open over a week now, and with 59 supports and 14 opposes (that I could see) this is pretty much clear consensus to implement (I have voted here though, so am biased). Only 10 years too late! :-) Can someone uninvolve close? How are we going to do this? AD 18:34, 8 June 2011 (UTC)[reply]

IMO, as an RFC-style discussion, the usual period of 30 days should be allowed. –

xeno^talk 19:22, 8 June 2011 (UTC)[reply

]

Yea, there's no rush. We should talk about implementation details first as well. Bureaucrats are going to be the ones taking on the workload here right? It'd be nice to see some "as a Bureaucrat I think it would be best to..." comments here, since we're apparently trying to tell them how to do their work here.
— V = IR (Talk • Contribs) 19:30, 8 June 2011 (UTC)[reply]

OK agree with leaving it open longer, but bureaucrats won't be having any workload at all - it'll be stewards doing the actual deadminning. If an inactive admin meets the criteria, any person should be able to request removal of rights on Meta. (And stewards aren't bothered about workload - loads of projects remove inactive admins). AD 21:17, 8 June 2011 (UTC)[reply]

If the proposal carries, I think a less chaotic method should be used than "just anyone post to

WP:RESYSOP. –xeno^talk 12:39, 9 June 2011 (UTC)[reply

]

Agreed. Also it shouldn't be done on meta anyway. Probably a regular bot sweep would be the simplest (it could probably do warning emails automatically, and maintain a list of those who still haven't edited a month after warning, and bureaucrats can respond to the list as and when). Rd232 ^talk 13:12, 9 June 2011 (UTC)[reply]

Well, even if bureaucrats were given the task of reviewing and verifying the lists, the actual removal requests would eventually have to make their way over to m:SRP - at present, Stewards are the only ones with the technical ability to remove the sysop userright (well, developers too, but they only act on userrights in exceedingly rare cases). –xeno^talk 13:38, 9 June 2011 (UTC)[reply]

Oh, I'd forgotten that. Bloody silly if you ask me. Wasn't there an RFC about giving bureaucrats the technical ability to desysop, to be used solely at specific direction of the community? If this proposal is adopted, I think it should be revisited. Rd232 ^talk 17:43, 9 June 2011 (UTC)[reply]

I think the most recent discussion was Wikipedia:Requests for adminship/Bureaucrat Unchecking (see also /Poll). Not sure where it went from there (if anywhere). –xeno^talk 17:52, 9 June 2011 (UTC)[reply]

If we're going to keep this open for several more weeks, maybe we should move it to a subpage? Rd232 ^talk 13:12, 9 June 2011 (UTC)[reply]

Not a bad idea. –xeno^talk 13:38, 9 June 2011 (UTC)[reply]

• And the strengths of the opposition? Not really any. Point is, deadminning inactive admins is going to help improve security, whether a little bit or a lot. The fact that it is a perennial proposal only means that it has been proposed a lot. This time, thankfully, so far
  consensus has changed
  in favour of implementing a deadminning process.
• You can try and claim that it is in the best interests to keep inactive admins forever, long after they're dead etc, but the many points raised by supporters ultimately show this is a good idea. As I already mentioned, it's only an accident that a desysopping procedure wasn't put in place originally - because it wasn't anticipated Wikipedia would last this long. Now it's become necessary. AD 21:38, 9 June 2011 (UTC)[reply]

I could not disagree more. There is no reason to oppose this proposal just because it hasn't been done before. Every idea in

WP:PEREN is not a suicide pact." We have no business dismissing an idea just because it has been dismissed before. Not a single oppose opinion has provided a legitimate reason that this proposal should not be implemented. It has been pointed out by many people that removal of permissions is a standard best practice in IT security. The only valid argument I have seen against this idea is that it may not improve security. There has been no proof provided for this, merely some vague idea that inactive accounts are less likely to be targets of abuse. Not one opposer has put forth a negative result of this proposal (although one editor has made a speculation that: a) a returning suspended admin may be offended by the mere idea of their suspension; and b) said prospective admin may be so offended that they would choose to no longer contribute at all). The proposal is minor, and puts a desperately needed policy in place where currently there is none at all. I will attempt to be just as blunt in this response - We have no policy that says adminship is permanent. That means it is not. This proposal would create a policy where there is currently a vacuum. There has not been a single good reason to oppose, and every oppose that amounts to "but that's the way we've always done it" should be completely disregarded by whoever closes this RfC. Jim Miller ^{See me | Touch me} 22:01, 9 June 2011 (UTC)[reply

]

I skimmed your wall. Basically, it's up to people proposing things to prove that it will help. I agree with Mr. Z-man and Tothwolf. This proposal seems to be based on little evidence that it will help anything that a few minutes of cleanup can't fix right now. Also, I think most people view PEREN topics as a graveyard, yes. Killiondude (talk) 22:16, 9 June 2011 (UTC)[reply

]

Well 80% of the audience has disagreed with you, and there are substantial arguments to do with security that haven't really been adequately tackled, for example the ability to view deleted content, or the fact that admins get a lot of slack as long as they don't become too visible, or the possibility of selling accounts, all of which haven't really been tackled. -- Eraserhead1 <talk> 23:50, 9 June 2011 (UTC)[reply]

Obviously we must take

someone is capable of judging admin-related consensus on their own? —WFC— 00:31, 10 June 2011 (UTC)[reply

]

A simple equation The risk we're trying to mitigate is that to Wikipedia, i.e. the risk of any admin account being breached.

Define: A = number of active admin accounts, I = number of inactive admin accounts (definition of inactivity doesn't matter for the logic, but let's say no edits for 1 year, as per proposal)
Define: S1 = insecurity of active accounts (0-1 variable, probability of breach: 0=perfect security, 1=complete insecurity), S2 insecurity of inactive accounts. Then

Risk of any admin account being breached = (A * S1) + (I * S2)

For there to be zero benefit from the proposal, either I needs to be zero (no inactive admin accounts), or S2 needs to be zero (i.e. inactive accounts have perfect security). Clearly neither is true, and therefore the proposal has security benefits, by reducing I to zero.

Quod erat demonstrandum. Rd232 ^talk 00:23, 10 June 2011 (UTC)[reply

]

• Lies, damned lies, and statistics. --Tothwolf (talk) 01:56, 10 June 2011 (UTC)[reply]
  • <facepalm> This equation does not fall into the domain of statistics. It is about logic. Rd232 ^talk 08:38, 10 June 2011 (UTC)[reply]
    • <grin> Same difference. If you want to get more accurate, the equation is a
      logical fallacy. Lies, damned lies, and statistics is more generally about the "persuasive power of numbers", so not just statistics. The use of an equation to make this argument here would be the same type of thing. Both equations and statistics are going to be outside of most editors' area of knowledge, but both can "look" impressive. --Tothwolf (talk) 06:56, 13 June 2011 (UTC)[reply
      ]

You're neglecting the underlying assumption, which is that once an account is desysopped, it will stay that way. That is, that this proposal will result in a meaningful reduction in I. A) It sets an arbitrary cutoff for "inactive." An account that hasn't edited in 6 months is just as theoretically vulnerable as one that hasn't edited in 12. I is not reduced to zero. But more importantly, B) By setting too simple of a method to get admin rights back, all it's doing is replacing "inactive admin accounts" with "accounts that could become admins with a single edit." Mr.Z-man 02:59, 10 June 2011 (UTC)[reply]

a) yes, "inactive" requires a definition for the equation to work. But the equation is correct for any definition of "inactive". And "just as theoretically vulnerable" is irrelevant; it's not necessary for S1 and S2 to have any particular values - the only requirement is for S2 to be non-zero. b) that is a problem, and it is why (way, way up the page) my support for the proposal is conditional on admin rights not being returned with a single edit, but instead on request after a month's "reasonable activity" (to be judged by the bureaucrats). PS Though requiring even a single edit would have security benefits if Wikipedia:Village_pump_(proposals)/Account_security#Notify_users_after_renewed_activity is turned on in combination with Wikipedia:Village_pump_(proposals)/Account_security#Notify_of_removal_of_verified_email_address: it would ensure an email is sent to the legitimate account holder, who is the person best placed to detect hijacking. PPS requiring verified emails and annually reverifying would also help. Rd232 ^talk 08:38, 10 June 2011 (UTC)[reply]

I agree that if we're going to do this we should have a more stringent system for returning rights. But this proposal as written does not have a sufficiently stringent system, so I guess I'm confused as to why you're trying to convince people to support it. This isn't a proposal for a general idea, it's for a specific wording to be added to policy. The email verification thing adds a pretty weak layer of security, since it also relies on a lot of assumptions. Namely that the actual account owner receives the email (it isn't on an account he no longer uses, which is a big assumption since many users have separate email accounts for wiki usage) and acts on it before a bureaucrat restores the rights. And even then, the actual owner has to somehow prove that he owns the account. Unless they have some alternate method of verification, it's the person who can actually access the account (the hacker) vs. some random new user claiming to be the owner (the actual owner). Mr.Z-man 21:20, 10 June 2011 (UTC)[reply]

Well to answer the first question, I think the issue is big enough to treat this as merely being about the principle - which has long been rejected. I'd anticipate a further discussion of implementation, in which the need for a certain caution in returning rights would be the key focus, because of its centrality to achieving the proposal's stated objectives. As to the other stuff - there are various email-related proposals in the account RFC which would all work together to make email a stronger (though still imperfect) hook to hang verification on, including some thoughts on how an owner could reclaim his account from a hijacker. But at the end of the day, it does need some caution in returning rights, or its pointless and possibly even dangerous. There are various ways it could be done. For instance, if there's some way to access a user's verified email address, this could be stored at time of deactivation, and then in order for rights to be restored easily, an email required from that stored address. If that "easy" route is not possible, then require something harder, like a month of "reasonable activity". But this is a whole other discussion, which will involve some detail, and that's basically why I strongly support this proposal conditional on there being reasonably effective safeguards to stop a hijacker getting into an inactive account and easily reactivating it. Rd232 ^talk 21:52, 10 June 2011 (UTC)[reply]

I'd like to see an additional discussion as well. But given the section above, I wouldn't count on it. Mr.Z-man 00:06, 11 June 2011 (UTC)[reply]

I think requiring a month of reasonable activity is probably a good idea, but I think requiring a post at the bureaucrat's noticeboard is better than nothing - and I think the frequency of re-permissions requesting will actually be extremely low so that lots of attention will be able to be paid to those people who are re-requesting their permissions.

I would suggest requiring a month of reasonable contributions after this has been implemented with no such requirement. -- Eraserhead1 <talk> 08:20, 11 June 2011 (UTC)[reply]

Lots of attention will be paid, for a few days until something else happens and most people lose interest. In the meantime the hijacked account is making a few non-controversial actions in public while in private he's harvesting pages of deleted content. The sockpuppet Archtransit kept us fooled for almost 7 months, and he was an admin for more than a month. The idea that behavior alone will be enough to catch hijacked accounts quickly is simply false. And if they just want to use the account to cause some quick damage, it doesn't really matter if people are watching them; we can't see what someone is going to do until after they do it. Requiring a month of editing or better, a reconfirmation RFA, isn't a perfect deterrent, but it's infinitely better than a post to BN. I still don't understand the argument that if someone is going to take the trouble to hijack or buy an admin account, that the fact that they have to make a single edit will somehow be a deterrent. It's like saying that putting a piece of tape over a lock will prevent someone from picking it. Mr.Z-man 13:07, 11 June 2011 (UTC)[reply]

I agree, on its own a request at BN has very low security value. If that's all we're doing, we might as well not bother with desysopping, and just bot-notify

WP:BN about admin returns after long absence. The only difference between the two is that a BN request might make it very marginally more likely that a legitimate owner of a hijacked account would notice the hijacking. The security benefits of this are just too low; if we're taking the issue seriously enough to overturn the long tradition of not desysopping inactive admins, then we ought to take it seriously enough to follow through on the logic. Rd232 ^talk 15:09, 11 June 2011 (UTC)[reply

]

I don't agree, I think the idea of requiring a month of editing is a good one, and I'd like to see that implemented, however if the person closing this discussion doesn't think there is a consensus for that even requiring a post at the bureaucrat's noticeboard is significantly better than our current position. -- Eraserhead1 <talk> 22:09, 11 June 2011 (UTC)[reply]

How is it better? I've argued several times now that it isn't, and possibly could be worse (by having the same level of security, with a false sense of security). I don't think I've seen any reasoning as to how it actually improves security. Mr.Z-man 03:51, 12 June 2011 (UTC)[reply]

Moves the fruit higher up the tree. Calls attention to the return of a long-dormant admin account. Prevents a would-be usurper from using the admin account to silently harvest deleted revision data. –

xeno^talk 04:44, 12 June 2011 (UTC)[reply

]

Because it gets people used to the idea that admins don't keep their rights forever, because it requires the scammer to know they have to go to the bureaucrat's noticeboard, and because they have to make themselves publicly known, which scammers generally want to avoid.

If everything is treated as all or nothing no progress is likely to be made, we can bring up the second point later if it doesn't "pass" this time. -- Eraserhead1 <talk> 08:57, 12 June 2011 (UTC)[reply]

I'll agree it's a step in the right direction, particularly looking at it overall and not just from the security point of view. From the security point of view, though, it's a much smaller step in the right direction than I think we should be satisfied with. Rd232 ^talk 11:48, 12 June 2011 (UTC)[reply]

"admins don't keep their rights forever" - If there's no practically significant barrier for return, then for all intents and purposes they still do. We technically flip the switch off, but they can get access to the tools in a couple hours if they return.

"it requires the scammer to know" - If someone is going to exert the significant effort required to hack an admin account, I would presume that they already have some sort of a plan for it and have at least a passing familiarity with Wikipedia administration. Since all policies are public, this is like

security by obscurity

without actually obscuring anything.

"they have to make themselves publicly known" - See my comment at 13:07 for reasons why this is rather weak.

Personally I think the argument that a returning admin will be out of touch with current practices is a much better argument than the mostly hypothetical security one. The situation there is not improved in the slightest if they can get the tools back immediately upon return. Mr.Z-man 13:37, 12 June 2011 (UTC)[reply]

Security through obscurity may not be the greatest ever security policy, but it does make users safer. Mac users are safer than Windows users, even though Windows is more secure, and safety is the key thing we want. There is also a substantial range between posting racist statements and just keeping your head down, which while a highly skilled hacker wouldn't be fooled, someone in between the two extremes might find a more serious barrier.

Additionally some level of checks can be made, such as checking the users writing style, or doing a checkuser to check they are in the same country as they were before.

With regards to making sure they still understand policy, I'd have thought making them step forward would be key for that purpose, as it means we know who they are and can give them advice/mentoring easily by watching for posts on the bureaucrats noticeboard. Giving that advice would be much harder if they don't have to step forward to regain their rights. -- Eraserhead1 <talk> 16:07, 12 June 2011 (UTC)[reply]

Checkuser data is only held for three months, and any discrepancies wouldn't prove anything anyway. Rd232 ^talk 16:20, 12 June 2011 (UTC)[reply]

Fair enough on the checkuser data, but I'd still say something like an originally US based admin logging in from India for the first time in over a year would be very suspicious. -- Eraserhead1 <talk> 16:33, 12 June 2011 (UTC)[reply]

Checkuser also isn't going to help us with login data. I would actually support the addition of both login and watchlist RSS feed access data to the data collected for checkuser. There are many sockpuppet operators who monitor the watchlists of their sockpuppet accounts via RSS and this data would allow us to unmask a lot of them. --Tothwolf (talk) 07:06, 13 June 2011 (UTC)[reply]

"Security through obscurity may not be the greatest ever security policy, but it does make users safer." Uhm, what?

This isn't even security through obscurity, this is more three wise monkeys "nope, no security issues here, none at all".

"Mac users are safer than Windows users [...]" Now that is an urban legend... Going back to Mac OS 7 and 8, computer virus infection rates of Mac computers were actually higher than PCs, because Macs often didn't have any sort of anti-virus software installed. As for more modern Mac malware, well... New Mac Malware Fools Customers, But Threat Still Relatively Small --Tothwolf (talk) 07:04, 13 June 2011 (UTC)[reply]

I have no idea about pre OS X, but with OS X there is now one bit of social engineering software, vs how much for Windows? -- Eraserhead1 <talk> 07:15, 13 June 2011 (UTC)[reply]

Back in the days of Mac OS 7, you wanted to write protect a floppy disk before putting it into an unknown machine, otherwise you had a 50/50 chance or worse of picking up a virus on the disk. OS X certainly improved things some, but it isn't foolproof either. My point was, both Macs and PCs have their faults, just in different ways, so you really can't say that one is more secure than the other. A lot of people used to think they were safer because they used a Mac instead of a PC (hence feeling they needed no anti-virus software), but this was just an example of a false sense of security. --Tothwolf (talk) 08:26, 14 June 2011 (UTC)[reply]

Without a shadow of a doubt both have security issues, but that doesn't mean that running a Mac isn't generally safer than running Windows. I agree with you that we aren't significantly increasing the security if we don't have stricter criteria, as there is still a large gaping hole if you push it, but we are increasing safety and will reduce the risk of problems - that in itself is worthwhile. Certainly I will be proposing to require waiting a month before reapplying the rights or something else that's similar if it doesn't pass this time in the next 6 months. -- Eraserhead1 <talk> 18:08, 14 June 2011 (UTC)[reply]

Half-serious proposal

Why not just block all editors who have been inactive for over two years? That would solve the security problem on the editing side.

A compromised admin account has the tools to unblock themselves.--SPhilbrickT 17:29, 23 June 2011 (UTC)[reply]

Not unless MediaWiki has been changed back to the old behaviour? --Tothwolf (talk) 01:25, 24 June 2011 (UTC)[reply]

I'll respond to the serious half there: because that'd be incredibly rude. Coming back from military service, or dealing with a late family member's estate, to find you have been blocked for being gone. Temporary suppression of rights is not in itself offensive, a block is a slap in the face that stays on your log. To respond to the not-serious half, if you're talking about mass-blocking regular editors, blocking all active editors would be far more productive. Our featured articles would stay perfect forever! ▫ JohnnyMrNinja 01:49, 24 June 2011 (UTC)[reply]

Recently retired admins

I just wanted to plonk down a related idea here before I forget it again: recently retired admins are another low-hanging fruit, and the same approach could be taken as with admins inactive for a year. So once an admin has been retired a month, give them a month notice of suspension of rights, then do it (on the same basis as long-term inactive, i.e. no prejudice to returning). This means a handful fewer accounts being available to be compromised (since months 2-12 after retirement would have the inactive account with admin rights under the current proposal, and with this they wouldn't). We needn't worry about this right now, but it seems a simple little addition if we're implementing the current proposal.

Sounds reasonable enough. -- Eraserhead1 <talk> 15:09, 26 June 2011 (UTC)[reply]

• Frankly, were such a proposal brought about I would have opposed it, because sometimes
  retire" for periods of perhaps even more than a month or so in order to get away from the usual stress and/or WikiDrama that occurs often within the encyclopedia, sort of as a cooldown measure. But if this issue were to be brought up I suggest it be lumped with the proposal above to remove inactive bureaucrats as well, so that we don't have several different RfCs covering practically similar issues to this proposal. TeleComNasSprVen (talk • contribs) 16:46, 27 June 2011 (UTC)[reply
  ]

Bearing that in mind, and noting that there are 252 Admins who will need to be warned about the measures and potentially desysoped in the near future and another 100 who will need some kind of warning that they've reached the half-way mark, it seems prudent to give the stewards a buzz now, or at least discuss implementation (as in the need for any bots, the warning-desysop timeframe, 25%/half way email warnings etc) . Thoughts? Bob House 884 (talk) 18:45, 21 June 2011 (UTC)[reply]

I think we can wait a week until its closed. -- Eraserhead1 <talk> 18:58, 21 June 2011 (UTC)[reply]

• Looking at the current results of this page, though, there appears to be a significant consensus at least for the concept/principle of removing the sysop bits from inactive administrators, but there is too much of a mishmash of differing opinions on how it's going to be implemented to tell accurately how the community as a whole wants to bring about the change. Many people have suggested redefining the threshold for inactivity as from as low as six months to as long as two years, and already they've also asked changes be made to the email system which is supposed to alert the administrators of their inactivity. TeleComNasSprVen (talk • contribs) 16:52, 27 June 2011 (UTC)[reply]
  • I presume that the closing administrator will be able to close it sensibly, if a little conservatively, and we can then have a further RFC in three to six months to deal with some more of the details. -- Eraserhead1 <talk> 17:30, 27 June 2011 (UTC)[reply]
    • Relatively few participants have supported a time period other than the year specified in the main proposal, and some of those were just voicing a preference, not conditioning their support on it. So the consensus for desysopping after a year of inactivity seems overwhelming. Nor is there a great deal of debate over the mechanics of notification. The proposal provides for ample notification, and nothing forbids the actual implementation from including even more (discretionary) notification just to be conservative. A closing admin who doesn't find consensus around those points had best provide a convincing explanation of why. The greatest disputation seems to be over the process of "reactivation" for a desysopped user who subsequently returns. This is where the proposal makes the least change from current practice, and it's also the last element that would have to be implemented in practice (assuming it ever happens). --RL0919 (talk) 21:45, 27 June 2011 (UTC)[reply]
      • The first step is building the list, and deciding who will contact them and how. Also, what about the (2, I think) crats that will be on the list? Should we let the other crats decide? I believe the general agreement was a notification one month in advance for rights removal. Also, the general consensus was that we give back rights if asked for. We should go with that for now, send the emails, and then we have at least a month if anyone wants to debate specifics of reinstatement. Better to get the doable part done than to set up another RFC before this one is even implemented. ▫ JohnnyMrNinja 01:59, 28 June 2011 (UTC)[reply]
        • There should be some sort of bot to automatically notify affected admins. To me, that's the fairest and most expedient method. It could be that this notification prompts a few inactive people to come back and get back into the swing of things. If someone wants to keep the tools, then all they have to do is make an edit and the message could even include a link to something saying "if you wish to remain active and keep your tools, please add your username to the list (link)". Then you'd know not only who wants to remain active but also get the required edit with the same process. Night Ranger (talk) 01:41, 29 June 2011 (UTC)[reply]
          • I think that an email and a talk page message should be left, and if they wish to keep their rights they should simply make one edit, anywhere, including just responding to the notice on their talk page. If a bot is running this, then the bot should see if any of these editors make any edits, as they will no longer be "inactive". ▫ JohnnyMrNinja 13:21, 30 June 2011 (UTC)[reply]
• Should the proposal be carried, I would suggest that implementation be initially staggered, so as to not overwhelm the Stewards (as much). For example: the first batch request would be for those administrators inactive since 2008 or prior (~117 according to
  WP:LOA/I); a month later, those inactive since 2009 (~75); and finally anyone who then meets the criteria from 2010 (~65 thru June). And then gong forward, requests would be submitted monthly or quarterly. –xeno^talk 13:25, 30 June 2011 (UTC)[reply
  ]
  • There's no race to desysop people as quickly as possible, so breaking the work into groups for convenience seems like a very reasonable idea. --RL0919 (talk) 13:38, 30 June 2011 (UTC)[reply]