Wikipedia

Wikipedia:Village pump (policy)/Archive 149

< Wikipedia:Village pump (policy)
Latest comment: 5 years ago by Redrose64 in topic Can you update the date?
Village pump (policy) archive  

This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX, AY, AZ, BA, BB, BC, BD, BE, BF, BG, BH, BI, BJ, BK, BL, BM, BN, BO · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197

Proposal to tighten administrator inactivity procedure

Latest comment: 5 years ago341 comments156 people in discussion
This discussion has been open since Nov 22 2018, and at this time, there is no consensus to change the policy proposed in the first section. Mandatory 2FA comments took place in multiple sections and would require a proper RFC to solicit the input needed. -- Amanda (aka DQ) 03:30, 11 January 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Yeah, I know, WP:PERENNIAL. But after yet another compromised inactive admin account ran amok over the project today, I feel like this should be revisited. The account in question did not have a logged action in over 2 years, and had made only 5 edits in 2017 and one in 2018. The policy as currently worded reads:

Administrators who have made neither edits nor administrative actions for at least 12 months may be desysopped.[1] Subject to the lengthy inactivity consideration below, this desysopping is not to be considered permanent, or a reflection on the user's use of, or rights to, the admin tools. The admin must be contacted on their user talk page and via e-mail (if possible) one month before the request for desysopping and again several days before the desysopping goes into effect. Desysopping on inactivity grounds should be handled by English Wikipedia bureaucrats. The summary in the user rights log should make it clear that the desysopping is purely procedural.

I propose modifying this to:

Administrators who have made no logged administrative actions for at least 12 months may be desysopped.[2] Subject to the lengthy inactivity consideration below, this desysopping is not to be considered permanent, or a reflection on the user's use of, or rights to, the admin tools. Desysopping on inactivity grounds should be handled by English Wikipedia bureaucrats. The summary in the user rights log should make it clear that the desysopping is purely procedural.

References

  1. ^ Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins, June 2011
  2. ^ Wikipedia:Village pump (proposals)/suspend sysop rights of inactive admins, June 2011

The change removes the notification requirement, and the "edits" criterion. The effect is that admin accounts which don't use admin tools for 12 months will simply have the bit silently removed as a matter of security. We won't tell them we're about to do it, and then they won't log in and make one nonsense edit to hang on to the bit. Removal will just happen when they've been away long enough, and if they come back some time later and want to go back to adminning they just ask at BN and go through the 24-hour hold like anyone else whose bit has been voluntarily removed. In fact admins should be actively discouraged from "holding on to the bit" in this manner, but let's at least do this. Ivanvector (Talk/Edits) 17:51, 22 November 2018 (UTC)

Survey/discussion

  • Support Given the length of time the inactivity policy has been around for now, I think it's reasonable to assume every active admin has heard of it, and nobody will be surprised if their rights expire, so provided this gets enough publicity in the right places, we should just do it. Also, as I just said on another thread, I think it would also be helpful to make two factor authentication mandatory for all admins, and desysop those who do not turn it on. It would stop this kind of disruption. Ritchie333 (talk) (cont) 18:09, 22 November 2018 (UTC)
I agree with the idea of desysoping (or at least warning) people for not using 2FA, but there would have to be some kind of cool-down period. Earlier this month, I had to get my phone replaced, meaning I went a day or so without 2FA. It simply wouldn't have been efficient to remove the bit for only 24 hours (especially because I was still active). Perhaps existing admins should get a month or two to set it up, all new admins get one week post RFA closure, and all admins that need to temporarily disable it also get a week. Anarchyte (talk | work) 23:12, 22 November 2018 (UTC)
I strongly disagree with any forced 2FA idea. Forcing editors to have a certain device in order to be admins runs contrary to our most basic principles. There is no rational reason to preclude people unwilling or unable to use such additional devices from being admins. Especially since 2FA is still a hassle as Anarchyte points out and any problem with the device might render an admin incapable of editing at all. Plus, how many active admin accounts have been compromised? Regards SoWhy 11:58, 23 November 2018 (UTC)
I also strongly oppose mandatory 2FA. Benjamin (talk) 01:12, 25 November 2018 (UTC)
Which part of our basic principles is it that requires insecure login methods?  — Scott • talk 15:42, 3 December 2018 (UTC)
As much as I think 2FA is a good idea, the fact is that requiring it would violate WP:5P3 (Wikipedia is free content that anyone can use, edit, and distribute). Administration is an essential part of running the project, and thus the ability to participate in administration needs to be available to anyone. Some people cannot afford to purchase the hardware required for 2FA. Some people are physically incapable of operating such hardware. Some people are not technically savvy enough to master its use. I would not be surprised if there were places in the world where possession of such hardware would be a crime, or at least expose you to unwanted government scrutiny. -- RoySmith (talk) 00:38, 19 December 2018 (UTC)
Good point. RfC banner added, and I'll advertise on CENT as soon as I figure out how that works. Ivanvector (Talk/Edits) 19:09, 22 November 2018 (UTC)
  • Strong support This should be done to any account with advanced permissions, such as rollbackers and reviewers, not just admins. funplussmart (talk) 19:05, 22 November 2018 (UTC)
  • I suggest that this proposal should also modify the lengthy inactivity section to clarify that the clock for the three years of uninterrupted inactivity always starts with the last edit, and not with the last administrative action. isaacl (talk) 19:05, 22 November 2018 (UTC)
  • Support the original proposal per the nominator, oppose making 2FA mandatory. I'm presently unable to use it as my only compatible second device is away being repaired (due to an obese battery). There is also insufficient capacity at the WMF to handle users who have problems with it. Thryduulf (talk) 19:31, 22 November 2018 (UTC)
  • Oppose if you're going to get rid of the edit requirement then you need to have some sort of protection for admins who perform non-logged actions. We've had admins who only take part in admin actions that don't generate logs, such as editing the various bits of the main page. Such an admin would be desysopped even though they're still performing admin actions. Yes, they could ask for the admin tools back, but I don't see why they should have to every month just because of a badly drafted policy. Strictly this would also allow new admins and recently resysopped admins to be desysopped as well. Hut 8.5 21:01, 22 November 2018 (UTC)
    • I imagine the bureaucrats would just skip that admin each month, knowing that they are performing non-logged administative actions. As long as the number of these are low, it should be manageable. isaacl (talk) 22:47, 22 November 2018 (UTC)
      • They might skip them, they might not. There would be no policy basis for doing so and bureaucrats tend to be keen on sticking to procedure. The more of these admins there are the harder it is to justify not desysopping them. The whole issue could be avoided by striking one word from the proposed policy change. Hut 8.5 20:37, 23 November 2018 (UTC)
        • @Hut 8.5: I have no problem with that personally, but then we're asking the 'crats to take on the non-trivial work of judging which admins are active. There's a proposal below to implement a log for editprotected actions, so that editing a protected page will be a logged action and count toward activity with this wording. And viewdelete has come up but as I understand how filters work just looking at a deleted page is not something that can be logged, but so far a theoretical admin who only uses viewdelete is an extreme edge case. Ivanvector (Talk/Edits) 20:55, 23 November 2018 (UTC)
        • Sure, I don't have an issue with removing the word "logged" from the proposed text. "may be desysopped" leaves the door open for judgment, but I agree that there isn't a need to limit the range of applicable administrative actions. isaacl (talk) 21:00, 23 November 2018 (UTC)
          • I'd be happy to support this if the activity requirement was defined in terms of admin actions, where an admin action is something which can only be done by an admin and which shows up in your contribution history somewhere. That would include editing fully protected pages, closing discussions which have to be closed by admins, imposing discretionary sanctions and probably a few other things. I agree viewing deleted pages isn't enough and we can't verify it anyway. "Logged action" will be interpreted as something which shows up in Special:Log, which is more restrictive. Hut 8.5 21:42, 23 November 2018 (UTC)
    That's the intent, really: by "logged action" I mean "some action that requires admin permissions". Up until very recently (see below) I was under the impression all admin actions were logged in one way or another. Logging everything admins do is good for accountability, and also has this side benefit of being an indicator (by absence of log entries) of which admins are not actively adminning, and so I went with "logged action" for the policy wording. But it's just as well if it's wording meaning "any administrative action" as long as we have an unchallengeable definition (i.e. editing a protected page is, closing an RfC is not; it's something non-admins cannot do, not just something they shouldn't) and some way to measure it (i.e. logging, or maybe a bot to do the check, or calling on the 'crats to do it). Ivanvector (Talk/Edits) 22:06, 23 November 2018 (UTC)
  • Interface admin allows people to edit interface pages, not ordinary full-protected pages. Furthermore interface admins can do a lot more damage than admins and you have to be an admin to be an interface admin. Hut 8.5 22:04, 22 November 2018 (UTC)

*Support - We're not in 2006 anymore and this isn't a small fairly unknown website, We're currently the 5th visited website in the world and as such in this day and age account compromises really shouldn't be happening, But compromises can and do happen everywhere so we're not always going to be tiptop in that respect, Anyway I support the modification/update. –Davey2010Talk 23:02, 22 November 2018 (UTC)

  • Support - Not sure what I was going on about above .... but anyway admins logging in and making one logged-edit simply to keep their tools is ridiculous - If you're not actually going to help here then what's the point in keeping the bit ? .... so the silent removals (instead of notifications first) will hopefully stop this, As the saying goes: Use it or lose it. –Davey2010Talk 12:37, 2 December 2018 (UTC)
  • Support it’s not that difficult to make the trip to CAT:EX or CAT:G7 so the inevitable “people will make dumb actions just to keep the bit” thing falls flat. Opppse anything about mandatory 2FA. I use it, but we would lose several functionaries if we required it not to mention countless admins. TonyBallioni (talk) 23:07, 22 November 2018 (UTC)
  • Support - Not sure how long it should be, but the constant gaming by inactive−but technically active−admins is counterproductive. Anarchyte (talk | work) 23:12, 22 November 2018 (UTC)
  • Oppose. We want inactive admins to resume helping if and when they want to; there are life reasons someone may step away from the project, and not all will be willing to run the RfA gauntlet again as Opabinia regalis was. We don't want to encourage someone disaffected with the project but unwilling to surrender their tools to delete something or block someone just to keep them, even if it's an unquestioning response to a noticeboard request. Admins who do things like editing fully protected pages (not only DYK, but ERRORS comes to mind) are as useful as those who specialize in deleting and/or blocking, but the former don't appear in the easy to check log. (Nor does checking deleted contributions in evaluating how to speak to an editor, for that matter.) On the other hand I got lots of log entries for moving my own drafts to main space "without leaving a redirect". It's not a fair metric of admin activity. Desysopping for inactivity is also not an efficient way to protect against admin abuse: I recall one case where an admin ran wild including posting a philosophical musing to the Main Page. Emergency desysopping is the best strategy and less likely to lose us useful admins. And we already have that. I also recall seeing something about functionaries periodically testing admins' passwords for strength, but given other cases I recall, I doubt that's been being done. That would help (and would encourage those who don't have serious problems with two-factor authentication to take the step to get out of the resulting demands they change their single password). Also, admins are expected to have e-mail turned on; has any thought been given to bureaucrats' e-mailing those who don't appear to be using their tools, asking whether they would consider handing them in voluntarily? Yngvadottir (talk) 23:17, 22 November 2018 (UTC)
  • I would prefer to increase the requirement on what constitutes as "active". An editor who has six edits over two years should not be considered active enough to keep the tools. Mkdw talk 23:35, 22 November 2018 (UTC)
  • Support Use it or lose it. The current requirement of needing a single edit in a calendar year is routinely gamed and far too low of a bar for retaining advanced permissions that can cause wide-spread disruption. Having read through previous related discussions I have never seen anyone present a compelling argument against implementing more stringent requirements.-- Jezebel's Ponyobons mots 23:43, 22 November 2018 (UTC)
  • Support We have nearly 80 admins who have edited in the last 12 months but haven't performed a logged admin action for over five years (in a few cases, ten). All of those, unless they're performing a large amount of non-logged actions - which I doubt - need to lose the bit. There's even a few there who have never passed an RfA .... Black Kite (talk) 23:59, 22 November 2018 (UTC)
  • Support per nom and above supports. ZettaComposer (talk) 00:53, 23 November 2018 (UTC)
  • Support this system is easier to implement, prevents gaming, and has good rationale as per nom. --Tom (LT) (talk) 01:08, 23 November 2018 (UTC)
  • I don't like the idea of -288 admins and -4 crats. I do like the idea of 2fa being mandatory. SQLQuery me! 02:34, 23 November 2018 (UTC)
  • Support. Removing privileges from admins who don't engage in any admin activity is a "paper loss", but a compromised account with privileges causes real harm. The standard proposed is still conservative and easy to meet. By comparison, some other WMF projects have requirements for admin actions every 6 months. (See meta:Admin activity review/Local inactivity policies for more information on other projects' policies.) --RL0919 (talk) 02:44, 23 November 2018 (UTC)
  • Support. Re-requesting the bit if it's been removed is no big deal; compromised admin accounts meanwhile pose a much larger issue to the project. Home Lander (talk) 04:18, 23 November 2018 (UTC)
  • Oppose. First off - This is very premature. Difficult cases make bad law; it's always a bad idea to respond to an event by immediately trying to create a policy that will prevent its recurrence. There has not yet been an analysis of what was going on here. We don't actually know if this is a compromised account; really, what we have is an admin account that acted in an unacceptable manner. Conclusions have been leapt to, and they have not yet been proven. Second - there's no evidence that this change will prevent future similar episodes. The vast majority of administrator accounts that required their privileges to be yanked were those of administrators who would easily have met these more stringent standards, let alone the current ones. Come back in a month, with greater research and good evidence that the proposal will likely prevent rogue administrator actions, and then we can talk. Risker (talk) 04:40, 23 November 2018 (UTC)
    We do know that the account was compromised (related phab task) but otherwise agreed that knee-jerk reactions aren't the way forward here. -- Ajraddatz (talk) 05:14, 23 November 2018 (UTC)
(Unfortunately the task is not visible to the public.) — regards, Revi 05:17, 23 November 2018 (UTC)
What we do know is that the same person has compromised (or at the very minimum, abused) 16 other accounts.[1] Personally I've no doubt about it. -- zzuuzz (talk) 07:20, 23 November 2018 (UTC)
Well, since Ivanvector below has indicated that this proposal isn't really about the recent admin account hackings, and it seems to now be understood that this wouldn't prevent hacking in the first place, I'd be willing to consider an increase in the activity levels of admin accounts. However, I do see lots of useful admin activities that are not logged. If there is to be a change in threshold for de-adminning, I'd go with any combination of X number of edits and Y number of logged admin actions within the previous 12 months, where the total of X+Y equalled some specified number; for example, there must be a minimum of 10 actions (either edits or logged admin actions) within the past year. I strongly believe, however, that the notification of a user that they are on the verge of losing their admin tools is absolutely mandatory; I actually don't understand why anyone would think it was okay not to do so. And it seems there is an agreement that 2FA is off the table too, which is a good thing, since it's really out of the control of a single project. Risker (talk) 02:25, 24 November 2018 (UTC)
It is about the recent hackings, but not meant to be a solution to that problem, just mitigating risk. If the idle hacked accounts had not had admin access then probably the hack would have just taken another form, the vandal has also been hacking accounts that only have rollback permissions. As for the notification requirement, my rationale for changing it is that in the policy's current form we let admins be entirely idle for an entire year, then we tell them to make one single edit if they want to hang on to the bit for another entire year, and in my view that entirely defeats the purpose of suspending the rights of inactive accounts. We might as well just not have this policy at all. If we alter the activity requirements instead, that could be an alternative to this proposal, but given that so many have already commented here on the original I think it would be a good idea to break that out into another subsection. Ivanvector (Talk/Edits) 14:58, 24 November 2018 (UTC)
Well, since it *is* about the recent hackings after all - and given the fact that as I write this I am currently investigating the most recent compromised admin account (of an administrator who is highly active)....this entire discussion is moot. This isn't going to stop the vandal involved, and I don't think it reduces risk whatsoever. Risker (talk) 20:33, 24 November 2018 (UTC)
  • Oppose Having to ask for my bit back every month because I only edit protected pages is not an ideal scenario. Stephen 05:08, 23 November 2018 (UTC)
  • Oppose - As a semi-active admin (but not one who would currently be desysopped under this proposal), I can't support this. I don't believe that the risk of rogue admin actions outweighs the harm to the project that would be caused by driving away semi-active admins who have put in a lot of time and edits, even if real life is preventing them from logging admin actions right now. In addition, desysopping without even a notification is cruel. -Danaman5 (talk) 05:39, 23 November 2018 (UTC)
"Cruel"? I had my admin rights on Monochrome BBS removed without asking sometime around 2002 (I couldn't even pinpoint the year, which is kind of the point) because of inactivity. All I said was "it's a fair cop". Ritchie333 (talk) (cont) 12:05, 23 November 2018 (UTC)
  • Support Not really about security, because I feel that's a non-issue overall. But I have long thought this policy needed tightening up to stop people "playing the game". I would change it slightly though, to remove the word logged, so removals should be based on any edit or log which required admin status. Aiken D 06:37, 23 November 2018 (UTC)
  • Oppose I was going to say what Risker said, but she already said it, so I can just say "what Risker said" ;) We can't just stop informing people of changes that concern them because we don't want them to actually act on that information. Adding to that, I always have a negative reaction to the tone of some of the comments in admin-activity discussions - there's always a lot of snippy posts about "gaming the system" and "hat collecting" and whatnot. Every time I point out that that was me at one point, I almost certainly would have done the "log in and make an edit or three" thing if I'd seen the messages while I wasn't active, and it would have been entirely due to thinking "oh yeah, it's been awhile, I should get back into that when I get some spare time" and then not following up due to, well, lack of spare time. And based on that the same stuff gets posted every time, it seems that pointing out that there's a perfectly reasonable good-faith thought process behind this behavior has exactly zero demonstrable impact on people's willingness to make kind of mean-spirited assumptions. That's not a reason to oppose on its own but it's a weird and off-putting pattern. *shakes fist at cloud* Opabinia regalis (talk) 07:10, 23 November 2018 (UTC)
  • Question: What's the escalation plan for two years or so from now, when the new moral panic is about admins who create and then speedy a page in their userspace once a year? —Cryptic 08:25, 23 November 2018 (UTC)
  • Support By definition, by not editing/doing an admin log in 12 months means they are not an admin! Lugnuts Fire Walk with Me 08:54, 23 November 2018 (UTC)
  • Oppose, far too many "things only admins can do" don't appear in the logs. We need more admins not less. Fish+Karate 09:25, 23 November 2018 (UTC)
    And I will note this RFC has not been written neutrally. "Yet another admin account" implies this happens frequently; per Wikipedia:Former_administrators/reason/compromised, the accounts of Denelson83 and Esanchez7587 have both been compromised this year, but the last one prior to these two was in 2012. Nine compromised admin accounts in 12 years is not frequent. "Ran amok over the project" - they made zero edits and 12 administrative actions, 10 of which were blocks, all of which were undone within 33 minutes. Emotive language doesn't help anyone. Fish+Karate 09:44, 23 November 2018 (UTC)
    In 2016 quite a few admin accounts were hacked by OurMine (see [2]) and they're not listed there in former administrators because they recovered their accounts (see e.g this for locking and unlocking) Galobtter (pingó mió) 10:03, 23 November 2018 (UTC)
    And in 2015, a few accounts were compromised by an attack elsewhere, including two admin accounts. I can agree with the wording being a little iffy, though it's a little more understandable after these are factored in. Anarchyte (talk | work) 10:11, 23 November 2018 (UTC)
    Thanks both, I was not aware of these. This takes it to 14/15 or so admin accounts in 12 years, unless there's others still unlisted, which still doesn't strike me as a regular occurrence to the point 2FA has to be imposed on everyone. Fish+Karate 10:52, 23 November 2018 (UTC)
The reason they didn't appear to "run amok" after indef-blocking two long-standing users who tried to stop them is that a bunch of people scrambled around to get the issue fixed ASAP. As Anarchyte has mentioned, The page above does not document the incident where Salvidrim and OhiaUnited were compromised, or when Jimbo Wales' account was cracked and ran amok, for example. We need a full set of figures to be able to look at the facts correctly. Ritchie333 (talk) (cont) 10:20, 23 November 2018 (UTC)
These stats also don't count the several steward and functionary accounts that were also hacked recently, which could have caused serious actual harm (but AFAIK didn't). Not that this proposal would do much for those levels of permissions, I'm just saying this is quite far from an isolated incident. Ivanvector (Talk/Edits) 13:11, 23 November 2018 (UTC)
  • Support- regardless this latest trigger issue. Not one iota of valid argument in any of the opposes so far. Leaky Caldron 10:15, 23 November 2018 (UTC)
  • Support Everyone can edit, but only admins can make admin actions. Thus their level of activity should be judged by the amount of admin actions they make. I fully understand that some of these actions are not logged, but I don't view this as a reason to oppose. talk to !dave 11:15, 23 November 2018 (UTC)
  • Conditional Support on the basis that an edit filter like the one Xaosflux proposes here (or some other solution) is adopted, so that all major onwiki admin actions are logged. Iffy★Chat -- 11:37, 23 November 2018 (UTC)
    @Iffy: These could be logged for bot review (see example on testwiki. — xaosflux Talk 14:45, 23 November 2018 (UTC)
  • Support protection of the project clearly outweighs putting a legacy admin to the trouble of requesting their tools back occasionally. ——SerialNumber54129 11:48, 23 November 2018 (UTC)
  • Oppose I wish people were pouring effort and creativity into keeping the editors and admins we have. Rogue accounts are easily dealt with. Making people go through any kind of hoop at the end of inactivity is an unhelpful additional barrier to their return. --Dweller (talk) Become old fashioned! 12:25, 23 November 2018 (UTC)
  • I'm all for increasing the activity requirement for security purposes. At the moment it's anything greater than 0 activity. I'm not sure that greater than 0 admin activity is the right way to go - I'd be more keen to look for say, 50 edits per year. It will stop those who keep dormant accounts alive by making a single edit, yet should be easy to reach even at 5 edits per month, which is our definition of "active". Perhaps have 50 edits per year or 1 admin action per year? Regarding mandatory 2FA, I oppose. largely per Risker's diversity concerns. WormTT(talk) 12:28, 23 November 2018 (UTC)
  • Oppose. (Disclaimer; this provision would have caught me out on multiple occasions.) The whole "reduce the potential for compromise" thing, I'm assuming is a complete red herring, unless anyone can provide any actual data to indicate that "admins who have edited within the past 12 months but haven't performed a logged admin action in that period"—the only group which would be affected by this proposal—are at any more risk of compromise than any other account. I'm a strong opponent of the current setup which allows legacy admins from the early days of Wikipedia to periodically emerge and start trying to enforce the standards of a decade ago, and would support some kind of periodic reconfirmation, but I don't see how this proposal would address either the security or the legacy admin issues. (What's to stop either a compromised account, or an incompetent legacy admin, from heading over to WP:BN and asking for the sysop bit back?) In all honesty, whatever the good intent of the proposers it looks more to me like an attempt to cull the number of admins via the back door. ‑ Iridescent 12:32, 23 November 2018 (UTC)
I don't particularly disagree with anything you've said here, but let me try and clarify my view on this. As I vaguely mentioned above, the inactivity standards here seem to be far higher than anything else I've personally witnessed - I've been the equivalent of desysopped for inactivity elsewhere without complaint (but perhaps I'm just the sort of person who shrugs shoulders and moves on) and when I was a regular on Monochrome BBS in the 1990s, policy was that if you didn't use any account (ie: basic user privs) for three months, it was deleted. Is that a good or bad thing, or just different? Secondly, I do think "culling the number of admins via the back door" is a fair point, and I think part of that is due to the dissatisfaction over "legacy admins" because it's too hard to pass RfA these days. Indeed, one of the reasons I went looking for admin candidates over the past 12 months was simply to try and dilute some of that, so that we had a fresh corpus of new admins bringing new ideas into the place, rather than having to rely on people with a grandfather clause. As for what else can do about that, I don't know. Ritchie333 (talk) (cont) 12:49, 23 November 2018 (UTC)
  • I'm in a weird place here — In a vacuum I don't dislike the proposal, but a few of my "always agree with" editors have opposed, so per usual I'm in agreement with them. I like the policy change, if only because it will increase the churn and make it clear that +sysop isn't that big of a deal. I'm not concerned about unlogged sysop actions (although regardless of this the edit filter may be a good idea) because it should be easy to head over to BN and say "Yo, still sysoping here" and get the required bit back. That does, however, belie my real issue with this, which is that it doesn't solve the problem of compromised accounts. A user who is occasionally editing without any logged actions is no less likely to be compromised as they are indeed still using the account. I can support more stringent activity requirements, but I can't support this on the grounds of trying to solve compromised sysop accounts. Put more succinctly by Eli355, [t]he Administrators are still using their account. ~ Amory (u • t • c) 13:18, 23 November 2018 (UTC)
  • Yes, but Only if DYK/Protected Logged - we frequently see DYK as a primary reason for suffering going through RfA, and protected edits must also count. I am in favour of this but at a minimum we need DYK logged and probably any protected edit tagged. Nosebagbear (talk) 13:49, 23 November 2018 (UTC)
  • While I don't want to be one of those "old" admins coming out of the woodwork to reflexively oppose, I think I'm going to oppose. De-adminning for inactivity makes sense to me - if you don't log in for a long time, you may not know what's going on, and you may not be paying enough attention to your account to be sure it's secure. I could support reducing the window of inactivity in the project at all, but I'm not convinced that de-adminning for disuse is the right way to go. What the project needs isn't fewer admins - it's fewer inactive admins. So rather than quietly taking about the tool, why not nudge people to use them more? Something like a bot message that says "you have not made a logged admin action in the last 6 months. Here are some clean-up tasks you could help with". Maybe after a year, up it to "you haven't made a logged admin action in the last 12 months. Please drop by BN to confirm that you still want the tools". Sure, some people are going to make some logged actions just to hold onto the tools, but for every one of those, there would probably be 10 or 20 people who would say "you're right, let me help out a bit". At the very least, I think we should try to nudge people into activity instead. See if that works, before we go ahead with a proposal that, let's be honest, assumes bad faith on the part of inactive admins. Guettarda (talk) 14:17, 23 November 2018 (UTC)
  • To be honest I'm surprised that so many editors are commenting here that this RfC is an attack on inactive admins. It's not, not at all, and I'm a little bit offended that it's being interpreted that way. It's purely patching a security vulnerability. Think of it like the front door of your house (apartment, dwelling, whatever). You have some friends over, you have a good time, eat some food, drink some beers, play some games, whatever. Then everyone goes home, and you close the door. You're still friends (presumably), they're still welcome in your home, but you don't just leave the front door open for when they come back (or you don't in this climate anyway). When they do come back, you look out your window or peephole or whatever, confirm it's your friend knocking on the door, then you welcome them back, eat some beers, drink some food, whatever it is you do for fun. That's all that this is. If an admin has been away for a while, they're still an admin, we just take their mop and hang it back in the closet while they're not using it. It's their mop, and when they ask for it back we gladly hand it back over, and then a bunch of people drop by WP:BN and leave notes like "hey welcome back! we missed you!" It's not a back-door desysop at all.
As for solving compromised admin accounts, of course this doesn't, it doesn't even really try to. As long as we have admins we're going to have hackers trying to crack admin accounts; some of them are inevitably going to be successful, and that is not the admin's fault. All this does is cut down on the number of doors left open to Wikipedia's house. And sorry for the crude analogy. Ivanvector (Talk/Edits) 15:29, 23 November 2018 (UTC)
  • CommentI am not an admin so maybe there is something I am missing, but how does this helps security. Is there any difference in using your account to make admin actions or edits in terms of judging activity and the likelihood of an account to be compromised. Using Ivans open door comparison, you are just as likely to open your door to a friend who has come over for an informal chat as you are to your same friend who comes on some formal visit. They have still visited, even if it is only once a year. If it really is necessary to tighten security via counting actions I feel it would be better to shorten the time of inactivity or increase the minimum number of edits per year. AIRcorn (talk) 17:34, 23 November 2018 (UTC)
    I think the main goal is to reduce the attack vector; less admins means less accounts vulnerable to be compromised, and accounts largely inactive are likely that of users who may not be around to get the reminders and improve their passwords (noting another admin just got compromised..last admin action in 2014) Galobtter (pingó mió) 19:45, 23 November 2018 (UTC)
  • Support, seems like a sensible reform. GABgab 18:20, 23 November 2018 (UTC)
  • Oppose the change per Risker and Iridescent. Particularly with the attempt to backdoor force 2FA for admins. ♠PMC♠ (talk) 19:55, 23 November 2018 (UTC)
Oh, hey, just back from another cleanup from another compromised admin account. There is no "attempt to backdoor force 2FA for admins" going on here. I don't know how to more clearly or bluntly state that 2FA enforcement is not going to happen. If it does it will come from the WMF and we'll have no say in the matter. It's just not part of this proposal at all. Ivanvector (Talk/Edits) 20:19, 23 November 2018 (UTC)
@Ivanvector, the very first comment in the thread is make two factor authentication mandatory for all admins, and desysop those who do not turn it on. You can legitimately say that you don't agree with the attempt, but don't try to claim the attempt isn't being made. ‑ Iridescent 12:55, 24 November 2018 (UTC)
There is always some background minority push to do some thing that is widely not supported or technologically impossible. Mandatory 2FA for admins is one of those rare things which is both not widely supported and difficult technologically to implement (WMF's implementation, not necessarily 2FA in general, see Risker's comments among others). I view the attempts to wedge mandatory 2FA into this completely unrelated proposal as hijacking the thread, and I wager I am more angry about it than you are. Ivanvector (Talk/Edits) 14:13, 24 November 2018 (UTC)
  • Oppose - Some form of removal notification is due, and it is possible to use the tools for the benefit of the community without logging any administrative action (e.g. viewing deleted page history). — Godsy (TALKCONT) 20:08, 23 November 2018 (UTC)
  • Support If you are not using the tools, you will not miss them. If you do want to use them, all you have to do is ask for them back. It's a small hoop to jump through for the sake of fewer sysop account with the potential to be compromised. The benefits to the project outweigh the inconvenience to any very infrequently active admins that this would affect. Natureium (talk) 20:27, 23 November 2018 (UTC)
  • Comment - We've had another cracked admin account this evening, no logged activities for four years, vandalised the main page, deleted today's featured article and indeffed a bunch of admins. Does this influence anyone's opinion? Ritchie333 (talk) (cont) 20:33, 23 November 2018 (UTC)
  • Support The base proposal without requiring 2FA. It should remain a strong recommendation though. Also support "logged actions" being extended to use of editprotect and tracked via the edit filter mentioned above. — AfroThundr (u · t · c) 20:49, 23 November 2018 (UTC)
  • Support The time for pearl clutching is OVER. 2 compromised accounts in a few days is unacceptable. Furthermore it will make the Mop Holder "Put up or Shut Up". Either they do have a need for the admin toolset (or can relatively easily get it back) or they don't need the tools any more. I agree with the provisos regarding certain unlogged items that should count as activity (though why we couldn't get those logged as admin activities is annother question). I note that previous attempts to get admins to maintain secure passwords (or 2FA) were turned down as beyond scope, however the outbreak of compromised administrator accounts requires us to exercise the more painful choice. Hasteur (talk) 22:27, 23 November 2018 (UTC)
  • Support Long overdue. The counterargument that not all admin actions are logged, while technically true, is a red herring. If you are only using adminship as a status and to peek at deleted material, you aren't doing an admin work. With two inactive accounts compromised in as many days it should be abundantly clear that this is needed. The policy will still be quite lax. Beeblebrox (talk) 23:46, 23 November 2018 (UTC)
  • Support - There are too many Admins gaming the system by making one edit a year to keep hold of their Admin bit when notified, and not making one Admin action for several years. It is about time we use common sense and stop this charade. JMHamo (talk) 00:23, 24 November 2018 (UTC)
  • Oppose When I first started reading I was intending to support. However, after reading some comments above, specifically Cryptic's about there still being a very easy loophole to keep the tools. The only counter to that is not telling admins that there tools are about to be yanked might work the first time, but, after that it won't be difficult to add a yearly reminder to create then speedy delete a userspace page. This would be especially easy to circumvent if edits to protected pages count as admin actions for this proposal, as one edit per year is still all that's required, it'd just need to be to a protected page instead of any page. Perhaps it might be better to increase the number of edits and/or logged actions are required to keep the tools. Callanecc (talk • contribs • logs) 01:04, 24 November 2018 (UTC)
  • Support - Per nom, remove irresponsible "gaming the system" and just plan account security. - FlightTime (open channel) 02:44, 24 November 2018 (UTC)
  • Support The comments about unlogged admin actions, moral panic, and suggestions of how an admin could game the system miss the point which is that reducing the attack surface is the first principle of security. That's all. Unlogged admin actions can be solved with a cratchat to establish an exception for a particular case. Concern about biting inactive admins can be solved by crafting a good message thanking them for their work and letting them know they can easily regain the right. That process should emphasize the need to have a unique password. Almost certainly the hacking of several admin accounts in the last couple of years was done by people matching the list of admins with lists of user accounts hacked on other websites and finding cases where the hacked password was reused at Wikipedia. Admins who are genuinely active are much more likely to have thought about security and we can hope they use a unique password. Johnuniq (talk) 03:03, 24 November 2018 (UTC)
  • A further suggestion: how about not calling it "desysopping", but something like "suspension of administrative rights"? The admin in question is not being removed from the administrator corps, and can continue to do all the same administrative actions as before that do not require administrative rights (including deciding not to take any actions). Should the admin wish to take an action that requires the administrative rights, an extra step of requesting that administrative rights be re-enabled is needed. isaacl (talk) 03:21, 24 November 2018 (UTC)
  • Support This is a political question, and I'm strongly in favor of there being more situations where admins have to say hello at WP:BN after a moderate duration absence from regular activity, or re-RFA after a longer one. I do agree with the concerns that editing the various full-protected transclusions of the Main Page should be tracked as admin actions for inactivity measurements if this is implemented; the case that an editor only edits other full-protected pages is unlikely enough to be ignorable. power~enwiki (π, ν) 03:30, 24 November 2018 (UTC)
    I must note that I don't see the security concerns as a good reason to support this, though it's a plausible excuse to re-start this perennial discussion. A more effective way to handle security concerns would be to inform all admins who haven't changed their password since 2013 that they have 30 days to change their password to one that meets security guidelines, or they will lose their admin privileges. Simply reducing the number of admins does nothing good (I concede we could completely avoid the risk of hacked admins by having no admins at all); this proposal acts as a (weak) proxy for reducing the number of admins who have insecure accounts, which is what is needed. power~enwiki (π, ν) 03:30, 24 November 2018 (UTC)
    Is there a way to force password change, maybe in LocalSettings.php, say every 90 days or whatever span of time ? - FlightTime (open channel) 03:47, 24 November 2018 (UTC)
    I note you're both making an assumption that passwords created in 2013 or earlier don't meet current security guidelines, or assuming that the security guidelines should include mandatory password changes. You may want to read https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes about the latter. (P.S. Yes, mw:Manual:$wgPasswordExpirationDays exists) Anomie⚔ 15:49, 24 November 2018 (UTC)
I'm no assuming anything, I was merely asking a question. - FlightTime (open channel) 23:25, 24 November 2018 (UTC)
  • I don't assume that all early passwords are weaker, but I believe the software-enforced minimum password strength has increased over time (if you believe all the comments here, at one time 1-character passwords were allowed, and that certainly should not be allowed). Forcing everyone to do a one-time password rotation might be a better option. I don't support a mandatory 90-day expiration period; in my professional experience in the technology industry rotation periods of less than 1 year are almost always harmful in improving security. power~enwiki (π, ν) 16:15, 24 November 2018 (UTC)
  • Oppose - As others have said, there are admin actions which are not logged. There are a lot of permissions in the admin toolkit, and most are not logged, and many are of indirect, rather than direct use. This has been stated in every one of these discussions. that fact hasn't changed. Plus there are things admins do which require access to certain tools, but which may not need their actual usage in that specific instance. Such as closing a deletion discussion. Also, we prefer admins to embody restraint in regards to tools. This sort of proposal will just cause people to think they shouldn't act with restraint. And besides that, we'll start seeing logs bloat with barely accountable actions. Want an example? Handing out rollback is something an admin can do. And hey, it's even logged! So every admin just goes and gives rollback to someone. And to really make it fun, give rollback to an inactive admin... Tell me what's been solved? And finally, the moment an admin account has been compromised, wouldn't the compromiser immediately do an admin action? And so wouldn't that pretty much void the justification for this proposal? This may be a well-meant proposal, but it just really is a bad idea. - jc37 04:38, 24 November 2018 (UTC)
  • Support - Given recent events, this proposal is more than necessary. A year without a logged action is an enormous window, and any affected admin can just pop over to WP:BN and ask for the bit back. Nathan2055talk - contribs 05:23, 24 November 2018 (UTC)
  • Strongest possible oppose Does it ever occur to you that not all of us have smartphones and never plan to have them, so not all of us have the option of 2FA? I don't really have an opinion on changing the activity requirements, but don't take away my user rights as long as I'm using them in a proper fashion. Period. Nyttend (talk) 05:45, 24 November 2018 (UTC)
    Nyttend, 2FA isn't actually part of this proposal. I apologize for my earlier comment conflating the two ideas, but this is only about the activity requirements. Bradv 05:47, 24 November 2018 (UTC)
    And 2FA doesn't need a smartphone anyway - there are 2FA apps for computers too. Boing! said Zebedee (talk) 08:15, 24 November 2018 (UTC)
  • Support. - There are a few pretty egregious individuals, basically NOTHERE administrators, if you will, who do a couple bland edits a year to retain tools. We need to get a handle on how many or few administrators there actually are, and these phantoms impede an accurate assessment. Carrite (talk) 07:57, 24 November 2018 (UTC)
Just wondering - what's wrong with that? --The Cunctator (talk) 15:17, 4 December 2018 (UTC)
  • Support. As others have opined, if you're not going to use the admin tools then you shouldn't have them. And it's easy enough to restore the bit to someone who is genuinely going to use it. I'll just add that my opinion is not related to the recent hacks, it's a view I've held for a long time. Boing! said Zebedee (talk) 08:18, 24 November 2018 (UTC)
  • Support disabling inactive rights is basic risk management in any it organisation. Doing one or two dummy edits a year is WP:GAMING of the inactivity rule and shouldn't be encouraged. --Pudeo (talk) 09:04, 24 November 2018 (UTC)
  • Agree that gaming the system is a problem. Disagree with the proposed solution to the problem of not notifying the inactive admin. The right way to deal with this is like we do with 3RR: an editor who repeatedly waits until just after the 24 hours is still treated as an edit warrior. Likewise, we can treat any pattern of dummy edits that are clearly designed to avoid the inactivity rules as we would treat any other inactivity. --Guy Macon (talk) 09:41, 24 November 2018 (UTC)
  • Support any proposal to tighten admin standards and accountability. feminist (talk) 09:55, 24 November 2018 (UTC)
  • Oppose This proposal as drafted risks exacerbating a bigger problem than it seeks to address. Our problem of admin retention is much much more serious than any problem that the current proposal is hoping to mitigate, and auto desysopping makes Wikipedia less welcoming for returning admins. I would be more relaxed if this was a more nuanced reform with the period of time that old admins could return after increasing and the introduction of a meaningful test for such returnees. For example one day of renewed activity (not necessarily contiguous) per year of absence, up to a maximum of ten years since being desysopped for inactivity. That would give the community a reasonable chance to assess if the returnee had remembered/refreshed and updated themselves about Wikipedia, and showed enough commonality and experience that they were likely the same person. ϢereSpielChequers 13:43, 24 November 2018 (UTC)
  • Why do we need to retain an admin who performs 1 admin. action a year? They are not productive in any meaningful way and simply inflate a headline Admin. count which does not reflect true productivity in anyway. Rather like many of the stats. you churn out from time to time, it is a meaningless total when a large number do next to nothing. Leaky Caldron 14:27, 24 November 2018 (UTC)
  • Actually I'm not interested in retaining as admins those who only ever do one or two admin actions a year. I'm interested in retaining and keeping an open door for formerly active admins who might become active admins again in the future. such as retaining/reactivating more of the formerly active admins who return here after long periods of time. The problem is that once someone has dropped to a very low or zero level of activity we currently have few tools to tell who might return in the future and who will never return. So I've no problem assuming that those who have died won't be back, but with the project not quite 18 years old we have no way of knowing how many adolescents who go inactive after less than a decade of activity will return once they have retired, or before. We don't yet have anything close to a figure such as "after x years of inactivity the chance of return approaches zero". ϢereSpielChequers 17:07, 24 November 2018 (UTC)
  • Support This is a simple, non-punitive way to keep our admin roster at least a little bit up to date. Powerful tools should not be attached to inactive accounts, that's all. If people aren't using WP at all, they should not have admin tools. If they are only logging on once a year because they got an email warning, they should also not have admin tools. I agree with the proposal as written, with the one addition that a note should be put on their user talk page, AFTER the desysop, explaining what happened and why, with the assurance that it is just a security measure and does not reflect any wrongdoing on their part, and they can get their tools back via a simple request at BN. -- MelanieN (talk) 15:23, 24 November 2018 (UTC)
P.S. I very much like Isaacl's suggestion that such action be called "suspension of administrator rights" rather than "desysop". -- MelanieN (talk) 15:31, 24 November 2018 (UTC)
  • Oppose the wording as written above. There are plenty of times where I have been an active administrator even though I didn't use "logged administrative actions". Especially when I'm engaged at WP:AE, my preference is to do unlogged actions such as warnings, rather than blocks. I'm not opposed to tightening up the policy in other ways, like if someone has fewer than 10 edits per year, that might be reasonably viewed as inactive. Then again, if those edits are at administrator pages such as WP:ANI, WP:AE, comments at ArbCom pages, or anything in the Wikipedia space (as opposed to user/article pages), then I would see that as being more active. --Elonka 22:25, 24 November 2018 (UTC)
  • Support, sans 2FA and with the "suspension" wording. I've thought about this very carefully, particularly because I take the oppose comments by Risker and Opabinia very seriously. And I would be opposing if, hypothetically, the proposal were to require a new RfA. But posting a message at BN and waiting 24 hours – that's hardly a burden. I do agree with Ivanvector's analysis of partially reducing security risks (no need to let the perfect become the enemy of incremental improvement), and also with the view that we really expect active admins to be able to easily satisfy the revised requirements. Wikipedia is simply not the website that it was a decade ago. In some ways, we should expect more "professionalism" from all editors, but certainly this isn't an imposition on those users who want to have advanced permissions. --Tryptofish (talk) 22:46, 24 November 2018 (UTC)
  • Support - Regardless of the recent activity, this would be a good policy. "Retaining" admins who do not participate isn't retention.Onel5969 TT me 23:18, 24 November 2018 (UTC)
  • Oppose per Dweller. Kaldari (talk) 00:46, 25 November 2018 (UTC)
  • Weak Support As the incident involving Killiondude demonstrated, this can happen to anyone, and isn’t only limited to inactive admins. I support this only for the fact that it might be a more effective deterrent to a black hat trying to get access to vulnerable admin accounts. OhKayeSierra (talk) 01:03, 25 November 2018 (UTC)
  • Support tightening desysopping (or "suspension") rules though there is probably a better way to get around admins who may attempt to "game the system" by speedying a bullshit page they create in their userspace so they've technically logged an "admin action". Of course, if an admin just wants to keep the tools for fun rather than to use them constructively to improve the project, it reflects poorly on their suitability for having the bit in the first place, not to mention the security concerns discussed many times above. IntoThinAir (talk) 01:40, 25 November 2018 (UTC)
  • Support The potential for an admin who performs non-logged actions being de-sysoped is a non-starter for me. All it takes to stop that from happening is to do a 2-minute drop-in at requests for page protection once a year. The amount of time expense to do that is less than the amount of time expense to clean-up after a compromised account. Chetsford (talk) 05:26, 25 November 2018 (UTC)
  • Strong Oppose - I find the removal of a notification requirement to be a non-starter and contrary to our basic principal that someone should be notified before an action is taken against them. If someone is inactive, it does not mean that they will not come back nor that they cease being a member of the community. As someone who tends to come and go (and is also an admin) even if I'm not fully active at a given period, I do make occasional edits, maintain a strong, secure, and unique password, and see all messages (via notification and email) especially because I run a few bots. Further, the requirement for a "logged administrative action" as opposed to just editing seems to go against the spirit of us being here to build an encyclopedia and the goal that the appurtenant bureaucracy should just be ancillary. If someone is editing without using the tools it does not make them any less trusted or capable of using them responsibly them when they do need to use them. Further, administrators can, and do, add value by helping at WP:DYK (where I personally do quite a bit of work), WP:EDITREQ, and in other places where the tools are of value or essential even if their use is not formally logged. Finally, I agree with Risker's comments above and do not believe that this will meaningfully increase security. If we want to increase security, the strength of your password, it not being reused elsewhere, and 2FA (current technical issues and lack of support notwithstanding) are much, much more important to look at than activity. Regretfully, it looks like the group _targeting admin accounts has enough sophistication to understand a bit of our inner workings, if an outside actor were to compromise a highly active admin account (as has happened before), all they would need to do is wait for the user to be offline or asleep to act. Our default edit counter (shown at the bottom of each user's contributions page) even has a "timecard" feature (see here for mine) which graphically shows a time distribution of your edits. Even if we were to disable this feature, it is not hard to figure out when I, or any other user, is almost never online. While I strongly agree account security, especially for accounts with advanced permissions, is essential, I cannot support this as I do not believe it helps us move towards additional security and am deeply concerned it could drive away valuable and respected editors and make it harder for them to return (similarly as Dweller pointed out above). Best, Mifter (talk) 06:27, 25 November 2018 (UTC)
  • Weak Oppose I want a solution that 1. fixes this problem and 2. doesn't feel punitive to good-faith admins who for whatever reason are inactive for a while. I'm not sure this proposal does either of those things. If we want to prevent hackable accounts causing problems, require ALL admins to change their password regularly. And is there any way to show on the password reset page the results of that little handy tool Guy Macon links to below? If admins are told when they reset their password how hackable their password is, and just how attractive a _target WP is, I would assume good-faith admins would go ahead and create an unhackable phrase rather than coming up with yet another version of pa55w0rd. And if after that they still do create a crap password and get hacked, THEN they get punished lol valereee (talk) 12:21, 25 November 2018 (UTC)
  • Support. Inactive bits must be frozen. But given the number of administrators who are not convinced that security issues could be more than a "set-up to thwart Ivanka" ... we will probably have to wait for a big drama, followed by panic countermeasures imposed by SanFran. Pldx1 (talk) 14:43, 25 November 2018 (UTC)
  • Support. I would want admins to be actively using their tools, but I disagree "logged actions" being the cut-off. Instead, I would want to extend this to any activity that could not be performed by a non-admin. I would want to have a notice given for admin accounts that are performing edits on a semi-regular/regular basis for the impending removal of rights, but for completely inactive accounts the notices seem unnecessary. Only providing notices to accounts with more than just a couple of edits a month would help to circumvent the problem of admins hogging their admin privileges when they are inactive. Dreamy Jazz 🎷 talk to me | my contributions 16:52, 25 November 2018 (UTC)
  • Oppose. I have been an admin for over ten years. I am an active editor; I'm on pretty much every day. My understanding always was that admin privileges are intended to be used sparingly. I try to warn vandals rather than block and I don't waste effort blocking IP accounts that appear to come from public terminals in schools. Usually after being warned and reverted a couple of times vandals just go away. I try to help settle disputes where I can and that often makes me an "involved editor" so I sometimes have to rely on other admins if my efforts fail and blocks are needed. A few times when I did use my bit, it just made a bad situation worse. Nonetheless, there are times when I do use it and often having to wait for permission to get it back would allow damage to persist too long. I would not object to tighter authentication requirements for admins, perhaps re-authentication when the bit is used after an absence from editing (rather than relying on "keep me logged in"). But I don't think admins who are active on the project should be incentivized to use their privileges any more than they deem necessary.--agr (talk) 17:35, 25 November 2018 (UTC)
  • Support If you do not use your administrator rights you do not need them but i oppose the requirement of 2FA as not all admins have phones and the way Wikipedia uses 2FA has issues Abote2 (talk) 22:20, 25 November 2018 (UTC)
  • Oppose. Wikipedia is becoming more punitive. People should always be notified when things are planned that affect them. There seems to be a trend toward trying to make people do things in a particular way or in a particular time frame recently. I contend that this attitude is driving users away. As a volunteer organisation we should be doing everything we can to retain and encourage users. Also rushing to change policy in reaction to a specific situation is never a good idea. Morgan Leigh | Talk 22:28, 25 November 2018 (UTC)
  • Oppose. This is security theater. We are going to have compromised accounts and do need processes in place to prevent it, mitigate the damage, and allow recovery. The reduction in the size of the attack surface that would result from this policy change is simply not significant, and the consequences for editor engagement over time are considerable. The Uninvited Co., Inc. 00:22, 26 November 2018 (UTC)
  • Conditional support on the condition that any former sysop who hasn't fallen short of the 3-year lengthy inactivity rule can regain the sysop flag anytime via WP:BN. In other words, I would support this proposal for as long as it only removes the technical permission of an admin who still edits occasionally but hasn't used any admin privileges, but retains the policy permission for those admins to regain their technical permission whenever they need it back. Also strong oppose requiring the current implementation of WMF 2FA per diversity issues raised by Risker et al and the technical issues raised on phab:T172079. Deryck C. 16:05, 26 November 2018 (UTC)
  • Strong Oppose -- This won't solve any problems. Just see the recent temporary desysop of Killiondude. The account was compromised and the real editor had edited the day before. I would much rather see an actual activity requirement of say 25 logged actions per year (edits; blocks; user right changes; whatever). -- Dolotta (talk) 16:47, 26 November 2018 (UTC)
  • (edit conflict) Support the bit can be returned on request. There shouldn't be mandatory 2FA for all admins, as it might be too difficult for some. Besides, how would one get 2FA before, since if I recall users without advanced rights (admin, CheckUser, oversight, etc.) can't use 2FA. SemiHypercube ✎ 16:51, 26 November 2018 (UTC)
  • Support -- as long as it is easy enough to reinstate in extenuating cases (which seems to be the case here) no harm no foul.--Esprit15d • talk • contribs 00:02, 27 November 2018 (UTC)
  • Strong Oppose, ah, here we go yet again down the slippery slope. I've always seen admin activity requirements as unhelpful for a number of reasons, including but not limited to the effect that this would have to de-diversify the admin population, effectively shutting down the possibility of adminship to those who may not have reliable secure internet for long periods--military deployment, missionary work, humanitarian aid, and the like. Not even requiring notification adds an addition slap in the face for those who frankly have donated a lot of their free time to the project already. Andrew Lenahan - Starblind 18:54, 27 November 2018 (UTC)
  • Oppose – Right spirit; wrong proposal. Normal edits should count toward admin activity, since by editing actively, admins, who are of course all virtuous and knowledgeable, can show by example so admin actions don't have to be performed. Inform people that the bit is about to be taken away, especially because real admin activity, such as DYK actions, aren't even being counted. However, I'd make the activity requirement higher, like average one action a day, not a year. How does someone who does less vandal fighting in a year than I'm apt to do in a day get to keep their key to the executive broom closet? Dhtwiki (talk) 07:47, 28 November 2018 (UTC)
  • Support but I agree with Dhtwiki that this should just be about keeping your account active in general, not about making demonstrably 'admin' actions. To me, the point of de-sysopping inactive admin accounts is to maintain security of an account that has no one on the other end of it. If an administrator is active in any way, that means he or she is logging in regularly, (hopefully) changing the password and keeping it secure, etc. If we want to de-sysop an otherwise active sysop for lack of admin-specific activity, that's fine, but we should be doing so for all advanced permissions and separately from this proposal. CThomas3 (talk) 19:53, 28 November 2018 (UTC)
  • Oppose both requiring logged admin actions and the removal of the notice requirement. While I understand the concerns, I don't think that they outweigh the problems of tracking unlogged admin actions (I think of closing AfD's as "No Consensus" as a good example) and the discourtesy of finding your account deadminned unexpectedly even when you have been making regular if infrequent contributions to the encyclopedia. I probably came close to a year without logged actions when I was an admin, and I would have hated to have lost the bit without even a warning. Eluchil404 (talk) 23:08, 28 November 2018 (UTC)
  • Support the first part. I don't, however, see a defensible rationale to deleting the notice/contact provisions.  — SMcCandlish ☏ ¢ 😼  12:44, 1 December 2018 (UTC)
  • Oppose. I see the problem, but this is too extreme. I might support some more complex formula such as (<n admin actions in last 12 months, and <n admin actions in last 2 years), but I'd prefer to see some human discretion applied, partly to avoid setting a _target for the hat collectors. Any numerical threshold risks encouraging hat-collecting admins to make un-needed admin actions simply to game a threshold.
Most of my admin actions involve editing protected pages, and AIUI those are not logged as admin actions. Unless they are included in the total counted, the numbers will be misleading.
And I strongly oppose mandatory 2FA. I am sure that I am not the only admin who is a smartphone refusenik (a phone which needs to have a "phone" button pressed before it can be used as a phone is a portable identity crisis which I don't need in my pocket; plus my fossil-phone is way cheaper, more robust and has a 1-month-on-standby battery life) .. and 2FA basically relies on having a smartphone. Instead, I change my password frequently using my own obscure formula, and I would support an enforced requirement for non-2FA admins to change password every 3 or 6 months or so. --BrownHairedGirl (talk) • (contribs) 04:01, 3 December 2018 (UTC)
  • Support. All users are responsible for securing their accounts. Accounts with sensitive privileges should be subject to additional security measures to reduce disruption to Wikipedia. Disabling inactive privileges and requiring two-factor authentication are measures that are widely implemented in companies with strong computer security policies. As the fifth-most-popular website in the world, Wikipedia is more important than many of these companies, and should tighten its security to prevent embarrassing breaches like the ones from last month. — Newslinger talk 04:57, 3 December 2018 (UTC)
  • @Newslinger: Wikipedia is not a company, and cannot be run like one. Its editors and admins are a much more diverse set, and your comparison seems to assume that en.wp editors have the same sort of access to resources as an employee of a major tech company.
Its editors are unpaid and receive no equipment from Wikipedia. They may not own a computer, and do their editing on someone else's machine or on some sort of public computer (e.g. library, school, university, work, housemate, family).
So any requirement which presumes ownership of particular equipment merely reinforces the already-massive systemic bias in en.wp's admin base, and erects a further barrier to editors on lower incomes, editors from remote areas or developing nations, editors with disabilities etc. --BrownHairedGirl (talk) • (contribs) 07:40, 3 December 2018 (UTC)
​Two-factor authentication doesn't require any additional equipment beyond what is needed to edit articles on Wikipedia. If an editor can run a web browser or a Wikipedia app on their own device, then the editor can also run a free authenticator app (list) or password manager (list) on their device (regardless of whether it's a desktop, laptop, or smartphone). For editors without their own devices, there are web-based password managers (such as KeeWeb) that also provide two-factor authentication at no charge. — Newslinger talk 08:54, 3 December 2018 (UTC)
  • @Newslinger: there may indeed be workarounds for the tech-savvy. But those workarounds increase the technical burdens on admins who are mostly chosen for their editorial judgement and understanding of policy, rather than for technical skills.
You really don't seem to get my point that Wikipedia is not a company and its editors and admins are not employees. This is a wholly different sort of organization, and these attempts to import corporate processes don't recognize that crucial distinction. I know some truly wonderful editors who would make brilliant admins, but who are so non-techie that they only ever use the visual editor. They would run a million miles from the complexity of 2FA, but they precisely the sort of people whose social and editorial skills are much needed in the admin corps. I would love to see more of them becoming admins; the role should not be the sole preserve of tech-heads. --BrownHairedGirl (talk) • (contribs) 09:07, 3 December 2018 (UTC)
​I made the "company" comparison to show that Wikipedia's security practices are weaker than those of less important organizations. This was not an assertion that Wikipedia is like a company, or that its editors and admins are like employees. In my opinion, two-factor authentication is much easier to learn than wikitext, and is a reasonable requirement for sensitive privileges on a very important website. — Newslinger talk 09:34, 3 December 2018 (UTC)
Newslinger, comparisons with a company have led you down a path where you are applying inappropriate measures of reasonableness, and looking at the perceived importance of the organisation rather than the extent of potential harm and the impact on users. Please do not underestimate the extent of the barrier which is placed in the way of many very productive editors and admins by technical measures which a tech-savvy person like yourself would find trivial.
As a voluntary group, en.wp editors include very many people who would never be remotely acceptable to the personnel depts of any corporate. Their contributions are valuable, and their needs are very different to those of a corporate employee.
Most of the potential for damage has been removed by https://phabricator.wikimedia.org/T150826, which prevents a blocked admin unblocking themself. A hijacked admin account can now be securely blocked until the issue is resolved.
And do remember that this is "the encyclopedia which anyone can edit". Our security is social rather than technical. --BrownHairedGirl (talk) • (contribs) 11:29, 3 December 2018 (UTC)
  • Oppose. Tweaking the activity requirements every time someones account with bad password gets compromised is just security theater. Also strong oppose requiring the immature WMF 2FA per diversity and editor retention issues raised by Risker, Andrew Lenahan and others, and the technical issues raised on phab:T172079. jni (delete)...just not interested 06:27, 3 December 2018 (UTC)
  • Oppose, forcing admins to have logged actions and not telling them they have forgotten to do so doesn't strike me as helpful. It is trivial to fulfil the logging requirement (delete and undelete your sandbox) so this is useless as a measure of activity. And anyway, what jni says. —Kusma (t·c) 11:18, 3 December 2018 (UTC)
  • Oppose, hard cases make bad law. Stifle (talk) 15:20, 3 December 2018 (UTC)
  • Oppose - per Risker, pretty much. Also, I'll join the list of people opposed to compulsory 2FA, at least while using it requires people to retain one-time keys indefinitely. The Land (talk) 15:40, 3 December 2018 (UTC)
  • Strong support. Best proposed modification to this policy in quite some time. As usual the opposition is a storm in a teacup around something that will pose no threat to the project's operations. It will on the other hand shut down the yearly charade performed by people who have no good reason to continue calling themselves administrators.  — Scott • talk 15:48, 3 December 2018 (UTC)
  • Strongly oppose: this doesn't reduce risk, per Risker, so it's pointless. It's also counterproductive. We need more experienced admins, not fewer, and admins are usefully so even without logged actions. Much of what we do as admins isn't logged. Jonathunder (talk) 02:24, 4 December 2018 (UTC)
  • Oppose A solution for a nonexistent problem. We need more admins not fewer. Λυδαcιτγ 09:57, 4 December 2018 (UTC)
  • Oppose I don't use my admin abilities that often, much less frequently than I edit. And I am one of the most experienced admins on Wikipedia. Does reviewing deleted edits count as an administrative action? Other people have made excellent points in opposition about the broader implications. --The Cunctator (talk) 15:15, 4 December 2018 (UTC)
  • Mildly oppose the 12 month limit. Deactivation of inactive accounts must be done somehow (and BTW, we need to think about reusing user names, if we do not already; if WP last for decades I hope someone will be the next Nabla :-). But legislating in a hurry is bad (as Risker said), the rule is too simplistic, and no warnings feels like punishing. Strongly Oppose 2FA, when it came up I gave it a look, it was almost impossibly convoluted, wikipedia is less and less a wiki (as in easy to edit) let's not make it something only for the special ones. Note I am an almost inactive admin, I edit once in a while, I have made none or almost none administrative action in the last ya«ear or so, mostly because I went back to college so I *am* busy. I have been considering temporary resigning, because I do not want to fool the statistics; and I would not mind a *friendly* reminder in that sense, but this is not it at all. - Nabla (talk) 23:02, 4 December 2018 (UTC)
  • Support, but strongly Oppose mandatory 2FA. Kudpung กุดผึ้ง (talk) 02:15, 5 December 2018 (UTC)
  • Support As an editor and former admin who has returned to the project very recently, I was initially surprised to find that administrative work had become a "very big deal," mostly on the basis of these identity hacks. So, I have to support any resolution which would seemingly improve the security of editors in general and admin accounts particularly. In that many of the identity hacks have been perpetrated by inactive admin accounts, I should thank @xeno in this space, for his diligence in deactivating my account when he did. I should also note that as far as editing the project, I don't miss the extra tools very much at all. I think See Recent Changes would be useful to me as I could be doing more cleanup editing. Most of you are doing excellent work, and it is appreciated by me. Hamster Sandwich (talk) 04:22, 5 December 2018 (UTC)
  • Oppose If they aren’t active enough, they wouldn’t even know they got a admin revoke. No-go. We should get a better criterion to keep adminship, for example 100 admin actions and 500 edits in a year, etc.. Oshawott 12 ==()== Talk to me! 12:44, 6 December 2018 (UTC)
  • Oppose Ugh, no just no. Whispering(t) 15:48, 6 December 2018 (UTC)
  • Oppose. Airbornemihir (talk) 10:44, 7 December 2018 (UTC)
    The case of Revolving Bugbear is somewhat pertinent here. I'm really not fond of the way they were singled out for attention, and specifically asked to "at a minimum" justify their retention of the administrative toolset. I think that's an undue "minimum" ask to make. I also disagree with the judgement call to remove their permissions after their ambivalent-at-best statement at the bureaucrats' noticeboard. This proposal is trying to codify the same kind of judgement call on an automatic (or semi-automatic, since it's done by individual bureaucrats, not software) basis, hence I am opposed. I note the amount of tedious work made for admins, and the harm done to the 'paedia, when an admin account is compromised. I would suggest searching for another solution to solve that problem. Airbornemihir (talk) 19:39, 7 December 2018 (UTC)
  • Oppose per Risker. -- Tavix (talk) 19:17, 13 December 2018 (UTC)
  • Oppose as written. I am not against this in principle, but the proposal is problematic in a number of ways. Not notifying is unforgivable. If a notification prompts a user to come back and do some admin work, that is a good thing, not a problem. Also, as others have pointed out, there are a number of tasks that require admin rights but do not get logged. DYK has already been mentioned, OTRS volunteers are another example. They need to read deleted pages. SpinningSpark 09:56, 15 December 2018 (UTC)

Questions about admin actions that are not logged as such

  • Comment - In theory, I support tighter guidelines on whether or not an admin is really making use of their tools. However, as pointed out above by Jo-Jo Eumerus and others, there are certain actions that require admin access, but are not logged as admin actions. DYK is a prime example, as some editors have become admins specifically for helping out on that project. There are some admins I see using their tools at DYK, and don't run across them elsewhere, but are vital to assisting that project. Devise a tool that logs ALL admin usage of tools, and I might be more willing to support this. — Maile (talk) 19:50, 22 November 2018 (UTC)
    DYK has come up a couple times. I'm not so familiar, but what do admins do at DYK that requires admin access but isn't logged? IMO it should be logged, or it should not require admin rights. Ivanvector (Talk/Edits) 19:58, 22 November 2018 (UTC)
    They use editprotected. --Izno (talk) 20:01, 22 November 2018 (UTC)
    Ah I see. Surely we could (should?) log edits to protected pages? Maybe that's a separate discussion too. Ivanvector (Talk/Edits) 20:10, 22 November 2018 (UTC)
    @Ivanvector: technically they are already logged, just not in any manner that is easy to find. Obviously "group" edits (like MediaWiki:, .json files, etc) are easy to filter, but the other ones are not. I wonder if this is a red herring though (i.e. how many admins are completely inactive in all logged actions but still routinely use editprotected?) — xaosflux Talk 20:43, 22 November 2018 (UTC)
    Does it require admin tools to create and maintain bots and scripts? That's also a key part of DYK. — Maile (talk) 20:37, 22 November 2018 (UTC)
    I don't believe so, I think anyone can operate a bot if it's approved, unless it's a bot with admin rights. Scripts might require interface admin now, I'm not sure. Ivanvector (Talk/Edits) 21:08, 22 November 2018 (UTC)

The last 10 humans, and the operator of the last bot, to edit Template:Did you know, made their most recent logged admin action this long ago:

Admin Last logged
admin action		 Days ago
Alex Shih 2018-11-18 4
Anarchyte 2018-11-22 0
Art LaPella 2018-07-13 132
Shubinator (operator of DYKUpdateBot) 2018-03-26 241
Dumelow 2018-11-05 17
Fish and karate 2018-11-21 1
Fram 2018-11-22 0
Gatoclass 2016-09-22 791
Huon 2018-11-21 1
Mike Peel 2018-11-09 13
Vanamonde93 2018-11-19 3

As you can see, Gatoclass is the only one who would lose their adminship with this proposal. Thryduulf (talk) 22:51, 22 November 2018 (UTC)

Thryduulf of the ones you list above, Shubinator is unique in that his bots keep the process running. He's the only one who would know what admin actions he's taken that don't show on his normal logs - but I think DYK would be up a creek without him behind the scenes. You don't list Wugapodes, and his logs look pretty active, but he operates WugBot that is also essential to the DYK processes. The others are directly involved in the edit protected areas of DYK that directly affect what appears on the Main Page. — Maile (talk) 01:34, 23 November 2018 (UTC)
I believe I wasn't listed because I'm not an admin, only pending changes and (recently) new page reviewer. WugBot doesn't have editprotected rights and doesn't need them as the approved page isn't under full protection, just the Queue for the mainpage. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:47, 23 November 2018 (UTC)
  • Regarding the questions about logging, while it's not as easy of a log, we could make an edit filter such as ((action = edit) & (page_restrictions_edit = sysop)) to "log" protected edits such that they could be "counted" by any inactivity bots (which really is how we would look for inactives in practice). — xaosflux Talk 05:28, 23 November 2018 (UTC)
  • Example of logging the use of protected edits. — xaosflux Talk 12:55, 23 November 2018 (UTC)
Although my understanding of logging administrator actions is dim, I believe I could have been desysopped for one year of miscalculated inactivity from Sept. 15, 2014 to Sept. 25, 2015, and also Sept. 26, 2012 to Apr. 22, 2014. That's logged actions only. Realistically, I'm far from inactive; I proofread everything on the Main Page, not just Did You Know. So it isn't just Gatoclass. But if you'd rather fix typos without me, my business could use more attention. Art LaPella (talk) 06:03, 23 November 2018 (UTC)
  • The fact that just in the last 10 admins to have processed a DYK already 1 of them would be removed means that clearly DYK is a necessary tagging. In preference, any edit of a protected page should also count. Nosebagbear (talk) 13:46, 23 November 2018 (UTC)
  • So, if I'm understanding correctly, the only admin action we've identified so far as definitely an admin action and definitely not logged is edits to protected pages, yes? Let's set up a log for that. I don't think anyone here yet has said we shouldn't, and lots of us have said we should. Ivanvector (Talk/Edits) 14:50, 23 November 2018 (UTC)
    @Ivanvector: I'm working on one (Special:AbuseFilter/942) - there is another admin action that isn't logged at all: viewing deleted versions. Note, those 'actions' are not currently counted toward activity. — xaosflux Talk 14:54, 23 November 2018 (UTC)
I saw that filter you're working on, it looks good so far. As for viewdelete, are there really that many admins that only look at deleted pages and do nothing else? Ivanvector (Talk/Edits) 15:02, 23 November 2018 (UTC)
Indeed, while you can have admins look just to answer individual's questions (why was it deleted etc), usually I'd expect it to be associated with one of:DELREV, CSD, Salting/Unsalting, copyvio, block discussions. Nosebagbear (talk) 15:21, 23 November 2018 (UTC)
I mean I'm sure there are cases where you just look at a deleted page and then do nothing else. But does anyone only look at deleted pages, but never do anything with them, or any other logged actions? That seems unlikely to me, but then again I was wrong about DYK and editprotected, so as it turns out I don't have all the answers. Ivanvector (Talk/Edits) 18:25, 23 November 2018 (UTC)
Personally, I feel viewing a deleted page to be something that an administrator is authorized to do, but not an administrative action in itself. Using the knowledge gleaned from this to weigh in on a discussion would be an administrative action. However I don't see any way to log this automatically. isaacl (talk) 23:17, 23 November 2018 (UTC)
  • Also noting that I oppose counting non-logged admin actions that is next to impossible to track after the fact. Seriously, it really isn’t that difficult to do one completely non-controversial logged action a year, and handwringing over something that is easily reversed and can be easily fixed for a year isn’t justified, especially given the extra work that would be required. I would support keeping the one year notice, though. TonyBallioni (talk) 22:35, 23 November 2018 (UTC)
  • It does appea that DYK is the single exception where an admin is actually doing useful admin work without logging any actions. As demonstrated above thsi would impact only one single admin's rights. That doesn't seem sufficient cause for not doing this, we can just IAR for that one admin. Beeblebrox (talk) 02:09, 24 November 2018 (UTC)
    At least two admins. And probably Shubinator. And it's the complete Main Page, not just DYK. Art LaPella (talk) 03:49, 24 November 2018 (UTC)
    I actually provided another example in this very thread.--Ymblanter (talk) 08:24, 24 November 2018 (UTC)
  • I think that one of the most valuable things that administrators do is say no....say no to blocking someone, say no to protecting a page, say no to deleting... And yes, there's lots of work happening in places like Arbcom enforcement and even admin noticeboards by admins who don't need to take logged admin actions in order for them to be effective as administrators. If someone is actually around and doing things, it really doesn't matter whether or not they're doing logged admin actions. I will make a proposal above. Risker (talk) 02:17, 24 November 2018 (UTC)
    • But do you think it is reasonable for an administrator to say no to literally everything? All they have to do is say yes one time (or however many actions the limit is determined to be). If we have a sysop that is saying no to every request, I would find it very hard to believe it is not a WP:POINT situation, and they should not be an admin anyway. Natureium (talk) 13:46, 24 November 2018 (UTC)
  • As I understand it, there is currently no logging of the use of admin accounts to view deleted edits. This is one of my most common uses of the tools, for example in checking out a candidate or potential candidate at RFA. I'm actually a little uncomfortable about the idea of an admin account quietly lurking and occasionally being used to view deleted edits, but we have in the past had a very active nominator who made little or no use of the tools apart from viewing deleted edits. So I would welcome some sort of log that at least recorded when an admin had last looked at deleted edits, provided it didn't log what specifically they viewed. ϢereSpielChequers 13:32, 24 November 2018 (UTC)
    I've created a AF log for "protected edits" that can be seen here: Special:AbuseFilter/942 - a 'viewdelete' log would require software changes so its a bit hard. For example @WereSpielChequers: can you point out any specific admins who have gone a year with no protected edits, no logged actions - that you think are still using viewdelete usefully? — xaosflux Talk 15:52, 24 November 2018 (UTC)
    Great, thanks.--Ymblanter (talk) 16:09, 24 November 2018 (UTC)
    @Xaosflux Thanks. As I said we had an active nominator in the past who as I remember it had not otherwise used the tools for some time. I don't know if there is such an admin at present. But there are plenty of occasions where view deleted is useful, if you are about to recreate a previously deleted page sometimes the only way to know that the previous A7 deletion was of a "14 year old professional skateboarder" and unlikely to be the same person as the diplomat or academic of the same name who you are writing about. ϢereSpielChequers 16:42, 24 November 2018 (UTC)
    Will this filter be automatically disabled if it matches more than 5% of edits, or does this wiki have a different setting for $wgAbuseFilterEmergencyDisableThreshold? I don't see anything about this on Wikipedia:Edit filter. I've run into that problem a lot on other wikis where I've worked with abuse filters, and I'm guessing the restriction was put in place to prevent situations like this incident that occurred here. Or is this not a concern because there are so many edits to English Wikipedia that it would never reach 5%? ♫ekips39 (talk)❀ 22:23, 24 November 2018 (UTC)
    @Ekips39: the sheer amount of other edits should keep this down, it is currently running at about a 0.02% hit rate against edits. — xaosflux Talk 04:20, 25 November 2018 (UTC)
    @Xaosflux: Is there any way to make meaningful statistics out of the filter log - which pages are most edited, and who are the administrators with the largest numbers of edits (and possibly smth else)? --Ymblanter (talk) 17:12, 6 December 2018 (UTC)
    @Ymblanter: these can be queried programmatically live (example - click SUBMIT) , from the database, or off of dumps, so someone could make a bot generated report (request at Wikipedia talk:Database reports). — xaosflux Talk 18:00, 6 December 2018 (UTC)
    @Xaosflux: Thanks, I will try to follow up when I have a bot more time.--Ymblanter (talk) 19:02, 6 December 2018 (UTC)
  • I don't think this is just DYK. Another group that has come up in previous proposals of this sort is the OTRS volunteers. A necessary part of their work is to read deleted articles when they are queried. Reading a page, even a deleted page, is not logged anywhere, so I don't see how a bot could make an exception here, unless it automatically excepted all OTRS volunteers. There are bound to be other edge cases that haven't come to light, which is why I think silently desysopping without notification is not acceptable. Not only must there be notification, but there needs to be a formal channel to appeal so the desysop can be cancelled before it takes effect. SpinningSpark 10:09, 15 December 2018 (UTC)
  • There's a few more examples of "somewhat logged" but not in the exact way. Correcting Main Page errors is "logged" but in the forms of edits and if you edit a lot of WP namespace, it can easily escape detecting the logged action. Same for requiring an admin to close a deletion discussion. OhanaUnitedTalk page 01:10, 25 December 2018 (UTC)
  • The issues which I can come up with of using one's admin bit without an obvious way of finding it:
    1. Unblock review - while some of these require either an unblock action or a block change to disable talk page access, most don't; any which don't have no obvious log to find.
    2. Viewing deleted edits, apparently an issue for OTRS users.
    3. Editing protected pages. While the edit is clearly logged in the page history, seeing several days, weeks or months later that the page was protected at the time isn't self-evident.
    4. Moving a page to an existing title other than reversing a redirect with no history - while the deletion itself is logged, so is a redirect-reversal move done by a non-admin.
עוד מישהו Od Mishehu 13:32, 9 January 2019 (UTC)

Alternative ideas

This has been a very good discussion and I'm very impressed with the diversity of comments, thanks everyone. I've definitely learned some things and had my assumptions challenged. Based on the key points raised up to this point I have an alternative suggestion:

  • An account is considered inactive when it has no presence on the website at all (no edits, no logged actions) for 91 days.
  • When an account is flagged inactive, we force a password reset and send the accountholder instructions to change their password, by email (if the account has email enabled) and with a notice on their user talk page. (The current password reset instructions are here)
  • If/when the user wants to resume using their account, with all its previous permissions, all they have to do is reset their password.
  • Since the password must be reset before the account can be used again, no permissions are changed (unless the account becomes subject to the lengthy inactivity policy)
  • I believe requesting a password reset counts as a logged action; it's present in the Checkuser log at least but of course that's not public, and it rotates after 90 days anyway. At any rate, the accountholder resetting their password should reset the 91 day clock, and if someone wants to string along keeping their admin access by resetting their password every three months, that's not really a security issue.
  • 91 days is just an illustrative number I pulled out of my ass, it could be any reasonable number.
  • Two admin accounts (at least) and several others with other advanced permissions have been compromised while we've been talking about this.

I think that this catches all of the concerns raised about admins who are active but don't log actions, about automatic removal of permissions, and about accounts being hacked due to old reused password hacks on other websites. Some issues are:

  • Accounts that don't have email enabled or accountholders who lose access to the email they provided on sign-up could be locked out. I think these situations can be handled by contacting Arbcom but I've never had to so I don't really know.
  • Accounts that are active will never be required to change their password, but that's already the case.
  • There is nothing in this alternative (nor in the original) that requires strong passwords or extra authentication factors, other than having an email address.

Any thoughts on something like this? Ivanvector (Talk/Edits) 15:52, 24 November 2018 (UTC)

The WMF security team is actively working to introduce technical measures that will prevent future attacks along the same vector that compromised the most recent two admin accounts. I'd argue that they are the experts and should be the ones making the call in this area. Us debating the pros and cons of each potential security measure not only exposes all of their cons in public, making it easier for an attacker to work around, but also is far less effective because most of us aren't experts in the area.
My suggestions is to limit discussion on this topic to what would generally promote account security, without getting into detailed technical solutions. De-flagging inactive accounts is good because it reduces the attack surface. I feel like any of these discussions are more about punishing the barely-active admins who dare to have other things going on in their lives than editing Wikipedia rather than actually being about security best practices, but I guess it's at least being considered. -- Ajraddatz (talk) 16:59, 24 November 2018 (UTC)
I disagree pretty much with everything you've said. "The office is working on it" is no substitute for community discussion on local policies, especially since the security team does things in a silo, slowly, with no accountability to the actual users of this project. There is no sinister ulterior motive here to punish anybody, or drive anyone away, or ... anything, I apparently can't anticipate the bullshit schemes people are going to insist on reading into this. It's about security best practices, and responding to an actual and ongoing security threat in any way that the local community is capable, because the security team has not. You seem to think that this hacker is an idiot and isn't already aware of all the things being discussed here, like these are brand new ideas that haven't already been implemented by security-conscious websites pretty much everywhere in the world for years now. The website haveibeenpwned.com has been tracking security breaches for five years of exactly the sort of info that's very likely being used to hack idle accounts here, and the best innovation we've had from the WMF in that time is a beta 2FA implementation that's problematic for many users, if the WMF allows them to use it at all. We don't need more vague promises that the under-resourced WMF has "top men working on it", we need a response now. Anything less is grossly irresponsible. Ivanvector (Talk/Edits) 18:47, 24 November 2018 (UTC)
I think the hacker is aware of discussions like this, or at least able to find them. I'll email you about some of the other points. -- Ajraddatz (talk) 18:55, 24 November 2018 (UTC)
Just to note that how we are having admin-account vandalism has been publicized (even though it would take just a bit of reading on en.wiki to figure out what's been happening). This basically means that the security hole due to the ability hack into admin accounts could get worse. --Masem (t) 01:48, 25 November 2018 (UTC)
Would it help to send an e-mail to all administrators alerting them on the incident and asking to evaluate the strength of their password and to change it if necessary? Those who do not have e-mail enabled can get a talk page message.--Ymblanter (talk) 10:41, 25 November 2018 (UTC)
  • A simple alternative While not having much of the finesse of Ivanvector's latest proposal in this section, using recent-ish changes it would (I believe) be trivially simple to assign the bit as a temporary (365 day) permission, with an expiry on the anniversary of the admin's initial grant of the bit. Perhaps a 24hr pause before re-granting to anybody who had absent for a significant period. Simple to do, no new infrastructure needed, no advertising of inactive accounts - I think this meets the requirements. Cabayi (talk) 14:28, 27 November 2018 (UTC)


Separate section for comments that are only about 2FA

  • Regarding 2FA, I don't remember (or just don't now, really) if anyone has access to stats on which accounts have it turned on or not. If we do, and we're not yet comfortable requiring it to be turned on for admins, maybe we can do something like enforce periodic password resets for admins that don't opt in. That's not part of this proposal, I'm just throwing out ideas. (I have 2FA turned on, ftr) Ivanvector (Talk/Edits) 19:27, 22 November 2018 (UTC)
    Well, I have a password which can not be broken. I do not want to turn on TFA because I (almost) do not use a cell phone. I am not sure why WMF thinks they are more clever than I, and I am already unhappy with 2FA requirement for interface admins - I will possibly have to resign my interface admin rights, but if RFA is required for all admins, I am not sure what I am going to decide. If you want to lose admins with zero benefit, this is probably the way to go.--Ymblanter (talk) 19:33, 22 November 2018 (UTC)
Neither a data plan nor a smart phone is required. All 2FA processing is done off-line, using a seed number and the current time to generate a key. Apps such as Google Authenticator and FreeOTP can run on any Android or iOS device without a data connection (and FreeOTP can be downloaded on your PC from here and sideloaded onto an Android device if WiFi isn't available for installation). If you do not have a smartphone/pda/media player that runs Android or iOS, you can get PC-based programs to generate the codes (WinAuth and Authy seem to be the most popular, and there are more options available for Linux-based computers such as gauth and oathtool). --Ahecht (TALK
PAGE) 19:46, 26 November 2018 (UTC)
This is a good discussion, but I've broken it out from the main proposal so as not to distract too much. I like our 2FA implementation because I always have my phone with me, and because my phone is also my authentication device for my office email, but of course it's not perfect for everyone. We could fall back on the "email you a code" type 2FA that some other sites use (Steam is one, and I hate it, my email server is slow) if it were possible to choose different authentication methods. Again, just a thought. Ivanvector (Talk/Edits) 19:55, 22 November 2018 (UTC)
In light of the number of reset requests I am wondering if the current 2FA methods run too high a risk of getting locked out of one's account. Besides, not all people are tech savvy enough to work with one device 2FA or have more than one device available at any time. Jo-Jo Eumerus (talk, contributions) 20:36, 22 November 2018 (UTC)
  • You would have lost me as an admin if you'd required TFA. Not only is it far beyond my level of technical comfort, and makes it all too easy to get locked out, I'm not going to spend $400 plus data plan for a smartphone for Wikipedia or anybody else. Massive imposition for little gain to the project in terms of security. Yngvadottir (talk) 22:55, 22 November 2018 (UTC)
  • Ditto. I act as an admin as a favour to Wikipedia, sysop status isn't a favour Wikipedia does to me. I have no intention of committing to permanently owning—and having permanent access to—an expensive piece of technology which requires a permanent and expensive subscription. purely because Wikipedia is having one of its periodic bouts of security paranoia, and if that means someone else has to clean out CAT:EX instead of me I believe I can live with the loss. ‑ Iridescent 23:01, 22 November 2018 (UTC)
@Iridescent: I can understand where you, Ymblanter, and Yngvadottir are coming from in relation to having 2FA be a requirement, but it's not as much of a commitment as the ghastly WP:2FA leads on. The most popular applications for this process are for mobile (namely Google Authenticator and Authy), but PC-based applications exist too. There are a few listed here, and there are others, like WinAuth for Windows. If you use Google Chrome, Authy has an available plugin. Unfortunately, I was unable to find any for Mac (that were not already listed) or Firefox. I didn't bother looking for Safari ones, and Brave, along with Opera I believe, primarily use Chrome extensions. Internet Explorer/EDGE are both a mess, so I'd recommend to anyone using those to swap browsers anyway. If losing the codes is what your worry about, scratch codes are generated when you enable 2FA. Email these to yourself and you'll never lose access to your account, even if you lose or change device. Anarchyte (talk | work) 23:33, 22 November 2018 (UTC)
gauth is available for Firefox. I should also note that Google Authenticator does not require a "perminant and expensive subscription", and it doesn't even require any internet acess beyond the initial installation (which can be done via WiFi). Used android devices are readily available cheaply ($10-$20) without a data plan if you don't need the latest and greatest flagship model. --Ahecht (TALK
PAGE) 19:53, 26 November 2018 (UTC)
  • Just noting as I did above that there are multiple functionaries that do not have 2FA, and for a variety of reasons, I would not even want to force this on CheckUsers or Oversighters, including but not limited to the fact that the security paranoia that Iridescent describes is very real and there are some plain insane ideas on functionary account security out there and there is a part of me that fears making this a requirement would be a slippery slope to some really dumb measures that would make a lot of people quit (yes, slippery slope is a bad argument, but WMF projects tend to make technical changes all at once if they ever happen.)
    That was all about functionaries, who I think should have a higher level of account security than admins because of the ability to access personal data. If we currently don't require CU/OS to do it, and I don't think we should, we certainly shouldn't extend the requirement to admins without those tools. TonyBallioni (talk) 01:36, 23 November 2018 (UTC)
    @TonyBallioni: it is being discussed see phab:T197160. — xaosflux Talk 05:55, 23 November 2018 (UTC)
    Xaosflux, thanks. -revi pointed me to the CU one and one for changing user rights. My general view on this is what I said in the CU one: there is no world where it should be more difficult to run a CU than it was for me to wire money to buy a house, which is an accurate description of some of the suggestions that have been made re: 2FA and the CU tool. TonyBallioni (talk) 06:17, 23 November 2018 (UTC)
  • Wikipedia, and the entire Wikimedia movement, is committed to creating and maintaining a diverse community. That means including people who have limited access to technology (in some cases, even limited access to software), people who do not have a lot of money, people who live in countries where it is not legal to own certain types of technology (or could result in significant state surveillance if owned). This is not an abstract concept - I personally know administrators who live well below the poverty line, some of whom don't even own their own computers; others who can't afford to maintain a second piece of technology like a mobile phone; and still others who live in countries where using 2FA would probably result in their being incarcerated. Frankly, there's almost nothing that an admin account can do that will result in any real level of off-wiki scrutiny. Admin accounts that go rogue are pretty easily globally locked. I also completely and fully endorse everything that Iridescent said. This is security theatre and is completely out of proportion to the problem it's trying to solve. Risker (talk) 04:51, 23 November 2018 (UTC)
    • Risker, not to mention that the most recent confirmed account compromises involving stewards (which *actually* could have had real life implications given the potential access to CU data on multiple projects) could not have been stopped by 2FA. TonyBallioni (talk) 04:59, 23 November 2018 (UTC)
      • @TonyBallioni: Would you be able to link me to these compromises involving stewards? I haven't been keeping up, but I don't entirely understand how 2FA couldn't have stopped it (unless their computers were infected, in which case nothing would have prevented it as they were already logged in). Anarchyte (talk | work) 05:05, 23 November 2018 (UTC)
I can confirm it has happened, but currently there is no on-wiki postmortem. — regards, Revi 05:10, 23 November 2018 (UTC)
And I can confirm that even those stew with 2FA were compromised. I can't talk about the details per BEANS (and other security constraints). — regards, Revi 05:12, 23 November 2018 (UTC) [ Clarification: The stew with 2FA compromised is NOT related to this incident. I'm talking about the past incident. — regards, Revi 03:42, 25 November 2018 (UTC) ]
Thank you for the (albeit restricted) clarification, -revi, though I can't help but think that something else must have also played a role in the compromising of the accounts. Having two separate devices prevents malware from getting to both the username and password, and the ever-generating 2FA code (I could give you my current 2FA code and it would be useless by the time you read this message). This is especially true given the major authenticators do not use accounts and are wiped if they're reinstalled (and, in the case of iPhones at least, are not saved to iCloud or iTunes when backed up to a computer). If someone's LastPass or 1Password are hacked and their 2FA system is compromised, then its not the fault of the system but rather the poor security employed by the account holder. This is all under the assumption that all the issues were at the user's end and that someone didn't just walk up to a computer with a logged in account (in which case ∞FA wouldn't have prevented it). Anarchyte (talk | work) 05:30, 23 November 2018 (UTC)
Requiring someone to own two separate pieces of expensive technology in order to be an administrator on a Wikipedia project is completely inappropriate and extremely exclusionary to anyone who doesn't have the ability to pay out thousands of dollars a year. We choose administrators because they are sensible, not because of their bank accounts or geographic location. Americans in particular seem to find it shocking that in a lot of countries, the phone that costs $200 in the US costs six months' wages, and that in other countries the typical internet connection costs 10-15 times as much as the average American family will pay. I pay about 3 times as much as the average American for considerably less access. Risker (talk) 05:55, 23 November 2018 (UTC)
@Risker: I noted this in a response above, but you do not need to devices to enable 2FA. Sure, it's more "secure" to use more than one, but downloading WinAuth for Windows (which has an extra layer of protection through a password and locking the data to your Windows user account) or Authy for Chrome accomplishes the exact same task. The only thing preventing someone from installing those pieces of software (or a Mac equivalent on this list) would be if the device has restrictions preventing non-vetted exes from running or if they are locked to a clean web browser.
I tested WinAuth while writing this response and it was very intuitive. See here for an image gallery explaining the process. Anarchyte (talk | work) 06:45, 23 November 2018 (UTC)
Good on you for trying to find a solution, Anarchyte; I do appreciate the effort. But again, it is entirely dependent on the user owning certain technology. It does not address the person who edits from school or public libraries, for example; as I've worked my way through the Wikimedia world, I've learned that what we take for granted here in the "Western" world is not the norm in the rest of the world. The WMF has already identified increased diversity as a critical goal in the coming decade, and so solutions need to be developed that not only accommodate but are actually focused on ensuring that people who don't own computers/smartphones can actively participate in our projects, and there are quite a few projects of languages from the poorest countries in the world. I'd like to encourage you to think more about how we can ensure that those projects can have their own admins - because we all have seen that once rules like this get applied to enwiki, they go through all of the Wikimedia projects unless there's an extremely concerted effort by a very big player (like German Wikipedia, for example). Risker (talk) 09:13, 23 November 2018 (UTC)
@Risker: Hmm, yeah. I didn't consider the precedent this would set. 2FA is a very loose term and doesn't have to be auto-generating 30-second-life-span codes accessed through secondary devices. An idea Ivanvector mentioned above, that I've also had experience with, is having codes emailed to a user. These will last longer (a few hours), have basically the same effect (prevent people from entering an account through a username/password breach), but will be slightly less secure due to the account's standing being entirely dependent on one outlet (the email address). Another idea that Steam and a few other applications use, like Facebook and Google, is remembering devices rather than browsers. I have literally no idea how this could be implemented (especially as it's a website rather than an app), but the gist is to have it so the user sets a device as being "okay" and then when the user logs in from these devices, it won't ask for verification. This prevents easy log-ins from hackers with one's username and password but doesn't hinder the account holder (usually). Anarchyte (talk | work) 10:03, 23 November 2018 (UTC)
"Remembering devices rather than browsers" is a total non-starter. As Risker says, it's easy for the core "relatively wealthy middle-aged people in Five Eyes countries" editor base to lose sight of the fact that sizeable chunks of the editor base don't operate on the same "home computer and a cellphone" basis. We have people who edit from work where they might be using a different terminal each day; people who edit from public libraries where it will obviously be inappropriate to install software; people who live in places China and Belarus where using any kind of secure system will make the authorities assume you're up to something and start prying into your private life; a fairly large contingent of serving military who edit Wikipedia as a hobby in their downtime on base and for whom installing unauthorized software on the computers or suspicious activity on their personal devices would likely get them locked up… If there were a genuine, serious issue to address then it would conceivably be justifiable to de facto ban particular chunks of the editor base from becoming admins, but since nobody's demonstrated any problem more significant than "a handful of admins used the same password for Wikipedia and Twitter and failed to change it when Twitter's password database leaked", that would seem to be a sledgehammer/nut situation. ‑ Iridescent 10:31, 23 November 2018 (UTC)
You're right, Iridescent. The email idea was the one I was going with to resolve the issue of not having a designated device and the "remembering devices rather than browsers" was to try to alleviate the concerns of those who think 2FA is too much of a hassle. Apologies if this wasn't clear. Anarchyte (talk | work) 10:48, 23 November 2018 (UTC)
(edit conflict) Without saying too much, this really wasn't a 2FA problem. I'm not anti-2FA (I use it myself and recommend anyone with advanced permissions where it is practical do so), but I also recognize there are valid reasons not to have it. Some financial. Some personal. Some just ease of using the technology, which can be an issue. It isn't a silver bullet and while it does provide an added layer of security, the fervor with which it is promoted when a high-profile compromise happens can miss the point that it is simply one tool for protecting your account, and that people should take reasonable steps to have a secure account as fits their particular situation. Mine allows for 2FA. I know of several functionaries where their situation doesn't allow for it. They all take reasonable precautions with their accounts, which is really all we can ask of them. What I would really like to see is a WMF password audit, as that would likely be a much more high yield activity, but I suspect that isn't happening anytime soon. TonyBallioni (talk) 06:53, 23 November 2018 (UTC)
Mandating 2FA would impose additional hassle on hundreds of administrators. And what problem would it solve? We had a compromised admin account. It made 8 or 10 admin actions, it was globally locked, the actions they had made were reverted, done. Pragmatically in terms of "person hours" it is much quicker to resolve such issues in the way we currently resolve them then it would be to make every administrator jump through 2FA hoops, all the additional hassle for stewards resetting passwords when people bodge up their login or lose their phone, and so on. Mandating 2FA would be an overreaction to a very infrequent problem. Fish+Karate 09:21, 23 November 2018 (UTC)
  • For what it's worth, I'm also opposed to mandatory 2FA for any level of account. I use it myself because it works for me, but I absolutely understand that there are technological and financial challenges with WMF's implementation (and/or in general) for many users. Strong passwords and good password hygiene are also important, but we can't really mandate those things, we can only advise and recommend. Just to add info to the pile, I use a password manager along with 2FA wherever it's available, I use passwords generated by the manager or xkpasswd for things I really need to remember, and I've moved money out of accounts with banks that still use a six digit number as an internet password. Ivanvector (Talk/Edits) 14:59, 23 November 2018 (UTC)
  • Given the problems that come with it (both inherent and any via a flawed system) then I wouldn't say anyone short of a steward or IntAdmin should need it. In its ideal form I am neutral to obligating it for admins - but certainly not at this time. Nosebagbear (talk) 15:23, 23 November 2018 (UTC)
  • With the second administrator being compromised today (3rd one this year) it is time to make having 2FA be a mandatory component for all new Admins (passing a RFA), all Admins requesting simple Resysoping, and all advanced privilege (Requiring identification to Foundation) holders. We've seen what a compromised admin and oversighter can do. Fundamentally the 2FA is one of the least intrusive ways to make the attack surface more difficult to succeed at. Hasteur (talk) 22:39, 23 November 2018 (UTC)
    • Hi, Hasteur. The WMF does not require identification of advanced permission holders, and has not required this for several years. There are many reasons for this; amongst the more important is that they do not have a method of securely storing the identification information, and the simple fact that they will not be able to verify that the identification documents sent to them truly belong the the person behind the account. Instead we are all required to read and sign a confidentiality agreement with our logged-in user accounts. Risker (talk) 04:28, 25 November 2018 (UTC)
  • I oppose mandatory 2FA: a proper password is plenty secure, while with 2FA it's too easy to lock yourself out of your account. Imposing 2FA would also effectively mean requiring admins to maintain committed identities and so on to convince sysadmins to unlock their accounts. BethNaught (talk) 10:14, 24 November 2018 (UTC)
  • As others have pointed out 2FA is fine for a real world organisation where employees work several hours at a time and are identified to HR and company IT/Security. It isn't such a good fit for a volunteer organisation like this, and can actually militate against editor retention, specifically editors returning after multi year holidays - not a common issue for corporate IT. If password protection for admins needs to be improved, then set some software in place to force a password reset on any admin account with a password shorter than 16 digits. ϢereSpielChequers 13:05, 24 November 2018 (UTC)
  • I won't be using 2FA. 3 reasons: (1) I have a unique, long, password (as does the email account I use only for Wikipedia) (2) Having seen the results of an organisation I did some consultancy work for when they introduced 2FA ... yeah, you can probably guess the rest... (3) You seen the mobile reception round here? Black Kite (talk) 23:32, 24 November 2018 (UTC)
    @Black Kite: just to clarify, our 2FA solution is not "on line", that is no connectivity is required between the authentication device and anything else, not for enrollment and not for use. — xaosflux Talk 20:26, 25 November 2018 (UTC)
  • Heh, I accidentally locked myself out of my own account this morning. I logged out to use one of my alts, forgetting that I had just started a system update on my phone and couldn't access my authenticator app. I could've looked up my scratch codes to get back in but I didn't have anything urgent to do so I just waited for the update to finish. I'm just saying 1) it happens to people who think they know what they're doing, and 2) you can recover your account if you do something dumb like this, but it's a hassle (it's supposed to be a hassle). Ivanvector (Talk/Edits) 17:14, 25 November 2018 (UTC)
  • Just a comment on forced periodic password resets (not entirely just about 2FA, but I can't see a better section). It's been largely debunked as a means to security, and it often just makes people change to passwords that are easier to remember (and therefore easier to hack). One place I worked briefly enforced monthly changes to passwords, and a significant number of people started using "January", "February" etc. That can be prevented by insisting on strong passwords, but with strong passwords you avoid any need for periodic changes anyway. If someone is victim to a brute force attack, all a periodic change really does is eliminate the passwords already tried and force the hacker to start again. So with a good strong password, a forced 3-month reset might reduce the mean time to hacking from, maybe, 50 million years to 49,999,999 years and 9 months. Strong passwords are the way to maintain security (and by that I don't mean nonsense like 8 characters including 1 digit and one upper case letter, I mean proper strong passwords), coupled with login attempt throttling, and maybe a good 2FA system where something extra might be needed (but 2FA isn't the real answer). Boing! said Zebedee (talk) 12:47, 3 December 2018 (UTC)
    I've just used a "Check the security of my password" site to check a few passwords. I did *not* check any of my real passwords on the possibility that it's a fake password-grabbing site! (though I used one at Russia's Kaspersky Lab, so that should be fine ;-) The results were interesting, with estimated computer-based cracking times...
    "January" - 4 seconds
    "Jan" - 7 microseconds
    "January1947" - 8 minutes
    "TomatoTrinket" (two random words) - 21 days
    "toMatOtRINket" (same two words with random caps) - 20 years
    "_QPZ#~pGww:6Q,7\" (from a random password generator) - 10,000+ centuries
    A password of similar length and format to my Wikipedia password - 8,763 centuries
    Some sites will offer a false sense of security, so be wary of any results. One, for example, reckoned "January1947" would take 41 years to crack, and I presume that's just doing a brute-force random-character attempt rather than trying any "Hmm, I wonder if it's when they were born?" connection of months and years. But I think it makes my point about strong passwords being the crux of it. Boing! said Zebedee (talk) 13:09, 3 December 2018 (UTC)
    I changed my password the other day as it seemed like good advice. My old password would have taken a pitiful 2,000 years to brute force. Lame! My new one, a far safer 552 quadrillion years. I think the bigger risk these days isn't your password being brute forced, it's your password being used on multiple sites. I had this issue once when LinkedIn dropped a bollock and gave away everyone's passwords. It wasn't the same password I used here, that's always been unique, but I did have to change passwords on about 40 different sites and learned a valuable lesson. NEVER REUSE PASSWORDS ANYWHERE EVER. Fish+Karate 13:46, 3 December 2018 (UTC)
    Definitely, yes, never reuse passwords between sites. Boing! said Zebedee (talk) 14:36, 3 December 2018 (UTC)
    Looking at my results again, I suspect the site I used got "_QPZ#~pGww:6Q,7\" wrong - it's only 16 chars from the printable ASCII set, and "10,000+ centuries" seems way too optimistic. Boing! said Zebedee (talk) 14:38, 3 December 2018 (UTC)
  • I support all the comments above by @Fish and karate, Iridiscent, and Risker. This is a security panic, which is entirely un-needed now that admins no longer have the power to unblock themselves. A hijacked admin account be be spotted, blocked, and the damage cleaned up quickly.
As others noted above, 2FA also imposes burdens on admins which they may not be able to meet for a whole variety of reasons: financial, logistical, state security policy, neurological diversity, etc etc. It is sad to see how some editors simply assume that because their life circumstances make 2FA easy for them, the same applies to everyone else.
If there was en.wp decided to take just one step to further reduce our already appallingly low levels of diversity, this would be near the top of the list. Luckily, en.wp's policies are aimed at increasing diversity. --BrownHairedGirl (talk) • (contribs) 13:37, 3 December 2018 (UTC)
  • An observation: it appears that what's written in this month's administrators' newsletter is the WMF's entire response to these hacks: they're not doing anything at all about vulnerable accounts, they're just passing the buck to users to secure their own accounts. Of course, their message will not get to inactive admins, so be vigilant for more hacks. Ivanvector (Talk/Edits) 14:19, 3 December 2018 (UTC)
    • That's a very poor observation. It's standard practice among security professionals to not publicly discuss the details of every mitigation strategy, to make it a bit harder for the attacker to adapt. Anomie⚔ 13:09, 4 December 2018 (UTC)
  • Agree with Boing! said Zebedee - my last job had us changing password every month - a lot ended up using a "core" password and added a 2 digit number to the end of it (and then writing the 2 digit number on the back of the PC...) FWIW, I do have 2FA installed, only because of c:Commons:Administrators'_noticeboard/Archive_69#URGENT:_CHANGE_PW_/_ENABLE_Two-factor_authentication, since I'm an admin on commons as well, and there was no great oppose to not implementing it (but there are only about 250 of us). In the end it cost me nothing to implement - I wrote a short python script User:Ronhjones/2FA for my PC - I just run it when I need a code (and it gives me my adminbot code as well). Ronhjones  (Talk) 18:45, 3 December 2018 (UTC)
    Ah yes, I remember now - I just added "Jan", "Feb", etc to my existing password (which was already quite strong). Previous ones couldn't be reused, but they gave up on the scheme long before 12 months and the need for a new root. And while we're doing password anecdotes, I had to try breaking into a colleague's account once (as he'd left some broken jobs clogging up the overnight batch queue - I'm showing my age). His username was just his first name, so the first thing I tried was his surname, and I was in - and his surname, appropriately, was "Hack". Boing! said Zebedee (talk) 19:01, 3 December 2018 (UTC)

Mandatory 2FA considered harmful

Allowing 2FA is fine, as long as the scheme uses meets the requirements of [ https://pages.nist.gov/800-63-3/sp800-63b.html#sec5 ]. Encouraging 2FA is also fine. Requiring' 2FA is a really, really bad idea. It is security theater, and in general is less secure than simply using a long, easy-to-remember-but difficult-to guess passphrase.

https://www.makeuseof.com/tag/two-factor-authentication-sms-apps/

https://www.wired.com/story/two-factor-authentication-apps-authy-google-authenticator/

https://thestack.com/security/2016/04/08/anywhere-computing-makes-2fa-insecure-on-ios-and-android/

--Guy Macon (talk) 07:38, 23 November 2018 (UTC)

I'll note that the articles you provided counter your point of passphrases being good enough. "And remember, any 2FA is better than no 2FA. Yes, it might take you an extra 10 seconds to log into certain apps, but it’s better than sacrificing your security." "the few minutes it takes to set up an authenticator app are more than worth the benefit". Here are three articles that support the use of 2FA:
Calling it a security theatre is subjective, and the article from The Stack is contradicted as "anywhere computing" relates to syncing information across devices, and these applications don't do that (at least Google Authenticator and WinAuth). I can understand possible situations in which someone cannot enable 2FA, but I see little reason to not if you can. So what if it takes someone an extra two minutes to log in? I'd much rather have to do that every so often than wake up to find my account compromised because Wikipedia or the connected email was hacked. And that goes for most sites that offer 2FA (I might not use a site's 2FA if I rarely use the site, but if someone's an admin+, it's hopefully safe to assume they're somewhat dedicated). Anarchyte (talk | work) 08:23, 23 November 2018 (UTC)
Just to comment - it is pretty clearly security theatre to suggest that the way to prevent compromise of admin accounts is to apply 2FA, when the last two reported admin or higher account compromises would not have been prevented even if the compromised accounts had had 2FA. It is also pretty clearly security theatre to suggest that removing admin permissions at a lower threshold will prevent situations where the accounts need to be blocked/locked/desysopped, when the overwhelming majority of admin accounts that have been desysopped would have met just about any activity criterion the community could reasonably come up with. So yeah. Security theatre. Risker (talk) 09:24, 23 November 2018 (UTC)
We hear about the successful attacks to compromise accounts, but never the unsuccessful ones. While I'm doubtful it has occurred, we would never be able to know if someone managed to guess the password to an admin's account who had 2FA enabled. There's a ping if they get it wrong a certain amount of time, but nothing for getting 66% of the way there (33% each for username, password, and 2FA). If that's an example of a security theatre, so is requiring CVVs for credit cards. It's simply a fail-safe to prevent people from giving away all their information. You could take a photo of the front of your card and no one could purchase anything online. I could give you my password and you wouldn't be able to access my account. I'm not saying 2FA is the be-all-end-all; just like CVVs aren't. If they were, we would never have a breached 2FA-enabled account and we would never have to worry about people using someone else's credit card. It's an extra layer of protection. Anarchyte (talk | work) 09:47, 23 November 2018 (UTC)
That's a false analogy. Compromise of a credit card causes the real loss of real money. Compromise of a Wikipedia account—even an admin account—causes someone to be a mild nuisance for a couple of minutes before having their contributions rolled back. Even assuming every editor had access to the technological means to use 2FA, an additional 10 seconds per day adds up when you multiply it by 1000-ish admins (not to mention the opportunity cost of "I've just noticed a problem, but I won't bother logging in to fix it because it would mean going downstairs, finding the phone and turning it on"). There are theoretical ways a compromised account could do genuine damage and force the WMF to perform a database rollback, but they've never once happened. The risk from a genuine holder of advanced permissions leaking data or systematically disrupting is orders of magnitude greater than the risk from a potentially compromised account, and even installing iris recognition on the computers of every admin would have zero impact on admins becoming disgruntled, drunk, involved in personal vendettas, or just bored. ‑ Iridescent 10:46, 23 November 2018 (UTC)
Fraud is usually intercepted by the bank and the account gets locked with the money spent being charged back, when possible. With this said, the analogy wasn't to give perspective to the connotations, rather that fail-safes like 2FA are all around us. I agree with your other points, though. Anarchyte (talk | work) 11:01, 23 November 2018 (UTC)
Going off of Iri’s point, this just happened, and while the account claims compromise, that is unlikely and in every likelihood we had a CheckUser on another WMF project (who at one point had access to en.wiki data that was stored on CU-wiki) was operating a goodhand-badhand sock situation on multiple wikis. Compromise is a concern obviously, but the chance of admin socking or a functionary going rogue is actually a much greater risk in my view. Again, I am not anti-2FA, but I do think we need to have a realistic view of actual risks. TonyBallioni (talk) 22:45, 23 November 2018 (UTC)
Sure, but did we ever had breach of an account with say 20+ character password which was not reused on any other sites? Ideally if the recovery mail is also protected by a 20+ character password which has never been used elsewhere?--Ymblanter (talk) 11:17, 23 November 2018 (UTC)
People haven't been going around revealing their compromised passwords. Length isn't the defining factor, complexity is. See this 8-10GB file of hacked passwords and you'll see that while less common, accounts with randomised passwords still get hacked. These sites may not be Wikipedia (some are actually bigger: 150 million Adobe and 165 million LinkedIn accounts, for instance) but we'd be ignorant to assume we can't be hacked. Anarchyte (talk | work) 12:05, 23 November 2018 (UTC)
I kinda get the feeling that if we make 2FA mandatory, that will just become the next _target. If we don't make it mandatory but everyone on the site still used 2FA (except me because my password would take "4.06 hundred million trillion centuries" to crack and isn't listed in any dumps) then passwords remain the more visible option (even if they only get my password well after homo sapiens is no longer a thing). If someone is not going to use 2FA, they need to check for their passwords on Have I Been Pwned? and if there's any chance it might have leaked, change it to something that will outlast the site. Ian.thomson (talk) 17:00, 25 November 2018 (UTC)
If credential stuffing is what's going on here, a better idea is to use a unique password on Wikipedia which you do not use and have not ever used on any other website. If it's a brute force attack then Macon's Principle is a good guide. And then there's session hijacking, and for that I don't know, but I do know if you log out of Wikipedia it logs out all of your sessions on all devices. Ivanvector (Talk/Edits) 17:10, 25 November 2018 (UTC)
In my experience, if you log out once you are logged out of all sessions at all devices. (Though I must confess I was this years in a situation on my ipad when I was logged on the English Wikipedia but not on Commons or Wikidata).--Ymblanter (talk) 17:41, 25 November 2018 (UTC)
Correct. Logging out of any Wikimedia site logs you out of all of them. Additionally, changing your password logs you out of all sessions besides the one used to change the password. In light of the recent events, I decided to changed mine (and my 2FA secret key) to verify this. I recommend other people do the same even if you think your password will take aeons to crack. Anarchyte (talk | work) 04:35, 26 November 2018 (UTC)
Ian.thomson, How do you know https://www.grc.com/haystack.htm wasn't hacked at the time and you haven't given hackers your password by checking it there? ;-) Boing! said Zebedee (talk) 13:31, 3 December 2018 (UTC)
Because the calculation takes place client side, not server side (you can load the page, disconnect from the net, and still check passwords). Also, I checked different scrambled forms of my password (substitution cipher on all the characters and then either swapped the front half and back half or then put the characters in alphabetical order). Ian.thomson (talk) 19:14, 3 December 2018 (UTC)
@Guy Macon: I disagree that enforcing 2FA for everyone would be security theatre. One of the nice things about 2FA is it is very hard for a person to screw up. During the enrolment phase, users are given a barcode of the master secret to scan into their phone (or other device). The barcode is generated by the website, which means it is complex enough, and unique to the website. Compare this to a password - the user is expected to come up with a unique complex password that they never reuse. It is much easier for a user to screw this up. In fact the path of least resistance is to simply use an easy to remember word for every website. Hence the problem of people using the same password on multiple websites. Now sure, people could also post their 2FA barcode to twitter or something like that, but that would be really odd behaviour and the user has to go out of their way to compromise the security of 2FA in that manner. In my opinion, user security is much like any other thing in the world. You have a certain small number of people who are really good at it, a large group of people who are in the middle, and a small number who are really terrible. Education can of course shift the mean to the right, however when you have a group of 1200 people, I am doubtful you can ever educate people enough so that there isn't a single person using a poor (or shared) password. Attackers of course don't care if 1199 admins have good passwords, they only attack the 1 person who has a poor password. This is why mandatory 2FA would be an effective security solution - people have very little freedom to do it poorly, so if everyone is forced to use it, then everyone has a base level of security, and the attacker cannot simply choose the weak leak. (I should of course clarify that 2FA is not a panacea. It won't prevent phising attacks. It won't stop your younger sibling from going on to your computer and deleting the main page while you are in the bathroom. It will however stop one of the most common ways website accounts on the internet are compromised: People using the same password on a different website that got hacked. I also want to acknowledge that 2FA is not without its costs. I'm only arguing that it is a measure with actual benefits and definitely not security theatre. Like any security measure it has costs and benefits; it has things it protects against and things it does not). BWolff (WMF) (talk)
I oppose forcing people not to use 2FA and I oppose forcing people to use 2FA. I support giving them a choice (possibly with stern warnings). What you described above (mandatory 2FA) would prevent me from logging into Wikipedia when I work in China. I bring along the stupidest possible flip-phone (can't run any programs, no camera), and I run the TAILS operating system on a cheap computer I buy locally and leave behind. I have no way to scan in a barcode while in China, and any barcode that is in my luggage must be assumed to be copied by my opponent (industrial espionage by a Chinese toy manufacturer who has full cooperation from the Chinese government). Again, the user should be given a choice.
If you *really* want to stop Wikipedia users from using the same password on a different website that got hacked, give the user a pronounceable four or five character string and tell him he must start his 12-or-more character password with it. Not that I recommend such a scheme, but it would accomplish your stated goal. --Guy Macon (talk) 00:44, 5 December 2018 (UTC)
All I am saying here is that mandatory 2FA has real security benefits in many realistic threat scenarios (including the 3 most recent admin compromises), and thus is categorically not Security theatre. Security theatre is usually a term used to talk about security initiatives that are very visible but have essentially no benefits against realistic attackers. Whether or not the security benefits of mandatory 2FA outweighs the costs in the context of enwikipedia admins, is a different question, and one that requires very different arguments than establishing whether or not it would be pure theatre. (As an aside though, I'll note that its surprising the types of devices that support 2FA. For example totp-me works on many basic flip phones). BWolff (WMF) (talk) 03:49, 5 December 2018 (UTC)

Macon's Principle

(If the following is too long for you, just read https://xkcd.com/936/ and https://xkcd.com/538/ ) and skip to the next section.)

Two factor authentication has its uses, but it is no substitute for a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. I have decided to call this "Macon's principle" so that I don't have to type "choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess" again and again.

If you follow Macon's principle, 2FA or any other form of add-on security is not needed.

As explained at Kerckhoffs's principle and Security through obscurity, we are not to rely on anything other than having a sufficiently long (See Brute-force attack) passphrase without any easy-for-a-computer-to-guess patterns in it.

We are to assume that the attacker knows every byte of information on the WMF servers (and in fact the attacker may actually be someone who knows every byte of information on the WMF servers -- If a nation-state offered a key WMF employee millions of dollars if he complied and made a credible threat to torture and kill his family if he didn't, there is a 99%+ chance that they would end up knowing every byte of information on the WMF servers.)

We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack.

We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).

The WMF does not store your passphrase anywhere. When you enter it it a cryptographic hash is performed and the result compared with a stored hash. This means that an attacker who knows every byte of information on the WMF servers can perform a high-speed offline passphrase-guessing attack, but cannot simply look up your passphrase and use it to log on.

So according to Kerckhoffs's principle, you should choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. The passphrase should only exist in your mind; never write it down, never say it out loud, never store it on any computer or online system.

Bad ways to follow Macon's principle

  • Passwords instead of passphrases (single words instead of strings of words with spaces between them).
  • Random gibberish.
  • Short passwords or passphrases. 8 is awful, 16 is marginal, 24 is pretty good, 32 is so good that there is no real point going longer.
  • Character substitutions (Example: ch4r4ct3r sub5t|tut10ns)

Good ways to follow Macon's principle

  • Use a standard English sentence with proper grammar, spelling, and punctuation.
  • Make it longer than 32 characters and have it contain at least three (four is better) longish words plus whatever short words, capitalization and punctuation are needed to make it grammatically correct.
  • Make sure that sentence has never been entered anywhere on your hard drive (including deleted files) or on the internet. "My Hovercraft Is Full of Eels" is bad because a dictionary that contains every phrase used in Monty Python's Flying Circus would find it.[3]
  • Make it meaningful, easy to remember, and something that generates a strong mental image.
  • Make it meaningful to you, but unguessable by others (don't use your favorite team, first kiss, mother's maiden name, etc.)

An example of a good passphrase that follow Macon's principle would be: 

 Sherwood painted his Subaru pink so that it would blend in with his flamingos.

(This assumes that you actually know someone named Sherwood and that he owns a non-pink Subaru. To make it easy to visualize and remember, you should use a name/car from among your acquaintances)

That's 78 characters that nobody in the history of the earth ever put together in that order until I wrote it. Typos really stand out (Sherwood paibted his Subaru pink so that it would blend in with his flamingos.) and are easy to correct. The sun will burn out long before the fastest possible passphrase-guessing program completes 0.01% of its search. And yet it would be far easier to remember than the far easier (for a computer) to guess HZn?m+jW1 would be.

(Side note: When I say "Use a standard English sentence with proper grammar, spelling, and punctuation." I mean use what you consider to be a standard English sentence with proper grammar, spelling, and punctuation. If, you, overuse, commas, and, kant, spel, that's fine as long as you do it the same way every time. And if you are better at Spanish, use what you consider to be a standard Spanish sentence with proper grammar, spelling, and punctuation. Just write your passphrase in whatever way you normally write. If you are handicapped in such a way that you cannot type the same thing every time, sorry, but you are hosed on Wikipedia or on any other system that requires a username or password. My advice also doesn't work if you are in a coma or are Amish and not allowed to use a computer. None of this applies to Wikipedia users.)

I could walk you through the math, but Steve Gibson has already done it for us. See [ https://www.grc.com/haystack.htm ]. Just type in your current password/passphrase and it will tell you how well it does against a brute force password guessing attack. The calculation is done locally, using JavaScript, so the password doesn't leave your computer.

If you don't want to risk typing in your password, try these 8-character test passwords (Generated from an atomic decay true random number generator):

  • HZn?m+jW (chosen from the 95 ASCII printable characters (01...89abc...xyzABC...XYZ `~!@#$%^&*()-_=+[{]}\|;:'",<.>/?) - 7.66 hours to crack.
  • PhBixXL4 (chosen from the 62 ASCII a-z/ABC-Z/0-9 characters (01...89abc...xyzABC...XYZ) - 36.99 minutes to crack.
  • qza7nm3g (chosen from the 36 ASCII a-z/0-9 characters (0123456789abcdefghijklmnopqrstuvwxyz) - 29.02 seconds to crack.
  • pgupwmxn (chosen from the 26 ASCII a-z characters (abcdefghijklmnopqrstuvwxyz) - 2.17 seconds to crack.
  • 54606559 (chosen from 10 ASCII 0-9 characters (0123456789) 0.00111 seconds to crack.

Try it with 12 characters, 16 characters, etc.

Now try "Sherwood painted his Subaru pink so that it would blend in with his flamingos." on the GRC calculator. The time to crack goes from minutes or seconds to ten billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries.

I should also mention dictionary attacks. My collection of cracking dictionaries is getting big enough that I will likely have to buy a bigger drive to hold them soon. (No, I am not a malicious hacker. Some companies hire me to evaluate their security. Or at least that's the story I am telling now... :) ) The good news is that if you use two words in a dictionary separated by a space, the time for an exhaustive search is squared, and with three it is cubed. The example I made up above "Sherwood painted his Subaru pink so that it would blend in with his flamingos." has 14 dictionary words. Even if the dictionary was really tiny (say, 1000 words), that's 10^42 guesses. And such a tiny dictionary is unlikely to contain "Sherwood" (with the capitalization) "Subaru", or "flamingos." (with the trailing period). So "Sherwood painted his Subaru pink so that it would blend in with his flamingos." is also ridiculously resistant to dictionary attacks.

--Guy Macon (talk) 17:21, 23 November 2018 (UTC)

How about also randomizing the sapces? E.g, S herwoodp aintedh isS ubarup inks ot hati tw ouldb lendi nw ithh isflamingos? ——SerialNumber54129 14:29, 24 November 2018 (UTC)
That would take exactly as long to brute-force crack, and how are you going to remember where you randomized the spaces? Ivanvector (Talk/Edits) 15:53, 24 November 2018 (UTC)
Exactly so. Randomizing the spaces violates one of my suggestions (Use a standard English sentence with proper grammar, spelling, and punctuation) and adds zero benefit. More importantly, Serial Number 54129 should have entered his suggested passphrase into [ https://www.grc.com/haystack.htm ] and compared it with "Sherwood painted his Subaru pink so that it would blend in with his flamingos." That would have told him the relative strength of the two passphrases against a brute force password guessing attack. --Guy Macon (talk) 22:13, 24 November 2018 (UTC)
Hm, just mentioning here that a very short phrase -- the names of my best friend's weirdly named cats -- shows as taking at minimum 38 centuries to crack. Which would actually protect me in every case except someone who knew me well enough to make that educated guess. Thanks for this info, Guy Macon. --valereee (talk) 12:06, 25 November 2018 (UTC)
Sherwood painted his Subaru pink so that it would blend in with his flamingos.
Trouble is, after a period of non-use, this could easily be misremembered as containing any one of
  • so that it would match
  • so that it blended in with
  • so that it would go with
  • so it would blend in with
et cetera. And that's just one part of the sentence: Sherwood might have sprayed his Subaru, or had it painted, or....
The XKCD suggestion is better, I think: just four words.
The next problem is that the Wikimedia websites require just one among perhaps fifty passwords that are required of me (many of them used only once a year or so). If I'm not to store them on my hard drive, then how should I remember them? -- Hoary (talk) 12:18, 25 November 2018 (UTC)
Remember, you should create a mental image Sherwood painting his Subaru pink and of it blending in with his flamingos. If the language first comes to your mind is "matching his flamingos" use that language, and create a mental image of him putting them next to each other and seeing if they match.
Last "problem" first: Use a password manager that keeps all of your passwords in an encrypted container so you only have to remember the one macon's-principle-compliant passphrase that accesses the rest. This also soles the "seldom used" problem; you end up using it a couple of times every day.
For most people Passsafe[4] is a good choice for a password manager. I often do engineering work inside of a factory in China in an industry (toys) where the threat of industrial espionage is high, so for me every webpage gets a password like this: weO'5QvWH6oeRjKQ;EU/I@alk#<0CJ5a/&FmHrV>/}O5]p{+Km}gJ~^e9'5=tznK and all of the passwords are stored as text files on a thumb drive that is encrypted using Veracrypt using multiple algorithms. Most people don't need that level of protection.
Next, it is not true that the XKCD advice is better than mine. That comic was written as an example showing that "correct horse battery staple" is easier for a human to remember and harder for a computer to guess than the "Tr0ub4or&3" alternative -- which it clearly is. Note that he assumes 1000 guesses per second, which violates Kerckhoffs's principle. We are not to assume that the attacker cannot perform a high-speed offline passphrase-guessing attack. We are not to assume anything about the amount of cleverness and computing power that the attacker has, other than arguments based upon basic math and physics (The attacker cannot spend more time than the age of the universe, he cannot have more memory available than the size of the universe will hold -- that sort of thing).
If you apply Macon's principle to the XKCD comic, you get the following very strong passphrase:
      The horse said "That's a battery staple". I replied, "Correct!"
Randall Munroe knows all of this, but I challenge anyone to fit all of the details needed to apply Macon's principle into a six-panel comic.
Here is a discussion of the math behind that particular comic:
http://security.stackexchange.com/a/6096/33
Or, as Bruce Schneier wrote: "This is why the oft-cited XKCD scheme for generating passwords [...] is no longer good advice. The password crackers are on to this trick."[5] --Guy Macon (talk) 16:18, 25 November 2018 (UTC)
Bruce is wrong about this, as several of the comments on his page point out. As long as the words in the passphrase are chosen uniformly randomly from a list or dictionary, the entropy of the passphrase can be computed from the number of words in the passphrase, N and the number of words in the list, L, as entropy = N*log2(L). If the entropy is high enough, cracking is not going to work. It doesn't matter that the cracker knows how your are doing this. One way to get uniformly random words is using dice. See Diceware. (COI alert, I'm the developer.) Your method, by contrast, requires people to exercise judgement on what is random enough, and there is plenty of experience to show that most people fail miserably at that. Also passphrases generated your way can easily be longer than many systems will accept. The latest NIST SP800-63b guidelines, linked above, require only 64 characters to be accepted. Your pink flamingo password is longer than that. And many (most?) systems do not even meet the NIST requirements. (Does Wikipedia?) And of course typing a passphrase that long without error, especially on mobile devices, is not easy. Making up a sentence using the random words is a great idea as a memory aid, but there is no need to make the sentence the passphrase.--agr (talk) 18:02, 25 November 2018 (UTC)
The diceware method is an excellent way of constructing a passphrase. I highly recommend it, especially if you use the EFF's long word list for five dice (or one die rolled five times).[6] Anyone using the diceware method instead of my method will also be insanely secure against both dictionary attacks and against brute-force guessing attacks. I have never heard of anyone or any computer program ever guessing a Diceware passphrase.
That being said, as you yourself pointed out in 2014, the four words that XKCD mentions (note that Randall Munroe never actually says that "correct horse battery staple" is sufficient, only that it is easier for a human to remember and harder for a computer to guess than "Tr0ub4or&3" is) are a couple of words too few:
"For the average user I now recommend a passphrase with six Diceware words, or five words with one extra character chosen and placed at random. This is a change from my previous advice [five words]..." --Source: The Diceware Security Blog
In my opinion (and this is a judgement call - I may be wrong), compared with my method Diceware is much more resistant to the well-known human tendency to make non-random, guessable choices, but (also IMO) my method gives you a passphrase that is easier to memorize and remember after a long time of not using it compared to a Diceware passphrase. --Guy Macon (talk) 07:02, 26 November 2018 (UTC)
Not intending to get into an argument with you, Guy Macon, just testing my understanding ... by, um, arguing. (Sorry!)
The horse said "That's a battery staple". I replied, "Correct!"
is clearly superior to
correct horse battery staple
(or whatever it was), all things being equal. But not all things are equal, it seems to me. If I want to log in here via my phone (which BTW is something I don't remember ever having done, and would be very reluctant to do), then I'd have to (i) remember the former precisely, (ii) paste it from text copied from elsewhere in the phone's memory (bad!), or (iii) read it off a piece of paper (bad!). As for my own computer, it's rare that I need to specify my password; when this happened, I wouldn't remember if I'd had "replied", "responded" or "answered" (etc etc); and if I'm reading it out of some file I might as well copy
correct horse battery staple bismuth fortuitous banana
(or whatever) out of it and paste that as do the same with the two sentences -- which are indeed hugely more easy for short-term human memory but I imagine [disclaimer: I am not a cognitive scientist] just about as hard, or possibly even harder, for precise memorization over a long period. (Or possibly the problem is that my memory is unusually crappy.)
I don't think what I'm saying contradicts what I understand as your main point, for which I'm grateful (and according to which I intend to upgrade some of my passwords). -- Hoary (talk) 01:40, 26 November 2018 (UTC)
I am in basic agreement with you. It is significantly harder to compose a passphrase that doen't have significant "I replied\I said" memorization problems when you start with a list of words someone else chooses. I should modify my advice to talk about that. --Guy Macon (talk) 07:02, 26 November 2018 (UTC)
While I do recommend a six-word passphrase, a four word passphrase like correct horse battery staple is still far stronger than what most people use and is unlikely to appear in a list of previously hacks passwords. I don't disagree that The horse said "That's a battery staple". I replied, "Correct!" is stronger. The question is whether the improvement is worth the added typing. Your passphrase is 61 characters long, vs 28 for the original. I'm not aware of any way to quantify how much more entropy your passphrase gains over XKCD's original, but most people do fairly predictable things when given open-ended advice like make up a sentence with these words. My metric is bits of entropy per keystroke. In my view, entering passwords accurately is the biggest cost to users. Very few people are going to memorize more than a few strong pass phrases. That's why I recommend writing them down or using a good password manager with a strong master pass phrase. The threat these days is not someone stealing your wallet, it's lists of hashed passwords being stolen and cracked offline at very high speed, billions per second. My Diceware list was chosen to minimize word length, and hence passphrase size, for any chosen level of security. The EFF uses much longer words, which I think is silly, but it's a personal choice. Again making up a sentence from a random passphrase as a memory aid is fine, but using the sentence as as the passphrase itself is a very inefficient way to increase security. For what its worth, I also have a tool for generating mnemonic sentences from any random 10-letter string. Random letter strings may be a better choice for mobile devices, which are becoming more common than PCs as an Internet access tool. The best path forward, I believe, is stronger ways for storing password validation data so that stolen lists are much harder or infeasible to crack. That's been the focus of my recent research. How does Wikimedia store its passwords?--agr (talk) 17:08, 26 November 2018 (UTC)
To partially answer my own question, I found a page https://www.mediawiki.org/wiki/Manual:User_table that describes the Wikimedia default which is pbkdf2 with 10000 iterations of sha256 and salt. That's not bad, but a memory intensive algorithm like scrypt of argon2 (or my RockSalt) would be better. Still, the default shifts the likely threat to using a password that has been cracked before and is high on a list of common passwords.--agr (talk) 17:30, 26 November 2018 (UTC)
@ArnoldReinhold: Just a minor correction to your comment, we are currently using PBKDF2 with 128000 rounds sha512 (and salt). [7]. BWolff (WMF) (talk) 06:31, 5 December 2018 (UTC)
Guy Macon, I'm not clear about the advantage of including word spaces rather than using a continuous string. Is it just that it makes it longer without increasing the difficulty of memorization? DGG ( talk ) 20:01, 27 November 2018 (UTC)
Itdoeslittletomakethingsharderforanattacker(anyreasonablycompetentattackerwilluseadictionarythattrieseveryphrasewithandwithoutspaces,d1fferentc|-|aractersub5titutions,etc.),butitishardertorememberandeasiertomakeatypowhenyourpassphrasedoesn'tusestandardspelling,punctuation,andgrammar. Guy Macon (talk) 23:59, 27 November 2018 (UTC)
I'd like to endorse Guy's principle, with one small addition: make sure your passphrase incorporates at least one unusual word – maybe one of your friends has an unusual name, or you know a place with a strange name, etc. Since the strength of a passphrase is directly related to the size of the dictionary needed for a dictionary attack, you can force an attacker to use a very large dictionary, and massively increase the time required to crack the passphrase by that means. Try something like My family and I stayed 14 days in Betws-y-Coed. HTH --RexxS (talk) 22:18, 29 November 2018 (UTC)
That's a very good adddition. Increases passphrase strength even more without making it harder for a human to remember. It would be a large dictionary indeed that contains "Betws-y-Coed". Thank you from the bottom of my parasagittal circumduction. --Guy Macon (talk) 00:03, 5 December 2018 (UTC)
The problem with a passphrase is that the risk of a typo is too high; and since I can't see the text I'm typing in, I can't even confirm that I typed it in correctly before clicking on the login button. In a passphrase of 40 characters, my chances of a typo are close to 100%; and in a password field, I can't even see it. עוד מישהו Od Mishehu 13:39, 9 January 2019 (UTC)

2FA is not just about "cracking" passwords

There's a huge amount of text here so I'm not sure whether the point has been made elsewhere, but I think it's worth calling out explicitly.

All the stuff about "Macon's principle" is fine, if the only thing you have to worry about is whether a password can be brute-forced. Unfortunately it isn't.

What happens if you need to log in from a public library or a Kinko's? There's probably no keylogger installed on the machine. But there could be. Are you going to come up with another seven-word meaningful and unguessable sentence and change your password?

With 2FA, you can go ahead and log in and not worry about it too much. Probably no one captured your password. But even if someone did, he/she will have a hard time using it. It isn't theoretically perfect, but it's pretty good, which in real-life situations sometimes has to be good enough. --Trovatore (talk) 19:56, 25 November 2018 (UTC)

  • You just have an alt with a different password in those situations, which is what most admins do. TonyBallioni (talk) 19:58, 25 November 2018 (UTC)
    OK, fine. What about if someone forges an SSL cert? You won't know when that might happen. --Trovatore (talk) 20:08, 25 November 2018 (UTC)
    Trovatore, An alternate account with 2FA on it as well? In any event when I go out, I never login to public devices. My laptop always comes with me. —CYBERPOWER (Chat) 20:15, 25 November 2018 (UTC)
    Someone might use a forged cert to impersonate Wikipedia even when you're logging in from home, and capture your password. Look, the details aren't important. The point is that there are lots of ways passwords can be captured, not just brute-forced. If you have 2FA, you can accept these risks and relax a little bit. If you don't, you can try to figure out all the attack vectors, which is a full-time job for highly paid people, or you can accept the risks and just hope. --Trovatore (talk) 20:21, 25 November 2018 (UTC)
    Would the alt have admin privileges, even if clearly identified as a second account? --Masem (t) 17:13, 26 November 2018 (UTC)

Trovatore makes some very good points. There are indeed more ways to attack your login than just a brute force or dictionary guessing attack. Even the "In any event when I go out, I never login to public devices. My laptop always comes with me" method desribed above could be vulnerable to a hidden camera attack or an Evil maid attack. There was a case where an Israeli counter-terrorism unit hired a magician to do a quick swap of a cellphone sitting on a desk with the owner right next to it, some other spies in the next room quickly cloned everything on the cell phone into another one with some special hardware built in, then the magician did another quick switch. Also see: 11 ways to hack 2FA and Security News This Week: Oh Good, Hackers Beat Two-Factor to Rob Bank Accounts

In our case, we aren't terrorists or spies and are extremely unlikely to receive such individual attention. For us, the most likely attack is someone trying multiple Wikipedia accounts looking for a guessable password. A less likely but still plausible threat is someone bribing/threatening a key WMF employer, gaining access to our list of password hashes, and doing a high-speed brute force password-guessing attack.

2FA is fine, until someone concludes that 2FA means they don't have to choose a passphrase that is easy to remember and hard for a high-speed offline passphrase-guessing program to guess. --Guy Macon (talk) 07:42, 26 November 2018 (UTC)

Account security is only as good as its weakest point. Anarchyte (talk | work) 08:30, 26 November 2018 (UTC)
...usually. If either guessing your passphrase OR faking your fingerprint will give the attacker access, then both your passphrase and the fingerprint reader have to be resistant to attack -- the system is indeed only as good as its weakest part. but if guessing your passphrase AND faking your fingerprint are needed to give the attacker access, the system is at least as good as its strongest part. --Guy Macon (talk) 00:10, 28 November 2018 (UTC)
2FA is a "both" scenario, though. If I turn on 2FA and make my password "password", an attacker still needs my rapidly-rotating and device-dependent 2FA token to log in to my account. Ivanvector (Talk/Edits) 17:06, 6 December 2018 (UTC)

Parallel discussion

Trying to kick this thing back awake, and also noting that there are several other discussions regarding nearly-inactive admins at WP:BN right now that have some very interesting points, including lists of admins who have hung on to the tools despite not using them for 5-10 years or longer. Beeblebrox (talk) 05:34, 6 December 2018 (UTC)

For the record, the WMF's own "make 2FA mandatory for admins" discussion is over here. Jo-Jo Eumerus (talk, contributions) 07:05, 7 December 2018 (UTC)

Alternative better idea than mandatory 2FA

Admins would upload a .XYZ file when logging in. This file contains a 2048-bit public key that will be checked against Wikipedia's own Central Authority (for verifying Wikipedia admin account login purposes only), where each admin account has their own private key in PKCS 12 (.p12) file and a Certificate, on the server. Wikipedia would e-mail the public key files to the admins via the e-mail address registered to their account.

When the file is uploaded, the an internal verification server will decide by seeing if the public key provided in the file would be able to decrypt a message if it were to be encrypted via the private key on the server linked to the admins account. If it passes the verification, the login process is successful. If it fails, the verification server will request the Web host server to inform the client to display a access denied error message. Aceing_Winter_Snows_Harsh_Cold (talk) 23:49, 8 December 2018 (UTC)

This is essentially still a 2FA: something you know (your password), something you have (this certificate; with the challenge of certificate management across many devices to worry about. — xaosflux Talk 17:23, 9 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Treat surname pages like disambiguation pages?

Latest comment: 5 years ago14 comments6 people in discussion

There are several discussions about whether surname pages are disambiguation pages, and there is a lack of full consensus, although the question may be semantic in some regards. It's not a simple yes or no question.

Some of the issues are:

Should surname pages be included in Category:Disambiguation pages? As discussed below in the second question, if editors should not link to surname pages because they should disambiguate links, then it may be helpful to categorize them as dab pages so that the links to them can be flagged for repair WP:DPWL. The template {{surname}} apparently does not automatically include them as disambiguation pages, and the Talk page discussion seems to suggest they are not to be considered disambiguation pages. There is a {{Dmbox}} template Talk page discussion about whether bots are behaving correctly in how the classify surname pages (apparently they don't). A Village Pump discussion there touches upon whether the various language wikis handle the issue the same way (apparently they don't).

After some additional research I concluded that surname pages are actually Set Index Articles and not disambiguation pages. SIAs are article pages consisting of lists of things in the same category (such as people) with the same name. Disambiguation pages are non-article pages that link to article pages for the various meanings of a term, i.e., they are navigation aids. The template {{surname}} is a Set Index Article template for surnames and can be used to categorize surname pages. The {{surname}} usage notes provide additional guidance on how to classify disambiguation pages that include a list of people with a certain surname along with other entries. Coastside (talk) 04:49, 8 January 2019 (UTC)

Should surname pages follow policy guidelines for disambiguation pages? I think they should. For example, WP:DABPEOPLE and WP:DABRED provide important guidance. Some disambiguation pages include surname sections, in which case it is rather clear that they should conform to policy under WP:DAB. These pages are (or should) be categorized with the template {{Disambiguate:surname}}, which puts the page in Category:Disambiguation pages with surname-holder lists. In any case, there is a question of whether the policy guidelines for surname lists in disambiguation pages is the same as for surname pages along with guidance about surname language categories.

I found policy guidance on this point at WP:SIA. It says: "An SIA need not follow the formatting rules for disambiguation pages, although many SIAs do. Unlike disambiguation page guidelines, an SIA is allowed to contain red links to help editors create articles on notable entries." Applied to surname pages, this means it's ok to add entries for notable people regarless of WP:DABRED. Coastside (talk) 05:31, 8 January 2019 (UTC)

Can and should you ever link to surname pages? It is a general guideline that you should not to link to disambiguation pages for article pages, but if surname pages aren't disambiguation pages, then is it ok to link to them? I would argue that links to surname pages should be disambiguated when possible. As a matter of fact, it is helpful for these pages to appear as pages needing fixing such as WP:DPWL so that the links can be fixed. Then again, some surname pages are written as if they article pages about the name itself, in which case it might reasonable to link to them, for example Bernard. There is some relevant guidance about when to include people in lists of people under standalone-lists. This seems to apply to surname lists. Stand-alone lists are considered a type of article page, not disambiguation pages.

Again, after research, I determined that it is ok to link to surname pages. This is because they are article pages. They may be standalone-lists, or they may include content about the surname such as historical information. Regardless, wikilinks that are meant to point to an article about a specific individual should link to the article page and not the surname page.Coastside (talk) 05:01, 8 January 2019 (UTC)

Should you always use the "(surname)" qualifier in surname page titles? This has been asked and discussed, and I think it's rather clear that surname pages do not always need the qualifier. If there is no main article for the surname, you just use that and redirect from the qualified name to the main page. I just mention it here for completeness.

Another possibility is to use the article name List of people with surname 'name' for cases when the surname article already exists and there is reason to separate the list from the list page (such as because of length). For example there is a surname article page Jenkins (surname) as well as a list page List of people with surname Jenkins. Notably, both of these pages use the {{surname}} template.Coastside (talk) 05:22, 8 January 2019 (UTC)

I would suggest we create a page specific to defining how surname pages should be handled.

Well, seems I answered my own questions. :) Coastside (talk) 05:31, 8 January 2019 (UTC)

Coastside (talk) 00:57, 6 January 2019 (UTC)

Excellent! I will join the conversation in the talk page.
APODAB and APOSURNAME does not handle the things WP:MOSDAB do, namely, the format of lists List of people with surname Spencer, and people lists present in nearly all Surname (surname) pages. While "article-type" texts are controlled vy our WP:V, the lists are sometimes in random format, which IMO must have strict rules similar to MOSDAB. Staszek Lem (talk) 18:38, 11 January 2019 (UTC)

A question came across recently, while creating the bot Noref (to add {{unreferenced}} tags) is if Set Index Articles require references. It seems silly to me to require references. They are essentially dab pages, IMO, the requirement for references being the defining difference. -- GreenC 19:30, 11 January 2019 (UTC)

Set Index Articles are not required to have references, but they are allowed to have them. bd2412 T 04:36, 12 January 2019 (UTC)
Set index articles are subject to guidance for standalone list articles at WP:LISTVERIFY. If the surname SIA is only a list of persons with the name, I think merely meeting the inclusion criteria for the list would satisfy verifiability that the person has the surname. Redlinks might need to meet some additional criteria. I'm not sure a surname-equivalent of WP:DABMENTION would be enough -- I think redlinks would need to meet some sort of notability criteria -- else surname lists could turn into a phone book listing. And of course, any non-list content (such as name origin, meaning, distribution, etc.) needs to be verifiable and supported by reliable sources. I'd be wary of a bot performing this sort of assessment. older ≠ wiser 10:27, 12 January 2019 (UTC)

Auto-confirmations

Latest comment: 5 years ago3 comments3 people in discussion

Auto-confirmations and extended confirmed should be tied to mainspace edits, not all edits.

Btw, I'm surprised this isn't perennial.

Benjamin (talk) 02:06, 13 January 2019 (UTC)

@Benjaminikuta: - two main reasons against this:
1) Almost all of auto-confirmed edits and a strong majority of EC edits will be in mainspace - making more than a small fraction of edits in other namespaces is usually something we see arise later on. Edits aren't the main barrier - so this somewhat risks being a solution in search of a problem
2) This proposal also is somewhat rude - it suggests that only mainspace edits are productive or at least contribute to knowing if an editor is sufficiently authentic to be trusted with wider access. I could understand ruling out the two user-spaces, but participating in the others can be just as beneficial. Nosebagbear (talk) 13:59, 13 January 2019 (UTC)
I agree with Nosebagbear. Just about any participation in a discussion anywhere other than the user's own talk page is likely to be productive (this includes some pages in the Wikipedia: namespace); as would participating in categories and templates which are used for the mainspace. עוד מישהו Od Mishehu 14:03, 13 January 2019 (UTC)

Self-promotion

Latest comment: 5 years ago21 comments10 people in discussion

Has anyone else received an email like this, which I found profoundly disturbing? What can be done about this?

From: Lauren <lauren@worldresearchernews.com>
 Subject: Get Featured in Wikipedia

Have you ever wondered of having a Wikipedia page for yourself or your company? We can help you get a Wikipedia page for yourself or your brand.

Usually Wikipedia only accepts pages on celebrities and famous companies, if you are looking to get one for your self, we can help you with that. Having a page for yourself in Wikipedia, brings you more credibility and makes you more famous.

We have been editing on Wikipedia for 7+ years and We've created tons of pages for companies, people, brands, products, and of course for academic purposes as well.

We own multiple accounts on Wikipedia with page curation and new page reviewer rights, so i can create and moderate pages with almost zero risk of another mod taking it down.

There are few wikipedia editors who are willing to create a page for money, and most of them are scared to offer this service directly, so they do it through their trusted sellers who markup the price to $1500 - $2500 per page.

Because you're buying directly from an experienced wikipedia editor and mod, you'll get your page a lot cheaper, faster and with more reliability.

Let me know if you are interested
Regards
Emily

--Michael Goodyear ✐  ✉ 20:22, 4 January 2019 (UTC)

Reply to the email and ask for a portfolio of their past work. GMGtalk 20:46, 4 January 2019 (UTC)
Have done so. It is possibly a scam, but a little searching turns up a lot af advertisements offering Wiki pages for money. --Michael Goodyear ✐  ✉ 00:08, 5 January 2019 (UTC)
Michael Goodyear, it seems you're not the only one. https://pastebin.com/vZphqd4A Vexations (talk) 22:37, 4 January 2019 (UTC)
I'm sure I'm not! This would be a mass mailing to a harvested or purchased list of email addresses. --Michael Goodyear ✐  ✉ 00:08, 5 January 2019 (UTC)

OK here it is:

Thanks for your interest in our services. Our service fee for Wikipedia page creation is $999 per profile, and it will take around 4 weeks to complete.

Here is our recent work for Dr. Ayman Al-Hendy from the University of Illinois.

Let me know if you would like to proceed.

Regards Lauren.

--Michael Goodyear ✐  ✉ 23:16, 7 January 2019 (UTC)

Pretty lame article, too. Many citations, mostly neither establishing notability nor supporting the statements they're attached to. And the heading capitalization suggests an inexperienced editor. And it's a unique account for the one article, so that's a pattern to watch out for. Dicklyon (talk) 23:27, 7 January 2019 (UTC)
I would care very little about this. These articles probably will never gain too much attention, and even if they gain significant attention, they would be proposed as candidates for deletion in accordance with WP:NOTE. User:AnUnnamedUser (talk) —Preceding undated comment added 00:39, 8 January 2019 (UTC)
@Atlantic306: – Another editor who goes around polishing up reputations and removing notability tags from such articles is Atlantic306. Probably the experienced ring leader. Dicklyon (talk) 03:06, 8 January 2019 (UTC)
I don't have much admiration for A306 but that's a blatant unsubstantiated PA.∯WBGconverse 07:46, 8 January 2019 (UTC)
The "experienced ring leader" part was kidding. The point was just that he needs to be more careful about removing notability tags based just on number of cites. Dicklyon (talk) 23:02, 8 January 2019 (UTC)
  • Comment: I've had an email from a similarly named account quite recently (I'm mindful of Oversight) so I don't want to put the full thing here. Mine's slightly different from Michael Goodyear's and Vexations' in that instead of advertising their services they tried to recruit me. I won't post the whole email here but if a functionary is interested, leave a message on my talk page and I'll send it over. Basically it was "I see you're an Articles For Creation reviewer, would you like a PayPal payment to accept some drafts?" Needless to say, I told them, in more diplomatic language, to get stuffed. If there's one thing I despise it's undisclosed paid editing, and anyone who knows my account history will know that I'm not exactly the bastion of morality myself. I'd also be willing to send this over to admins active at AFC, pinging Primefac to see if he's interested. I echo Winged Blades of Godric's comment, I don't always see eye-to-eye with Atlantic306 but to suggest he's an undisclosed paid editor without any proof whatsoever is tantamount to a personal attack and I would advise Dicklyon to withdraw it. Many thanks, SITH (talk) 20:27, 8 January 2019 (UTC)
    StraussInTheHouse, forward it to the functs; we don't "officially" handle these requests but if it's a case of UPE there might be a sock ring involved. Primefac (talk) 20:38, 8 January 2019 (UTC)
To be clear, Atlantic306 accepted this draft, that does not necessarily make this editor a paid contributor, since the article was the product of Nocturnal911. In this case, remedial action has been taken, and that contributor blocked. The real issue, is how widespread is the practice? And how can it be rooted out.--Michael Goodyear ✐  ✉ 22:56, 8 January 2019 (UTC)
If you look at where Atlantic306 removed the noteability tag, and look for other edits with similar summary, it doesn't look like a good behavior. He needs to be more discerning. Dicklyon (talk) 23:36, 8 January 2019 (UTC)
      • Dicklyon (talk · contribs) you are wrong again as I have not removed a notability tag on that article, check the edit history. I commented on the notability on the talk page but that was nothing to do with a tag. On other articles I sometimes remove inappropriate tags which can be added by 4 year olds, as per WP:Overtagging and as for your joke ... Atlantic306 (talk) 22:32, 13 January 2019 (UTC)
Dicklyon, I agree with you, but it's best, even if you're joking, to avoid casting aspersions because that can get you on the wrong side of ArbCom. SITH (talk) 23:40, 8 January 2019 (UTC)
Please bear in mind that it is quite possible that the sender of the e-mail (or of anything similar) is not entirely honest, and had nothing to do with creating Ayman Al-Hendy, or any other article they claim to have created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 9 January 2019 (UTC)
Point well taken and we have seen examples of that before but in this case the article was created by a sock puppet who was subsequently blocked. --Michael Goodyear ✐  ✉ 22:58, 9 January 2019 (UTC)

Stub and CN on user pages

Latest comment: 5 years ago5 comments5 people in discussion

Are stub and citation needed tags allowed on user pages? RetroAsgardian (talk) 15:32, 8 January 2019 (UTC)

It depends... are you are talking about using these tags on a draft located in user space... or using them in some other way? Blueboar (talk) 16:01, 8 January 2019 (UTC)
@RetroAsgardian: I don't think so, as they add categories that user pages shouldn't be in. See WP:USERCAT, which says that User pages and user categories do not belong in mainspace categories such as Category:Living people or Category:Biologists, which are reserved for articles of the encyclopedia (in mainspace). This applies also to user subpages that are draft versions of articles. --DannyS712 (talk) 21:54, 9 January 2019 (UTC)
Stub categories aren't included on userspace pages; however, they should only be there on a page draft, not simply because they can. Same goes for the categories of {{Citation needed}}, which categorizes pages via {{fix}}, which in turn does it using {{Category handler}}'s "main" parameter. עוד מישהו Od Mishehu 12:27, 13 January 2019 (UTC)
  • Yes, since people draft articles in userspace, and (for WP:CREEP reasons) well never have a list of templates "forbidden" in userspace. The fix is to install a namespace test in the template so it doesn't categorize non-articles into article categories.  — SMcCandlish ☏ ¢ 😼  19:31, 15 January 2019 (UTC)

No-indexing

Latest comment: 5 years ago7 comments7 people in discussion

The article Rahaf Mohammed al-Qunun was nominated for deletion almost as soon as it was created. It is thus no-indexed.

The fact that the AfD is overdue to be snow-closed aside, why is this well-written article on an important topic hidden from search engines?

Is it right that any article can be hidden - effectively irreversibly so, for several days - on the whim of a single editor? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:13, 10 January 2019 (UTC)

Yes, because the opposite is allowing articles that definitely should not be indexed in (which is tricky to undo). Better a temporary delay for positives, which has very minor negatives vs some major negatives that could come from the opposite. Additionally, multiple incorrect AfD nominations or incorrect patrolling will ultimately lead to the removal of the rights to do either. Nosebagbear (talk) 00:19, 10 January 2019 (UTC)
Yes. No-indexing CSDs and AFDs is appropriate. There is no rush to index good new articles, whereas there are strong reasons to avoid indexing the worst cases. Until an AFD is resolved, we aren't going to run down the rabbit hole of assertions that "article-X is an obvious_keep/obvious_delete" and "obviously_should_be_indexed/obviously_should_not_be_indexed". Alsee (talk) 09:13, 10 January 2019 (UTC)
Current NPP practice is to index AfD - it's going to be decided one way or another by the community and if someone finds something non-notable in the interim the big "this might be deleted" serves as a warning. Current practice is to not index PROD or CSD until that has been dealt with since those could be removed more easily. Best, Barkeep49 (talk) 23:09, 10 January 2019 (UTC)
I think Pigsonthewing is talking more about Template:Article for deletion/dated which automatically injects NOINDEX to the page than about whether we need to manually review the page or not. Same as what's being discussed at #NOINDEXing all nominated articles. –Ammarpad (talk) 05:52, 11 January 2019 (UTC)
Putting aside the question whether readers need to be protected from AFD-ed content (almost certainly not; most of the world knows that Wikipedia's content is of variable quality and the biggest problem - incorrect information - isn't helped by NOINDEXing at all) is it really a good idea to hide away articles that could be improved? Jo-Jo Eumerus (talk, contributions) 06:58, 11 January 2019 (UTC)
Yes. I'd encourage you to use your imagination here. Short-term no-indexing (which would last no more than 7 days) is really pretty irrelevant; it's either going to be in the encyclopedia or it isn't, and by "encyclopedia" I mean a resource that is designed to exist for the long term. Just think, ten years ago Google only sent its crawlers through about once a week. Now it is including pages less than an hour old in its results. It can be devastating to the article subject who really shouldn't have an article, and subjecting those article subjects to an additional week of agony is highly inappropriate and fundamentally unencyclopedic. Risker (talk) 19:57, 15 January 2019 (UTC)

WP:MEDRS policy ?overemphasis on reviews

Latest comment: 5 years ago3 comments3 people in discussion

Hi. In my opinion there may be many medical experts in the short term future contributing to wikipedia. Several I know are reading our policies in detail as we speak. Medical experts now are only now starting to realise its importance. Wikipedia is not a place for medical reviews. However, as an expert, when we are reviewing we are repetitively taught to NOT to cite reviews, ever, rather primary sources. In Wikipedia, we need to give new studies their weight (please note I have never tried to cite my studies, only my review, which I consider should never be cited in medical literature - but it was, thats the point). But under WP:NPOV when making encyclopedic articles we should, in my opinion cite an important singular study, so the content is up to date. And then neutralise it with an expert opinion commenting it on its relevance, and experts that say it is irrelevant. I think that Wikimedia foundation may assist with the replication crisis in medicine in this regard. The reason I feel strongly about this is because experts such as myself find it hard to contribute, but are starting to realise that it may be more important than submitting to the New England Journal of Medicine sometimes. What do we think? E.3 (talk) 07:01, 18 January 2019 (UTC)

Re primary V secondary: If the explanation at WP:MEDRS isn't enough, see Wikipedia:No original research#Primary, secondary and tertiary sources. Wikipedia is based on reliable secondary sources, so while there is a place for primary, peer-reviewed research, reviews are much better because they help to establish the topic's notability and to avoid novel interpretations of primary sources. All analyses and interpretive or synthetic claims about primary sources must be referenced to a secondary or tertiary source, and must not be an original analysis of the primary-source material by Wikipedia editors. An encyclopedia and a scientific manuscript are very different creatures. ~ Amory (u • t • c) 11:21, 18 January 2019 (UTC)
You and other academics are taught to cite primary sources and offer your original thoughts on a topic: after all, if you have nothing original to say, what is the point in publishing your review, or giving you course merit. Citations in academic circles are not only there as evidence of source material to back-up a point, but also as part of the scientific courtesy of giving credit to the preceding science that established a fact. These are not Wikipedia's concerns and we do not want original thought. We need to publish the consensus opinion of experts, and the best way to do that is to read and cite the secondary literature rather than primary research papers. If a particularly study is exceptionally notable in its own right, then it can be mentioned in article text and for some facts, cited as a source about itself (e.g., number of patients recruited). But for conclusions (was it efficacious, safe, cost-effective, etc) we prefer to use secondary literature. For most facts, the reader is not interested in the study that established it.
There is a particular problem with editors who wish to promote a point of view at odds with the expert consensus. It is easy to cite individual research studies to back up claims that are not in fact considered robust or even truthful by experts. By writing "A scientific study ... found that ...." they appear to give scientific evidence for their POV. We would rather, in most cases, the article text just stated the fact, and cited a high quality secondary source. A good example of such are the systematic reviews performed by medical organisations to make clinical recommendations. They may grade the evidence into levels of quality and may even dismiss studies that fail to meet certain standards. This is the original research we want to build upon rather than doing ourselves. In contrast the authors of those research studies may over-inflate the robustness of their claims and merit of what they have achieved. Review papers are not the only alternatives, of course. For many topics, a professional-level and topic-specific textbook may be more comprehensive, though perhaps not so up-to-date. -- Colin°Talk 12:51, 18 January 2019 (UTC)

Current event templates

Latest comment: 5 years ago3 comments2 people in discussion

What is the point of current event templates? I think in most cases it would be clear that the article deals with a current event. Yes, the available information may be changing fast, but so what? The template is frequently used in cases where the article is being continually updated by a number of editors. There doesn't seem to be an obvious problem with an article like that. The problem is with an article that isn't being updated. Ironically, deaths attract the tag, even though the death is unlikely to change. Sure, we learn more information, but that is more true about living people. And what is a current event? Brexit has the template, even though it has been going on for years. Sure things are changing, but that is true for many articles, even for the article about the Earth. New information can be found about ancient history.--Jack Upland (talk) 22:42, 19 January 2019 (UTC)

I've always presumed that it's there to warn editors that an edit conflict is quite likely or that the information they'll add is likely to be changed very soon as newer and more accurate sources emerge. It probably also tries to say that if you are in the process of adding some information you read in yesterday's newspaper, you should check today's since some knowledge has probably changed already. The most useful feature is probably the category because it helps in monitoring pages that attract many (newbie) editors and probably spawn many discussions on the talk page that require consensus to form more or less instantly. – Finnusertop (talk ⋅ contribs) 21:16, 20 January 2019 (UTC)
Thanks, Finnusertop. That makes sense.--Jack Upland (talk) 08:13, 21 January 2019 (UTC)

Wikipedia:Articles with a single source

Latest comment: 5 years ago10 comments5 people in discussion

I think ALL articles with WP:1R should be deleted. The current guideline, which states only to add the template is not enough and swells the backlog. I think all editors (especially the new ones) should be forced to draft on userspace before publishing to mainspace. Reliability, even though it is a vastly different topic, is a huge part of notability. Of course there SHOULD be exceptions with highly reliable sources. But enforcing the no 1 source rule will make life a lot easier for this community. Please don't forget to ping me when you reply. ImmortalWizard(chat) 18:33, 19 January 2019 (UTC)

They should all be improved and further sources added, where possible. --Michig (talk) 18:36, 19 January 2019 (UTC)
@Michig: it would be really difficult for people to do cleanups. All I am saying is using the userspace efficiently. One should not simply create a page. ImmortalWizard(chat) 18:44, 19 January 2019 (UTC)
It's very easy for people to "do cleanups" based on one source in cricket articles. In fact, ImmortalWizard, you could easily do it yourself. If the article contains a link to CA, add a link to CI. And vice versa. If this is the only problem relating to "one source", it's just as easy to fix yourself as to complain about it. Once again you are contradicting yourself as to whether the problem is that the articles contain only one source or whether CA and CI are sufficient enough as sources. Bobo. 18:48, 19 January 2019 (UTC)
Wait no, I am not talking only about cricket, it's in general. ImmortalWizard(chat) 18:56, 19 January 2019 (UTC)
And what if I CAN'T find any more sources? ImmortalWizard(chat) 18:57, 19 January 2019 (UTC)
That depends. Are you referring to cricket articles, or articles in general? If you're still referring to cricket articles, as you have been throughout our conversations and on WT:CRIC, you know precisely where the "second source" is to be found. Bobo. 19:04, 19 January 2019 (UTC)
  • A good rule of thumb: If an article is under sourced, first try to fix the problem yourself... then see if others can help out. If you have personally searched for additional sources (per WP:BEFORE) and can not find ANY... then go to the relevant project talk pages and noticeboards to see if others can help. If that fails, you have grounds to nominate the article for deletion. Blueboar (talk) 19:25, 19 January 2019 (UTC)
@Blueboar: thanks for your advice. ImmortalWizard(chat) 20:55, 19 January 2019 (UTC)
  • I'm of the opinion that there are many cases where a simple merger to a larger, more inclusive article would be sufficient. Additional sources could then support creation of a stand alone article. --User:Ceyockey (talk to me) 22:46, 21 January 2019 (UTC)

Gender information

Latest comment: 5 years ago9 comments7 people in discussion

Wouldn't it make sense to formally indicate the gender of a person, for example in cases where the name is not an indication, and in any case the name and the use of gender articles might be insufficient.

Also, what is the policy on transgender persons? Without gender information, some transgender to males for example appear to have always been male, and equivalently females appear to have always been female. While there may be an argument that gender is a choice, it is also something people are born with by biological assignment and so information about gender is biographical. -Inowen (nlfte) 06:38, 21 January 2019 (UTC)

There is no need to record information pertaining to a person's gender or sex, unless that person's gender or sex is somehow related to their notability. RGloucester — ☎ 06:58, 21 January 2019 (UTC)
Sounds convoluted, so how about something simpler: If they are male, we indicate they are male, and female indicated as such. If they are transgendered, its indicated that they are transgender, and also which of the two kinds of transgender. -Inowen (nlfte) 09:33, 21 January 2019 (UTC)
It's not convoluted at all. Unless their gender status is important to why they're notable, it's not relevant to the article. — The Hand That Feeds You:Bite 22:37, 21 January 2019 (UTC)
The Manual of Style already has a section on how to handle gender identity, and another on how to handle name changes. Novusuna talk 10:48, 21 January 2019 (UTC)
May be worth pointing out that since I pointed out the relevant sections of the Manual of Style, Inowen has proposed changes on the MoS talk page. Novusuna talk 22:46, 21 January 2019 (UTC)
This seems like a job for Wikidata. Most biographies include this information in one way or another; standardized formally indicating things is very much Wikidata's thing. power~enwiki (π, ν) 22:34, 21 January 2019 (UTC)
@Power~enwiki: and they do.. wikidata:Property:P21 - <sarcasm> and so very very suprisingly it is not argued about all the time at wikidata:Property talk:P21 </sarcasm>. — xaosflux Talk 23:09, 21 January 2019 (UTC)
Interesting that I encountered my first trans-gendered person biography during the course of standard editing in a loooong time just a couple of hours ago, Ina Fried. The solution in this articles case is to handle via Categories, specifically Category:Transgender and transsexual women. I think that a combination of categorization and Wikidata (as noted above) is sufficient where the person's gender is not part of the person's notability, but this shouldn't be something writ in stone; like most things here, there's a wide range of acceptable solutions. --User:Ceyockey (talk to me) 22:43, 21 January 2019 (UTC)

Columns in reflists

Latest comment: 5 years ago5 comments3 people in discussion
  • Proposal: Make unwritten rule written.

First an option, now compulsory. Some people fancied columns and now no one is allowed to use the existing parameter. And I am accused of working against a 'consensus', also exceptionally bloody unpleasant. I disagree it is an improvement, and don't think I'm the only one who find them hard to read and naff, but if it is now compulsory the documentation and policy should outline that no one is allowed to continue using the single column function and they can be reverted to 3RR if they try. This should be VERY clearly stated in policy and documentation for the template. cygnis insignis 02:56, 8 January 2019 (UTC)

This is presumably about Template talk:Reflist#column default, where after much not-getting-it-ism, the OP was pointed to the means to set all columns to whatever width, or non-width, he pleases. --Izno (talk) 03:14, 8 January 2019 (UTC)
Izno, no, this is about stopping anyone else getting the same run around and being insulted for having a different view (not uncommon outside this place) and reverted to that preference. This is not the place for debate, or thug someone you disagree with. I'm asking that the pollicy and documentation reflect the result of consensus / fait accompli. cygnis insignis 03:51, 8 January 2019 (UTC)
Clarify that 'the means to change' is to change my own display, not use the existing parameter because apparently I am the only person who ever objected and not liking this is weird. It is shit design for digital documents, my opinion, it is very bad to have a unwritten rule that allows content creators to think they are contributing in an unobjectionable way and is distracted by yet another a claim by swaggering edit warriors that something undocumented at the template or MOS is compulsory. Clearly that needs to be documented, the unwritten rule be written, because I have better things to contribute than opposing what a clan of wikithugs staked out as their territory. I surrender, they won, change the documentation to stop giving ammo to the otherwise disinterested talk page goons who fight this out from article to article. cygnis insignis 07:06, 8 January 2019 (UTC)

Footnotes vs. parenthetical citations

Latest comment: 5 years ago1 comment1 person in discussion

I started a conversation on footnotes vs. parenthetical citations: Wikipedia_talk:Citing_sources#Author_prominent_citations. Please contribute to the conversation there. Coastside (talk) 16:33, 23 January 2019 (UTC)

Notability of elections?

Latest comment: 5 years ago8 comments6 people in discussion

Do we have a specific policy or guideline about the notability of elections, or do we simply apply WP:EVENT? I ask this becaus I noticed 1909 Invercargill mayoral election and similar articles, and I wondered if such a local elections with some 2,000 voters isn't too local in scope and coverage. We could make hundreds of thousands of articles about elections of that scale if we simply look at all local councils in democracies over the last 100 or 150 years, and perhaps we should limit ourselves to elections with a larger impact instead, and bundling such smaller elections in "local elections in year X in country or state Y" articles instead? All thoughts welcome. Courtesy ping @Pokelova:. Fram (talk) 07:27, 21 January 2019 (UTC)

@Pokelova: Fram (talk) 07:28, 21 January 2019 (UTC)

We generally don't have articles at this level of detail; if local elections at the same time in all cities in New Zealand, an article on 1909 local elections in New Zealand would be reasonable. The information could also be included on Charles Stephen Longuet, the elected mayor in this election. power~enwiki (π, ν) 22:33, 21 January 2019 (UTC)
I have no particular stance about the notability of these races, but these kinds of mergers result in articles that are pretty useless for readers. Merging them into personal biographies bloats articles with big tables that don't fit there, and merging them into mass-election article results in a huge page of elections with nothing much in common and sprawling tables that are hard to build upon into any kind of useful prose about the subject to inform readers. This is an issue better dealt with on a case-by-case basis as to whether they meet WP:GNG, but if they're important enough that the content needs to be on Wikipedia, they're far better dealt with in individual articles than creating bloated messes that exist for the sole purpose of denying them individual articles. The Drover's Wife (talk) 00:21, 22 January 2019 (UTC)
 
Boss
 
Boss
 
Boss
 
Boss
 
Phoning it in. Go home
To me it looks like an excuse to host photos of that amazing facial hair. When I look at the pages for 1907 Invercargill mayoral election, 1908 Invercargill mayoral election, 1909 Invercargill mayoral election, ... 2019 Invercargill mayoral election. I can easily imagine all of the content -- boss portraits included -- being merged into one table of election dates, candidate names, and vote counts, with a couple sentences of notes. How is that sprawling? Or uninformative? To me this kind of thing is easily solved. It could be a nice list page, and in the hands of someone who cared, an FL. --Dennis Bratland (talk) 03:37, 22 January 2019 (UTC)
It depends what you think readers are after - I'm super-nerdy about politics, but the only time I'm ever looking for names-and-numbers results is if I'm writing something for Wikipedia. If I go to an encyclopedia article on an election, the candidates' names, photos and a results table are the absolute minimum you'd expect, but one would normally expect some actual prose telling me anything whatsoever about the subject. I guess I don't see the point of bothering if you're going to put the most bare-bones of information in a format that prevents it ever being used to tell readers anything more useful than the exact number of votes some dude got. The Drover's Wife (talk) 03:50, 22 January 2019 (UTC)
I agree. I don't see the point of a table.--Jack Upland (talk) 07:54, 22 January 2019 (UTC)
I do not think there has been a specific cutoff of what electoral campaigns are notable for their own page. Within the past year, there is precedent for keeping individual pages of special elections for races for US Congress, such as 2017 Georgia's 6th congressional district special election. However, there was a strong debate about whether 2018 California's 10th congressional district election should be kept. My position is that is there is sufficient RS sourcing the electoral contest could be notable, including a local mayoral race. --Enos733 (talk) 18:24, 23 January 2019 (UTC)

new proposals regarding admin activity standards

Latest comment: 5 years ago1 comment1 person in discussion

see Wikipedia:Administrators/2019 request for comment on inactivity standards Beeblebrox (talk) 20:51, 23 January 2019 (UTC)

"Deletion" -> "Unpublish" and "Warning" -> "Final caution"

Latest comment: 5 years ago1 comment1 person in discussion
  Moved to Wikipedia:Village pump (idea lab)

— Preceding unsigned comment added by Xaosflux (talk • contribs) 12:50, 16 January 2019 (UTC)

Bad guidance in Template:One other topic

Latest comment: 5 years ago1 comment1 person in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Please join discussion at Template_talk:One_other_topic#Encourages_partial_title_matches about the guidance in the {{One other topic}} template which encourages partial name matches.

As per the Disambiguation Dos and Don'ts, editors are not supposed to "include every article containing the title." The template basically guides editors to do just that. Coastside (talk) 16:50, 24 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Why do we suddenly have thousands of article linked to Template:Curlie?

Latest comment: 5 years ago4 comments2 people in discussion

I gather that there used to be a project called DMOZ, and that Curlie is purporting to take over for DMOZ, but I feel like there should be some kind of discussion before we decide that thousands of our most prominent pages should link to one specific third-party website. bd2412 T 19:15, 24 January 2019 (UTC)

@BD2412: the DMOZ templates that are likely still in place was redirected to the new template over a year ago. — xaosflux Talk 19:25, 24 January 2019 (UTC)
See also Template_talk:Curlie#Requested_move_8_December_2017. — xaosflux Talk 19:26, 24 January 2019 (UTC)
I see. I'm not sure why we need these, but it's a small matter. By the way, the article, Curlie, is up for deletion. bd2412 T 20:06, 24 January 2019 (UTC)

Can you update the date?

Latest comment: 5 years ago1 comment1 person in discussion
  FYI
 – Pointer to relevant discussion elsewhere.

Please join the discussion at Wikipedia talk:Template messages#Can you update the date? --Redrose64 🌹 (talk) 12:09, 27 January 2019 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)/Archive_149&oldid=1079337152"
  NODES
Chat 9
design 4
Done 19
eth 74
games 1
News 12
orte 7
see 104
Story 10
twitter 3
Users 28