Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
« Older discussions, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26

Give Extended Confirmed Users/Non-Admin Users the right to semi-protect a page in order to deal with vandalism.

Today I was engaged in a suppression of a particular persistent vandal on theDracula (Castlevania) who was able to continually vandalize the page despite a RPP being filed along with an administrator request for intervention due to lag and Admin-Shortage. Perhabs a way to reduce the demand for admin services would be to re-distribute some of their powers down to other users by giving them the ability to semi-protect pages for a short period of time(1-2 hours) to reduce the delay and improve counter-vandalism efforts.Zubin12 (talk) 12:42, 28 August 2018 (UTC)

There was a recent major RfC on the creation of an additional userright to allow short term page protection. Strictly speaking only the original proposal which allowed quite a long time was closed as major consensus against. A mid-discussion proposal fairly similar to this got mixed views (I think that one mooted 6 hours). The userright would need to be significantly tougher to acquire than rollback/NPP (the general "intermediate" rights). Worthwhile having a hunt through the archives to find it to avoid duplication. Nosebagbear (talk) 12:57, 28 August 2018 (UTC)
Oh that's disappointing, Could I have a link to the discussion I'm not able to find it looking back through the archives.Zubin12 (talk) 13:01, 28 August 2018 (UTC)
  • Link to RfC. I'd suggest linking in NeilN if you want to discuss the concept in more detail - it would need to be excellent to even get some reasonable discussion as this is a functional perennial. You can have a look at his proposal if you search ctrl+f " I agree the original " Nosebagbear (talk) 13:03, 28 August 2018 (UTC)
I just went through a discussion today where if an extended-confirmed editor had been able to exercise their wish for protection they would have unjustly prevented an editorial opponent with a valid concern from editing and pretty much destroyed three months' work without scrutiny. I know this is a one-off anecdote, but I do see it happening regularly enough that I'm convinced that granting any blocking or protection powers to non-admins is and remains a bad idea. Ivanvector (Talk/Edits) 23:34, 28 August 2018 (UTC)
Just giving it to ECs would be an insane idea and wildly OTT. As I mentioned, were this 3-hr protect proposal to progress you'd need a firm set of requirements for an extra user-right to be provided/denied at WP:PERM.
Ivanvector,and Nosebagbear I understand your concerns that this power may-be misused in edit-wars but I don't think that a short duration 45 minute block with instant permanent revocation for misuse will be that much of a problem. Surely responding to handful users abusing a tempory protect function will take far less admin time than the current RPP system ?Zubin12 (talk) 14:19, 29 August 2018 (UTC)
  • EC is too short, 5 months 2 thousand edits would be better, and at PERM admins would look for a proven track record in counter vandalism. As for duration of application, I think 45 minutes max would be quite ok, and not against the Wiki Way. The perm could be limited to the mainspace only, and could also be made have its own tag and show up at a Special:UserTempProtected noticeboard where patrolling/subscribed admins could attend to it. Also, a rate limit of 2 temp semi-protects an hour would further prevent rogue users from abusing it. The standard "Users take all responsibility for their edits while using this permission and may receive sanctions up to and including indefinite blocks for misuse" would cover anything else. I can see an occasional user being confused (AGF) and using it enforce their preferred reversion (off the top of my head, when BMK was last dragged before AN3, it wasn't strictly vandalism, but he wasn't edit warring for his own sake, rather the good of the 'pedia.) but either the removal of the right, a community talking-to, or a block would solve the problem. It's fairly hard to disrupt the encylcopedia when you can only semi-protect the same page for 45 minutes out of each hour. I'd view rollback as a more dangerous tool than this. Thanks, L3X1 ◊distænt write◊ 13:46, 29 August 2018 (UTC)
Beyond prove track record in CV, a demonstrated correct use of RFPP would be necessary. A couple more thoughts: depending on coding complexity, preventing the same user page-protecting the same article twice within any 24 hr block would also hinder mis-use. I would say if this is in place, then a simpler 1 hr SP could be used. There are quite a few cases though where a 2hr SP would be better (particularly either in really peak times or the (0400-0700 UTC) "bubble" when the amount of admins online drops heavily). Nosebagbear (talk) 15:03, 29 August 2018 (UTC)
Nosebagbear, I agree with you on the RFPP trackrecord and on the once-per-day rules. I also agree with what Zubin12 said just above. Thanks, L3X1 ◊distænt write◊ 20:42, 29 August 2018 (UTC)
I'm just going to specifically link in @NeilN: since he was the one who wrote a proposed motion in the middle of the rejected one that is reasonably similar to this one and I think his thoughts might be helpful Nosebagbear (talk) 21:22, 29 August 2018 (UTC)
Neil's on wikibreak, since the 5th of this month. Thanks, L3X1 ◊distænt write◊ 21:12, 30 August 2018 (UTC)
Cheers for pointing out. Nosebagbear (talk)
  • So some summary thoughts from the couple of us currently involved, I'm not sure I'm fully in favour, but I think a pre-pre proposal would help clarify (italics indicate known queries):
  1. Protection would be limited to semi-protect.
  2. Protection duration would be limited to between 45m-2 hours (TBD).
  3. Right holders ("RHs") could only protect the same page once within 24 hours.
  4. RHs could only protect 2 pages within one hour.
  5. There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
  6. Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.
  7. The right could only be used in Main or Talk (not including User Talk) namespaces.
  8. Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted

Nosebagbear (talk) 22:43, 30 August 2018 (UTC)

That's a good summary, but I would ammend the requirment for RPP to simply record of previous vandalism on the page. The whole point of this proposal is to reduce the work-load on admins so requirng an RPP is kinda counter-produtive. Zubin12 (talk) 23:45, 30 August 2018 (UTC)
A good summary, but there are some points (I am directly responsible for a few, it seems,) which over time I have come to second guess. While we all agree EC30/500 is too short, I am not convinced 6 months is a good minimum, 3 months (or 90-100 days)might seem better. Our goals here are twofold (correct me if I am wrong): prevent misuse by the novices, and to prevent abuse by those with malicious intentions, such as socks and LTAs. Well, socks, LTAs and those who are NOTHERE usually either show their hand in the first week of editing, or are quite capable of playing a long game to get their way. (Jay, SwisterTwister, TheGraceful-Not-Slick-Enough, and Dr.Strauss fit into the sock category, they ran sock accounts for months and years before being discovered. Now TBH, they had other intentions than the disruption of the Pedia, but still, they can serve as a template) For these people 6 months isn't long enough, but neither is 5 years. For maximum effective use, to our own benefit and to the RH, I think shortening it would work just fine. As for edit count, I am fine to pitch that to the community, as I started out editing with all my heart and soul, and racked up 2000 edits quite fine. However, if our Service Awards are to indicate the general or expected progression of editting progress, if we are going to lower it from 6 months, the edit count requirement should correspondingly drop to 1000 edits as well. I have seen in recent discussions just about everywhere here, that more and more of us are delineating mainspace edits apart from all edits, and that is good, but admins at PERM aren't stupid, and would detect gaming when they saw it. Bots aren't giving out permissions to anyone who just breaks the minimum threshold, anybody making piddlesome edits to their sandbox would be shot down. I also think it would be beneficial to us and to novice CVU operators if the permission requirements weren't carved too deeply into stone. The goal here is to protect the encyclopedia against vandals in a more effective manner while helping to take a few straws off admins' busy backs. Assuming point 5 is accepted by the community sans amendments, I would like admins to not decline a RH just because they were 10 days or 200 mainspace edits short, if everything checkout.
Another thing (sorry I am running on) about point 5, (and I know these are just brainstorming points) 150 days is 5 months, so if 150 is going to be accepted, the block log thing should be amended (on paper at least) to reflect that.
Re: Point 6, I agree with Zubin a bit, it seems counterproductive to file a duplicate report. One thing I have noticed through my work in CVU is that it would seem that a short "Go away stop that please" technical restriction would be of infinite more use to the encyclopedia than actually having to fight prolonged revert actions against vandals. (Basically, for an obvious vandal, a 30 minute no frills block after just one penis edit would be more effective and better to all involved than having to wait for 4+ vandal edits, multiple warnings, and then AIV. If I were in charge I would rewrite the blocking and protection policies to encourage the use of very short term measures. But I digress…) If the Special:NonAdminSemiProtect page/queue were implemented, or maybe just for the first 10 uses by the RH, I think that would allow misuse to be corrected and abuse to be stopped easily enough, without requiring RFPPs all the time. I expect this tool (if enacted by the community) to be used quite often, and if point 6 was the rule, RFPP would be spammed into useless oblivion, requiring a dozen or so "clerks" to sort through them all and try to keep up.
If each mini-protection had a tag attached to it, a MW query (we are now in technical territory where I am quite ignorant) or bot could trawl through them all and look for anything suspicious: pages being mini-protected when they hadn't been previously edited by IPs/non-AC users for a week or more, repeitious protections that might indicate misuse, and flag those for human review. I'd expect a large false postive rating (how many of us have clicked the wrong button in TW or rollback and not noticed it?)
Currently, I think we have enough to prevent abuse, indeed Point 2 and 3 would make this harder to abuse than rollback, where one could cause an awful lot of damage in 4 minute if they so desired. Playing devil's advocate, if we hand out RB to over 6 thousand editors and let it be, why should it be so hard to get a right limiting you to disrupting 48 pages a day?
Last one for tonight, something should be done about spaces where this tool is applicable: main only? Main and Talk: spaces? If use in the userspace at all allowed? I can see a lot of newer users getting a nasty comment from a reverted IP (vandal or no) and applying temporary protection when they really of oughtn't. Thanks, L3X1 ◊distænt write◊ 00:59, 31 August 2018 (UTC)
Drops mike...saunters away
2 hours still seems short. During the RFC mentioned above I visited RFPP during off hours (early morning UTC, US holiday). Four requests took over 12 hours to be answered, the average answered request took over 9 hours to be answered, and there were 10 requests that were still unanswered after over two hours. I think 6 hours would be reasonable, although NeilN's proposed 3 hours is better than nothing. There would be a requirement to report all temporary protection at RFPP, so if admin response time at RFPP suddently improves, improper application of protection could be swiftly be dealt with by admins. --Ahecht (TALK
) 17:48, 5 September 2018 (UTC)
  • Response - Right, the comments above seem to pertain to points 5 & 6. I'll attempt to reply to this, bit by bit:
The time span was less "filter out bad eggs" and more "let policies fully seep in" - you can gather lots of CV experience and a fairly high hit rate, but I think accuracy still improves over time. Still, I'd be happy to say 90 days so long as CV and RFPP track record were fairly firm
I disagree about reducing the edit count. I think that level of participation is necessary - you might do it in (say) 120 days, you might take 200, but I think that 1000-2000 step is a fairly key one in "basic grasp on the intermediate bits" to "being firm on all the standard areas". I believe this right could be more troublesome than rollback error, and thus a higher level of edits should be required. If nothing else, it needs to be made clear that this will be a fairly rare user-right.
I'm fairly happy for a general all-space edit count, and leave it to the WP:PERM admins (who are definitely aggressive investigators) to check for system-gaming (even non-deliberate cases). I'm also happy for admins to judge edge-case exceptions - they usually do so via probation.
I originally did write time-in and block-free times the same, but amazingly all the user-rights are like this. I think it is there in the viewpoint that an newish editor with 3 months exp is easier to trust with tools than an 8 month editor with a block 4 months ago. I'm not sure myself either way, but if that is the general viewpoint then I'm not sure I'd dispute. I would want to note that perhaps it should be a 90 day clean-period for a single 3RR block.
Hmm, I can see the arguments here as regards time saving, duplicative, even more admin-time use etc. I can also see some massive concerns that RHs would be getting admin-lite powers without proper oversight - it'd be a shift of direction from "holding the fort while awaiting an admin" to "dealing with smaller cases alone". I'm concerned by the thought (and potential significant disagreement) - might be nice to get a couple more opinions.
I 100% agree that it should only be usable in Main and Talk spaces (not including User Talk). In fact, I'm going to add it as a mooted agreed point above.
My own thoughts A "Special:NonAdminSemiProtect" queue would be needed, however perhaps two other things could be useful: a more active use of parole when giving the right then usual, and some comment/tick box log that would require RHs to note 2 things: why they were using the right, and why it had to be used in place of other measures/warnings and AIV-block etc.
As well as an individual "1 use per page per 24 hours" perhaps we should make that a "1 (maybe 2?) use per page per 24 hours" in total". After all, if it is being that much of a problem it is most definitely a case for a "proper" protect.
Thanks for reading (and if you aren't L3X1, congrats for reading both posts!) - thoughts, especially on point 6? Nosebagbear (talk) 17:23, 31 August 2018 (UTC)
I've also amended another bit of NeilN's usage - the right should only apply against vandalism from multiple users, rather than the other reasons RFPP being used Nosebagbear (talk) 16:09, 2 September 2018 (UTC)
I get that other reasons (disruption, unsourced additions and removals, annoying edits etc) would be disallowed but are we sure "from multiple users" is a useful clause? I can't really remember anytime I was dealing with multiple accounts or IP hopper on the same article at the same time while an RFPP was filed. Most vandalism I know of is single-author.
Thinking point, allowing other reasons to protect would open a can of worms, but might it be worth it? This was on my watchlist this morning, Special:Contributions/Brent_william. None of the edits are vandalism, (wolf characterising the last one is up to him, I won't dispute it, but I wouldn't have done that myself), but the editor in question did need assistance in making whatever changes he wanted, and a technical nudge to a talk page might have helped hium. Thanks, L3X1 ◊distænt write◊ 18:56, 2 September 2018 (UTC)
L3X1 - Multiple users is necessary - otherwise these RHs would have lower requirements than formal RFPP. I also agree with them - I think the disruption of short protect is greater than the 4 or so actions to block a single user/IP and refer to AIV (which is more reliably quick than RFPP).
While of course there would be some benefits for additional benefits for blocking other categories, we need to limit to extremely clear-cut cases and the only general category where that is the case is vandalism. Nosebagbear (talk) 10:43, 3 September 2018 (UTC)
Only noting that "protecting against widespread vandalism" could be seen on the other side of the coin as "rump caucus trying to subvert the page consensus". The protection better get an endorsement by an admin in good standing otherwise the protection and permission needs to be revoked, for cause. Hasteur (talk) 16:39, 8 September 2018 (UTC)

"Helper" account for a user assisting another disabled user

There was a request yesterday that bounced around a few forums, about how a user could go about assisting another user who has a disability (arthritis, I think it was) and finds it difficult to edit directly. The "helper" user, Izzat Kutebar, proposed creating a second account for the disabled user, which they would then operate on the disabled user's behalf. By the time the question got to my attention Izzat had already been advised to ask in a different place several times, and was unfortunately but understandably upset about the situation. I responded that shared accounts are not allowed, but I think I need to go back on that in the interest of accessibility. This seems like as good a time as any to have a discussion on this topic, even though Izzat has supposedly permanently retired apparently because we did not jump fast enough for their liking; that's partly my fault.

On the issue of a "helper" account, I think it's fine, and if there is some policy that forbids it, we should revise it. Let me use the example (inapt here, but maybe not) of a deaf person's assistant, or a translator (or an ASL interpreter, I suppose). In sensitivity training, we are taught that even though the disabled person interacts with the assistance of a helper, you are not interacting with the helper but with the disabled person. I see this as an analogue for a disabled person who cannot operate a keyboard editing Wikipedia with the assistance of a helper who types for them - per our policies, the disabled person must have their own account, not share the helper's account. I think we can and should accommodate that.

As far as policy is concerned, the sockpuppetry policy (the policy on the use of multiple accounts) doesn't explicitly cover this situation, but I think it ought to fall under something similar to a designated role - the helper is a role and should not edit from their own account while helping the disabled user. But the policy also says that role accounts of this sort are forbidden (presumably meaning those roles that aren't "designated"), so if this is the approach then the policy needs to be adjusted. I'm not sure if we need to require disclosure or just advise that helpers can disclose privately to Arbcom if they wish.

I'm posting this here at the idea lab because I'm not really sure where to go with it, so input and/or other ideas are appreciated. Ivanvector (Talk/Edits) 23:30, 28 August 2018 (UTC)

If User 1 wouldn't be able to operate a keyboard, then wouldn't the account belong to User 2, with User 2 editing by proxy for User 1? WP:PROXYING is only prohibited in the case of users who are sanctioned. There is, AFAIK, no policy forbidding proxy editing for users in good standing. GMGtalk 23:35, 28 August 2018 (UTC)
As a concrete example, I was in the middle of the woods in February on a training exercise, and I spotted what I thought was copyvio, but was on mobile with crap for internet access. So I logged onto IRC and asked for someone else to look into it. That, to my mind, is proxy editing for reasons of accessibility, although in my case, not related to disability. GMGtalk 23:40, 28 August 2018 (UTC)
I suppose you're right, and I've done the same. I guess what I'm looking for is a way for us to recognize, for reasons of administration and dignity, that the account actually belongs to the disabled user, who edits with the assistance of the helper. The same as if the user edited with an assistive device, or text-to-speech or whatever technology is used for this purpose (I don't mean to offend anyone, I just don't know). I may be overthinking it. Ivanvector (Talk/Edits) 00:09, 29 August 2018 (UTC)
(edit conflict) Well you can't let it "belong" to User 1 (that would be shared), but you can have it "dedicated" to User 1. Something like:
It's not perfect, but it puts someone else in the position of having to open an RfC to disallow it, rather than you opening an RfC to allow it as a form of shared account. GMGtalk 00:43, 29 August 2018 (UTC)
I suppose if serious behavioral issues arose, all three accounts would be subject to sanctions. Just as if you asked me by email to join in your edit war by proxy, and then when I was blocked, I gave your email to ArbCom. GMGtalk 00:51, 29 August 2018 (UTC)
  • Wikipedia will bend over backwards to help with accessibility for to the project by the disabled, definitely including editing assistance by arthritic users. If User_1 needs assistance from User_2 to perform some edits, and these two people feel more comfortable not using their main accounts where User_2 is doing something for User_1, then by all means create a new User account, such as User:User_2 on behalf of User_1, making it clear on the main userpage that User:User_2 on behalf of User_1 is an account controlled solely by User_2 for the sole purposes of performing edits requested by User_1. This way, each account is technically controlled by a single person, and no one is sharing passwords. Ideally, User_1 will use their main account to confirm the arrangement.
This is off the top of my head. I am sure there are other solutions. --SmokeyJoe (talk) 00:34, 29 August 2018 (UTC)
I think that we're overthinking this. Two editors need two accounts (one each). We don't care whether those users type on keyboards, sing to their speech-recognition software, or ask someone else to press the buttons. What matters is that 100% of the words posted under each username are actually the words chosen by a single human. It is not a "shared account" if you are typing someone else's words. That makes you a meat-based implementation of speech-recognition tools. It does not make you a joint owner/participant in the account's activities. The only significant policy problem there is Wikipedia:Meatpuppet, but that is not unique to disability/transcriptionists. That problem is no different from the problems experienced by people talking about their edits in university dorms, on Facebook, or around family dinner tables. WhatamIdoing (talk) 20:59, 10 September 2018 (UTC)
  • Taking everything that's been said here into consideration, I think perhaps that nothing necessarily needs to change. If a disabled person has their own account but gets assistance from another person to physically operate the account, this is either not a violation of any policy, or we should ignore the rule. As for "helpers" who also have their own account, I would suggest that they disclose privately to Arbcom, keep their own editing separate (with a separate account) from the editor they're assisting, and have that be the end of it. Ivanvector (Talk/Edits) 13:42, 12 September 2018 (UTC)
    It's like an amanuensis. Consider Eric Fenby writing out a musical score: if it's his own work, then his name appears at the top; but if it was composed by his employer, then the name Frederick Delius is given. --Redrose64 🌹 (talk) 19:49, 12 September 2018 (UTC)

Removing official website

I would suggest the members who would like to comment on the question I am going to ask, to visit [1] link before answering my question. My question is: from the link, I was able to understand that the subpages like 1970 Stockholm Open and 1989 Stockholm Open doesn't have official website and doesn't needs to be linked. So, am I allowed to remove the official website link from the specific wikipedia pages or do I need to remove the magic word official website and provide it as a normal link? Currently, for the official website section, they follow single value constraint ie. only one page can have same official website. Adithyak1997 (talk) 15:07, 1 September 2018 (UTC)

Just as a note, original discussion here. I don't think we should replace {{official website|}} with [ Official website] in 1970 Stockholm Open only for the sake of a cross-wiki category check, since the use of the template on the page will let people know if there is an official website being linked to on the page. That being said, if a consensus determines that having an "official website" (of the organization) for an individual year of a tournament is inappropriate, then by all means feel free to remove the template (though linking to the Swedish Open website on the 1970 SO page makes sense to me). Primefac (talk) 15:15, 1 September 2018 (UTC) (please ping on reply)
This seems like primarily a Wikidata problem with P856. But anyway, the template only defaults to the Wikidata property if left blank. So {{Official website}} on Google will to to But {{Official website|}} on Google will go to, even though it's placed on the Google article. GMGtalk 15:16, 1 September 2018 (UTC)
I think the concern is more with pages populating Category:Official website not in Wikidata - the WD page for the 1970 Stockholm Open, for example does have an "official website", and thus it's in this cat. Primefac (talk) 15:48, 1 September 2018 (UTC)
Oh. That seems like a bit of a silly category actually. Poor Abraham Lincoln's got no website at all. GMGtalk 16:03, 1 September 2018 (UTC)
You won't see that category in the article Abraham Lincoln because what it really says is Official-website-defined-in-article-but-there-is-no-official-website-defined-on-Wikidata
As for the 1970 Stockholm Open etc., we shouldn't use the template or the phraseology. Remove the link because it contains nothing about the 1970 tournament. – Finnusertop (talkcontribs) 17:01, 1 September 2018 (UTC)
Since many of them are saying answers, I suggest somebody(after discussion)to tell a final response to this message as I am not familiar in doing that. It needs to be done only after discussion and not now. Adithyak1997 (talk) 17:33, 1 September 2018 (UTC)

So what change needs to be made?Any final result from this discussion?Adithyak1997 (talk) 14:36, 10 September 2018 (UTC)

Discussion for feasibility of a two password system

How hard would it be to implement a two password system in the database? A system that:

  • Allows for using a second password in conjunction with the first for increased user security. Password entropy increases by orders of magnitude when you have two.
  • Is an additional layer of security for those who are not comfortable using 2FA but it could be used with 2FA as well. Should also work with the "keep me logged in" 365 day cookies for simplicity and convenience. Transparent. See the admin newsletter from March where it is reported that only 16% of admins have enabled 2FA. I believe that editors/admins would be much more comfortable using a two password system.
  • Is optional for existing editors but recommended for those with advanced permissions. Possibly required for all new accounts; this may help stifle all existing automated account creation scripts (spambots) used by prolific sockmasters and UPE sock farmers. It would also slow down those creating multiples by hand, too.
  • Would allow the user more time to help prevent a compromised account in the event the first password is breached. The user should be able to change the breached password to maintain account control and the alert should encourage contacting a checkuser to go after the hacker.
  • First alerts the user when the first password has been breached as opposed to alerting on attempts at the first password. Current attempts at hacking passwords result in alerts that are causing disruption by encouraging users to change their passwords. Aside from alarming people, sometimes en masse, this has led people into locking themselves out of their accounts. If their password was already strong then they shouldn't have to change it. We shouldn't be allowing hackers and sockmasters the ability to cause that much disruption (see this article and Attack on Wikipedia accounts over).
  • Allows checkusers to check those that breach the first password and hopefully block underlying IP addresses. Currently checkusers cannot check hacking attempts although there is something in the works to remedy that.

Is this something that others would be interested in having?
 — Berean Hunter (talk) 16:42, 5 September 2018 (UTC)

  • It sounds interesting, but I'm having a hard time coming up with situations in which an attacker would be able to obtain the first password without obtaining the second. It's not like attackers are just running dictionary attacks against wikipedia (as that is easily detected and shut down). The only feasible ways are a) password reuse from compromised sites, b) phishing, or c) a breach of wikimedia servers. For password reuse, rather than activate a two password system, a security-concious user could simply use a unique password for wikipedia. For phishing or a breach of servers, the attacker would get access to both passwords. In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something). --Ahecht (TALK
    ) 16:50, 5 September 2018 (UTC)
    • Random note: I haven't enabled 2FA because I don't want my ability to edit Wikipedia to rely on my ability to pay my phone bill. --SarekOfVulcan (talk) 16:57, 5 September 2018 (UTC)
2FA, i.e. Google Authenticator, works offline. Just like a RSA security key generator. I suppose without a data connection, clock drift would eventually become a problem. But key generation doesn't depends on an active data connection. ☆ Bri (talk) 18:37, 5 September 2018 (UTC)
To me that Google Authenticator looks like it would negate much of the security benefit if it's all stored in the same device. Nevermind the added complexity... Jo-Jo Eumerus (talk, contributions) 19:11, 5 September 2018 (UTC)
Using google authenticator means that someone needs either physical access to your device or something like a remote-desktop connection to it. It prevents the vast majority of attacks where a remote attacker obtains your password either through password reuse, phishing, or a database breach that includes passwords but not OTP keys. --Ahecht (TALK
) 20:33, 5 September 2018 (UTC)
Ahecht, if your home was your account then the analogy is that I'm suggesting adding a type of entryway that is a mantrap (interesting that they have put that article up for can be sourced but I'll have to do it later today or tomorrow..example of mantrap). Instead of having one solid door with a deadbolt, you would have two where the design slows down an attacker and allows a better chance to respond. If someone gets your keys elsewhere because they picked your pocket (phishing) or left copies elsewhere (password reuse) or they got master keys from the manufacturer (compromised wiki servers) then they could still get in. My suggestion was never meant to be solutions for those problems. That would not negate the security value of the added entryway. Lock pickers would have two to get through. The analogy doesn't work fully because you would be able to do something about a person trying to break in the first door in real life but in our current situation, we can't.
"In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something)." No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Macon recommended. With what I'm suggesting, you would have two long sentences in separate fields with separate constraints. Entropy potential increases greatly.
If the mantrap is a sound, security best practice then why wouldn't it be in the virtual sense? Security is best practiced in layers and having more options is better.
 — Berean Hunter (talk) 11:30, 6 September 2018 (UTC)
Berean Hunter, so basically you propose the current 2FA system, but without the key changing every single time... —TheDJ (talkcontribs) 11:40, 6 September 2018 (UTC)
It is similar to 2FA in that you are using multiple tokens for authentication but would not require separate apps or timing sync. This would be built in just like the current password. It is simpler than conventional 2FA and you wouldn't have the opportunity to lock yourself out because of scratch codes.
 — Berean Hunter (talk) 12:01, 6 September 2018 (UTC)
Breaking a password isn't like picking a lock. Generally, it's not a brute-force attempt (as those are easily detected and blocked), but it's the equivalent of someone having the key to the door because they found your keys lying on the street. If you keep both keys on your keychain and someone steals it, a mantrap won't help. If you're trying to stop someone from picking the lock, instead of adding a second lock, you can just add more pins and use security pins. --Ahecht (TALK
) 13:25, 6 September 2018 (UTC)
I am wondering whether a person is more likely to use two 12 character passwords or one 24 character password. And whether they will remember the two 12 character passwords more than the 24 character password. If the answer to both questions is yes as I suspect then that would be a sound argument in favour of 2PA. Jo-Jo Eumerus (talk, contributions) 13:54, 6 September 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Re: " '...user could obtain the same result by simply concatenating the two passwords' No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Macon recommended."

If I remember correctly from my conversation with the developers, you can enter a passphrase of 65535 bytes (possibly larger -- I would have to check) but (and I did look this up before posting) only the first 256 bytes are used. Unless you are doing something fancy with Unicode characters, 256 bytes equals 256 characters equals 2048 bits.

Anything larger than 32 characters doesn't increase security -- it would take longer than the age of the universe to guess, so whoever is first in the concatenation could use up to 224 characters without compromising security. (Pro tip: always place the shortest password first when concatenating, just in case some bozo has a million-character password.)

Technical details: Wikipedia stores a hash of passwords using PBKDF2/HMAC-SHA-256 with 64000 rounds and a 128-bit salt. If you have a unified login on multiple projects, each project uses a different salt, so cracking a password hash on Wictionary or the French Wikipedia doesn't allow the attacker to log in to the English Wikipedia.

Re: "...alerts the user when the first password has been breached...", this is a terrible idea. Lets say we combine passwords using your scheme or concatenation -- it doesn't matter for the purposes of this illustration. You choose "ab" and I choose "XY", giving us a password of "abXY". That's 32 bits, so it would take 32768 guesses to try all possible 4-byte passwords. Now allow the fact that someone correctly guessed the first two characters leak out (Per Kerckhoffs's principle, we have to assume that the attacker can monitor the alert) So the attacker only needs to make 256 guesses to get the "ab", them 256 guesses to get the "XY". By alerting the user of a partial breach you have substantially reduced the strength of your password.

In my expert opinion, the scheme I described at Wikipedia:Administrators' noticeboard/Archive298#PSA: Admins might be better off with a long passphrase rather than two-factor authentication is more secure than the scheme described above. --Guy Macon (talk) 13:59, 6 September 2018 (UTC)

Re: Google Authenticator; really really bad idea. You are putting software on a smartphone, and if the smartphone is an Apple or Android device, it isn't secure. And closed source from a company which is known to gather user data? No thank you.
Here is how I protect my Wikipedia login:
My Wikipedia passphrase consists of 256 random printable characters, which I generated from my hardware True Random Number Generator. I recommend BitBabbler ( ). Every website gets a unique password, with the longest length they will accept.
I can't remember the passwords, so they are stored as ASCII text files, which I only access using Linux. The files live on on an SD card, encrypted with Veracrypt ( ) using a long but easy-to-remember passphrase, plus a 1MB keyfile on another sd card.
I keep copies of the two sd cards in multiple locations in multiple countries (I have a deal with two other crypto nerds -- they send me their encrypted backups and I send them mine).
And of course c0c5e71bca550e99a8ae6641e66c428e232051bade39cd47355634ff159c9475fffa1d12eee339aa401bfe5b31ff7fc352c2b9c6f002bfe82d03a6b3f9e40047 is a SHA-512 commitment my real-life identity. See Template:Committed identity. --Guy Macon (talk) 14:30, 6 September 2018 (UTC)
  • I'm in favor of multiple passwords, but not in this variety. I think we should be able to have "privileged" and "non-privileged" types of passwords as described here: phab:T153454. I don't think changing logon security from "something you know" to "something you know+something you know" is that beneficial. 2FA is a great idea, but we need to make 2FA recovery easier to use. — xaosflux Talk 14:34, 6 September 2018 (UTC)
Ahecht, I disagree. With our specific problems and existing system, the more frequent occurrences of hacking attempts are done by hand and perhaps to harass users because they can invoke the alert system and alarm them. It can be somewhat akin to repeatedly pinging someone as a form of harassment. "as those are easily detected and blocked" No, they are not easily detected and blocked. I'm a checkuser and I can't detect the IPs being used at all and no, they aren't usually blocked. What do you know that I don't? For me it is frustrating to see people get locked out of their accounts or they otherwise become alarmed/upset and we couldn't detect them. That is why your suggestion of security pins doesn't work as an optional instead of but perhaps built in as an additional feature. That would not forego our ability to have a crow's nest built in for the checkusers to see them and then detect and block. You may also be missing the value that this system could break existing automated account creation scripts and force a reset. Most operators aren't the coders and that sends them all back to the blackboard. Zombie machines would break, too. Not a bad way of performing a purge.
"If you keep both keys on your keychain and someone steals it, a mantrap won't help." I've already accounted for that with "My suggestion was never meant to be solutions for those problems." It is understood that if someone gets your keys elsewhere that there could be a claim to the contrary has been made. Are you suggesting that the concept of a mantrap does not have value or isn't a security best practice?
Guy, I wasn't suggesting that someone does this idea instead of yours but rather in addition to it. I think the long passphrases are a very good idea. "By alerting the user of a partial breach you have substantially reduced the strength of your password." You lost me with that. The person that possesses both passphrases has the ability to reset the first. That beats the current system where they own you as soon as they have used the first password. If you had a mantrap entry, you wouldn't want your alarm to go off at the first door? Huh?
Also Guy, this isn't about what professionals are doing...this is security for the masses. Like you, I use GNU Linux but we both know that it remains in the minority from a user experience perspective. Sometimes, it is hard to get people to try it, isn't it? Perhaps not for everyone. People aren't going to do all that you describe above because they are not as technically adept as the professional. They aren't enabling 2FA, either. Wiki editors could simply check a box in their gadgets and enable what I'm talking about. With new accounts having them enabled by default (still an optional idea), there would be no further complication than simply entering the second password. Remember that many folks don't perform regular backups so getting a more satisfactory security practice is a balance between the practical and the ideal. KISS principle applies over Kerckhoffs's principle here. This would offer a pragmatic approach where a solution has not been realized for the masses of our editors/admins. If there is a hole (exploit) to what I suggest then help me fix it but we need other options available. This option could also be quantified by similar results as those used to determine only 16% admins have 2FA enabled. We don't have a way of quantifying who decided to take your long passphrase suggestion so easily.
 — Berean Hunter (talk) 15:15, 6 September 2018 (UTC)
  • I just want to respond specifically to User:Xaosflux's two password idea. I think what we need is some kind of privilege escalation mechanism, like unix's sudo. I maintain two accounts (User:RoySmith and User:RoySmith-Mobile). I use the later on my phone because I don't want to leave an admin-enabled login session on a device that's easy to lose. It's a common practice, but it's awkward, and fails KISS. I'd rather have a single account, and a way to say, "authenticate and grant me admin rights, which automatically expire in N minutes". BTW, the best 2FA device I've ever used was the Yubi Nanokey. It lived in a USB-A port on my laptop, so it was always within reach, and totally convenient. If you make things easy to use, people will use them. If you make them awkward to use (i.e. having to type in a code), people won't use them. That's human factors for you. -- RoySmith (talk) 15:44, 6 September 2018 (UTC)
  • Can I add that you do not need a smartphone (or any phone) to have 2FA. There are other systems to generate that data, so long as that system has your 16 digit code and the current time, then it can work it out. I've enabled 2FA on my account and my Bot account (an adminbot). All I use is a simple python routine to give me both numbers (User:Ronhjones/2FA). I suspect there are other ways it can be done on the PC (you could always load up a Memu android emulator). Ronhjones  (Talk) 21:25, 12 September 2018 (UTC)
  • There's also Winauth, a portable open-source Windows 2FA authenticator that also supports encrypting your TOTP seeds with a FIDO U2F hardware token. --Ahecht (TALK
    ) 21:08, 13 September 2018 (UTC)

A bot to ping pending changes reviewers

So I'm looking at the pending changes backlog, and there are 39 pages in it. The oldest revision has been waiting for 45 hours; the next oldest, 25. We have over eight thousand users who could review these changes (probably less, once activity is taken into account), and somehow all of them have just not looked at Special:PendingChanges. I propose we have a bot that pings random pending changes reviewers (opt-in or experienced (>50 reviews) PCRs only? let me know) when the backlog gets over 10 pages (threshold up for debate) or a revision is over 24 hours old. Thoughts? Enterprisey (talk!) 06:14, 8 September 2018 (UTC)

So you are proposing having a bot nag me about pages with pending changes that are not on my watchlist? Editing Wikipedia is like drinking from a fire-hose; you need to focus on the articles you are interested in improving.--Guy Macon (talk) 06:45, 8 September 2018 (UTC)
It's opt-in. (Probably.) Enterprisey (talk!) 07:06, 8 September 2018 (UTC)
I imagine this falls under same de-facto policy as reporting AIV backlogs to AN. That is to say – don't. :P Although if people want to opt-in to the pain, then by all means. TheDragonFire (talk) 07:10, 8 September 2018 (UTC)
The thing is, the people at AN are probably very aware that AIV exists, and likely check it from time to time. I imagine many pending-change reviewers just don't check the pending changes page whatsoever, and this would just be a reminder. Enterprisey (talk!) 07:11, 8 September 2018 (UTC)
Who says that pending changes reviewers are supposed to respond to all pending changes requests on all pages? I certainly never signed up for that. Sure some reviewers would be willing to do that , but for them we have Template:Pending Changes backlog and Template:Pending Changes backlog-defcon --Guy Macon (talk) 18:11, 8 September 2018 (UTC)
This has started to go slightly off-topic, but I don't think many reviewers stick to a single topic area, as there's nothing in the pending changes guidelines that requires topic knowledge.
Another thing I could do is exempt editors above a certain number of edits, on the grounds that they would get annoyed by such a notification. Enterprisey (talk!) 18:40, 8 September 2018 (UTC)
I'm glad you mentioned those templates. I now have an instance on my user page, where I'm more likely to notice it. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
I mostly just forget that Special:PendingChanges exists, because I don't have these pages on watchlist. I will add it as a thing To Do. --Izno (talk) 12:04, 8 September 2018 (UTC)
  • SOunds nice, ATM. I don't put those pages on my watchlist because there are a few thousand of them, and also all the normal ok edits that happen to them would clog it. If you are willing to spend the tiem to make a trial bot, I might opt in for a few weeks next spring when I have time. Thanks, L3X1 ◊distænt write◊ 16:02, 8 September 2018 (UTC)
    Yeah, since there are so many PCRs I'd imagine, by default, the bot would ping a given user only once every six months or some massive time period like that, when the backlog gets quite high. Enterprisey (talk!) 18:42, 8 September 2018 (UTC)
    I'd be interested in a ping when certain criteria are met, such as >50 entries outstanding, or >48 hours pending, with a cooldown of X days (configurable). This could even be entirely opt-in and user-customized with a template like the Miszabot config. The bot could just check the talk pages of all reviewers (or check for transclusions of the hypothetical template) so it can know who to ping. It doesn't even have to clutter the user's talk page either, since the bot could just post on a central PC status page or something. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
  • I wonder if bots can just ping notifications without the talk page spam. I wouldn't mind a bot that did that for a lot of the things around the wiki. --Izno (talk) 15:52, 10 September 2018 (UTC)
    Yes, that would definitely be a good idea. Enterprisey (talk!) 06:34, 12 September 2018 (UTC)
  • This looks like a nice idea, if only the bot could ping and not spam talk pages. I always forget about Pending changes L293D ( • ) 12:20, 12 September 2018 (UTC)
    Yes, I've decided to have it ping users on a talk page, so that the targeted pages (maybe two or three per user pinged) will show up in the notification. I could also ping users from an edit summary directly, thus avoiding cluttering up a talk page, but that would be harder to audit. Enterprisey (talk!) 20:00, 12 September 2018 (UTC)
  • I think it is commons: that does this: displays a "pending changes is backlogged, please help" to only pc access people - might be on watchlist only. — xaosflux Talk 12:40, 12 September 2018 (UTC)
    Actually, that is "patrol backlog", but same concept. — xaosflux Talk 12:41, 12 September 2018 (UTC)
  • I've opened a discussion at VPPR. Thank you all very much for the input. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

Logout tool

I made this suggestion over at meta 3 months ago and nothings come of it, so I wanted to post it here and see if perhaps a more active project would be interested in running with it. I'd like to propose the creation of a universal logout tool that can see what devices currently read your account as being logged in and log out of all of them so as to better insure account security. I know that certain password protected services (such as Gmail) have this option in place to unilaterally log out of all devices that read as having logged onto or into your account, so utilizing the tool for Gmail logs you out of your desktop, laptop, smartphone, and ipad devices which then require you to log in to all devices again. Such a tool would be a good fit for Wikipedia, I think, especially since many of us edit from public computers, mobile devices and the like. Being given the option to log out of all devices at once would increase account security and help keep accounts in account holder's hands. TomStar81 (Talk) 19:10, 17 September 2018 (UTC)

Showing a list of logged-in devices would require wiki servers to keep a log of which devices are issued persistant cookies. I'm not sure what the current data rentention policy is for data such as device type/browser/etc, but IP addresses used to access the site are currently only stored for three months (which is shorter than the 1-year expiration for checking the "keep me logged in" buton). As to the second part, clicking the "log out" link on any device should regenerate your login token, signing you out on all devices. See phab:T51890. --Ahecht (TALK
) 20:25, 17 September 2018 (UTC)
Thinking more about this, there might be some merit in allowing all users to run the WP:CheckUser tool on themselves, to see if they can spot unusual activity. It wouldn't exactly show a list of logged-in devices, but it would give users a window into their own account activity. Only downside is that access to such a tool could help sockpuppets to make sure they are properly covering their tracks. --Ahecht (TALK
) 20:41, 17 September 2018 (UTC)
I don't think a hacker getting access to your account should be able to see your IP address. PrimeHunter (talk) 21:53, 17 September 2018 (UTC)
@TomStar81: actually using Special:UserLogout on any session should log you out of every session already - though it doesn't let you 'display' the sessions. — xaosflux Talk 23:17, 17 September 2018 (UTC)
Well that's good news! If you log out from any machine you should log out form all machines, which helps keep accounts secure. Thanks for the reply and for entertaining the idea (although in this case it appears you guys were one step ahead of me :) TomStar81 (Talk) 23:52, 17 September 2018 (UTC)
Only tangentially related, but for what it's worth, you can see any applications you've granted authorization to at Special:OAuthManageMyGrants. ~ Amory (utc) 01:29, 18 September 2018 (UTC)

2 new ideas

I don't know if this is the right place to ask but I came up with these 2 ideas:

recognizing blocked users on history pages

When viewing history pages there should be a way to tell that a user is blocked, for example, to have the word "(blocked)" after the blocked user's username. -- -- -- 06:13, 20 September 2018 (UTC)

Check out the "Strike out usernames that have been blocked" gadget in your user preferences. DMacks (talk) 06:31, 20 September 2018 (UTC)
thanks, that was quick. -- -- -- 07:42, 20 September 2018 (UTC)

watchlist for all Wikimedia sisterprojects

To have all of my watchlists on a single page, so that I shouldn't have to visit each sisterproject separately in order to check my watchlists. Thanks in advance, -- -- -- 06:13, 20 September 2018 (UTC)

See Wikipedia:Global, cross-wiki, integrated watchlists. DMacks (talk) 06:32, 20 September 2018 (UTC)
thanks, I'll check when I'll have a chance. -- -- -- 07:42, 20 September 2018 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (idea lab)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA