Wikipedia talk:Demoting inactive admins

• What I like about this is that it allows for smaller chance for powerful accounts being compromised (it happens when passwords are sent over a non-secure protocol). Additionally, it's the closest thing to reconfirmation, so why not? ★MESSEDROCKER★ 11:38, 18 December 2006 (UTC)

• It's not a disaster if a sysop or bureaucrat account gets compromised, it's just a nuisance. We developers can respond rapidly to disable a compromised account with any level of access, although as far as I'm aware, this has never been necessary. Active accounts are far more likely to be compromised than inactive accounts. Demoting a respected and trusted member of the community who is temporarily inactive may be considered disrespectful. For these reasons, I would recommend only demoting users after significantly longer than the proposed time periods, if at all. -- Tim Starling 11:58, 18 December 2006 (UTC)

• • If the sysop/bureaucrat acknowledge s/he may go on a wikibreak, where is the issue? The account would be declared on break, come back and continue to do as before the break. I don't see this disrespectful at all, if anything this shows that the sysop/bureaucrat is showing some bit of accountability; not just disappearing and may never return. Sysops and bureaucrats serve the community, not themselves and this is something that everyone needs to understand; otherwise what is the point of having the tools? While it is a comfort that you can revert it quickly; isn't the point of security and not getting compromised being prepared to prevent it? While you are correct that the most likely situation would be an active account, the active user is generally monitoring his contributions, watchlist, and would pick up on an issue with sneaky changes; and rapid destruction would be stopped by you guys. An active user also needs his tools, an inactive user does not; and this is why I proposed such a policy be brought into discussion. An inactive user could easily avoid the need for an RfA, by simply declaring wikibreak and getting access upon return. Somitho 13:45, 18 December 2006 (UTC)

• I'm not really sure what the issue is that this proposal attempts to solve -- is it a solution looking for a problem? --ⁿɡ͡b Nick Boalch\^talk 12:17, 18 December 2006 (UTC)

• • Nick, did the above to Tim, answer your question? Somitho 13:45, 18 December 2006 (UTC)

• See also WP:PEREN. I don't like the hard-and-set cutoff lines, per m:instruction creep. This appears to force people to post wikibreak notices to exempt them from inactivity effects. I have not seen any evidence of inactive accounts actually being a problem. (Radiant) 13:24, 18 December 2006 (UTC)

• • It's not forcing them, but it is generally a good idea if you plan to be involved in the community to atleast post a quick note on your user page with "I'll be on wikibreak for 3 months while I visit South America." for example. Please take a second to read the above coments to Tim Starling on why I believe it needs to be done. — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}|talk]] • [[Special:Contributions/{{{1}}}|contribs]])
    • Yes, but your reasoning depends on a number of assumptions that you have not given any evidence for. In particular, as Tim says, inactive accounts are far less likely to be compromised (and if compromised, an account is unlikely to remain inactive). So the problem you purport to solve does not appear to be as problematic as you think; and even if it was, Tim stated they already have a better mechanism for dealing with it. See also Wikipedia:Inactive administrators (2005). (Radiant) 13:53, 18 December 2006 (UTC)
      • Radiant, I can tell you from personal experience in the industry, that it will happen eventually if it hasn't already. The issue is how do we mitigate the damage when it does happen. Look at Denial of Service botnets growth between 2000 and 2006; machines are easily compromised. I understand it may be easy for the developers to fix the problems; but what can we really do to lower the possibility of occurrence? I've removed all requirements in this proposed policy for re-RfA'ing as that was a bit extreme. I looked over Wikipedia:Inactive administrators (2005) am really not sure why it didn't pass, it was a pretty good idea. Somitho 14:24, 18 December 2006 (UTC)
        • Because (1) we don't in general fix hypothetical problems until they actually occur; (2) while the danger of account compromise is real, inactive accounts are far less likely to be compromised (leading to false positives); (3) a compromised account would likely not stay inactive (leading to false negatives) and (4) we already have a better method of dealing with compromised accounts. (Radiant) 15:12, 18 December 2006 (UTC)

I've modified a few of the policies at the advice of another user. Somitho 14:24, 18 December 2006 (UTC)

I also want to remind everyone, that I am open to suggestions; not just "lets end this now before it even starts". Somitho 14:24, 18 December 2006 (UTC)

I feel that the security gained is well worth any loss in viewed respect. I'm sure people will get used to the idea of their accounts becoming inactive after a given point of time. I also feel that the specific period of times are sufficient. Overall, I support this proposal. --Jmax- 14:50, 18 December 2006 (UTC)

In any system with hierarchical structures (or anything resembling that), people who do not need power should not be given power. For the rest I support it per Jmax-. -The preceding signed comment was added by Nazgjunk (talk • contrib) 16:07, 18 December 2006 (UTC)

Hmm, Intresting.. Possibly a good idea, but Wikipedia isn't a site where there should be 'stone-tablet' rules. Obvisuly some method for idnetifying dormant admin accounts would be good, but removing privliges for dormancy would need to be carefully explained to those affected, lest there be accuastions of people exceeding thier powers.. ShakespeareFan00 23:37, 20 December 2006 (UTC)

ShakespeareFan00, they would not lose access permanently; they could simply request it upon return from away status. As it says below; and on the policy. This is not a form of recall, and the only way a sysop would be denied access upon return is by ruling in effect by the ArbCom. Somitho 04:06, 21 December 2006 (UTC)

• Bad idea. Lots of extra work for the stewards, lots of hurt feelings, lots of editors not returning from what were intended to be temporary breaks, and very little benefit. This is a solution looking for a problem; until we have inactive accounts being compromised and causing problems, we don't need to consider how to prevent it: It's not a problem until it happens. If we start having waves of inactive sysop accounts being compromised, then I might change my mind, but I can't think of any at all, and even if they were, as Tim said, it's a very quick cleanup for the devs and a quick button click for the stewards. No need to create a policy where no problem exists. Essjay (Talk) 04:15, 21 December 2006 (UTC)

Why?

There are plenty of reasons given as to why this would not be bad. I'm not about to say it will be terrible. But for something to be implemented, it has to actually do something good, not simply have lack of badness. And the only argument given for why it's good is "Prevents compromising of accounts", which confuses me. Why is an inactive account more likely to be compromised? -Amarkov ^blah_edits 05:57, 19 December 2006 (UTC)

To answer your question, you are correct; an account active is no harder or easier to access than an inactive account. However, what everyone has failed to realize is, should it be compromised it would have been so unnecessarily because this policy could be introduced. An inactive account is no easier to get into, but is a sitting duck - so to say; because active accounts of course are active and need the tools and resources; and inactive accounts are obviously inactive, they do not; when account becomes active again it would be a fairly quick and easy process to just request such access again. Somitho 01:25, 20 December 2006 (UTC)

Not a recall

I would like to point out, this is in no way a threat of recall or taking your flag away for good. You could simply request it back upon return. But you do need to remember, you serve the community and whats best for the community IMHO is the best possible enhancement of security without undue hardship on the developers. Tim Starling has already commented and stated it could be reverted pretty quickly on the part of the developers; however the time it may take them to do such may take away from possible code development / enhancement of MediaWiki.

It would be a very simple process, the ideal situation is you declare yourself on wikibreak and your status would be removed until you requested it be returned. The other alternative is you are inactive for the minimum amount of time, the relevant tag is then disabled (checkuser/oversight earlier than your sysop tag due to the security at risk) upon a bot noticing you are inactive and forwarding to a steward. The steward then disables your tag, upon return you post on an access board; and a bureaucrat or steward retags you with your flag. No questions asked. No risk on losing your flag, as of current the only way to do such is by ArbCom resolution; and this would not change that.

I hope this resolves the concerns I have heard. Somitho 01:25, 20 December 2006 (UTC)

Problem is, this goes against what currently happens. Currently, if you are desysopped for any reason, even user request, and not just an Arbcom ruling, then bureaucrats are not under an obligation to resysop you. If they believe it would be in any way controversial, they are expected to send you to AfD RFA for re-confirmation, even if it was an entirely voluntary request. I doubt that this would change if there were a policy that mandated desysopping after certain levels of inactivity. -Amarkov ^blah_edits 04:14, 21 December 2006 (UTC)

Since when did we confirm administrators at AfD? :-)

That said, while I supported this idea in the past, I am not so sure anymore - if an inactive admin account is compromised, the attacker can just pretend he/she's back and proceed to ask for the bureaucrats to restore their priviledges - even if involuntary desysopping for inactivity is enforced. Look at how Rob Levin was tricked into giving a GNAA troll staff-level access on FreeNode - the troll impersonated FreeBSD/MySQL developer Greg Lehey. So this scenario is just as possible in the case of an actual compromised admin account. Leave the emergency de-sysopping to our devs - they know best and react adequately fast. Kimchi.sg 13:11, 27 December 2006 (UTC)