Wikipedia:Village pump (idea lab): Difference between revisions

I've seen a couple of heated situations over this week Naomi Wu and Sarah Jeong come to mind where the debate ultimately boils down to "should Wikipedia comment on somebody's tweets?" Considering the ephemeral nature of Twitter and the tendency of Twitter to produce drama my tendency is to say, we should not be commenting on tweets at all until such time as they become real-world news such as in the case of James Gunn or Canada-Saudi Arabia relations and even then we should only be commenting inasfar as those tweets had an impact on anything relevant.

Of course, WP:DUE exists. So does WP:BLP and those are supposed to provide some cover. But it would appear those policies are not working; this is especially the case when we have canvassing going on off-site and end up with a host of new accounts who want to make sure that a person's 3AM rage-tweet becomes a matter of permanent encyclopedic record. I think a clear and unambiguous policy on when a tweet can be considered notable, with very strict delineation is necessary. However right now my idea is only half-baked, which is why I brought it here to thresh it out. Thoughts? Simonm223 (talk) 19:16, 17 August 2018 (UTC)[reply]

Concur. Twitter is a bane to Wikipedia's reliable source policy also. If someone notable wants to discredit a report or finding, they don't need to use facts, just twitter bash it. There is no journalist providing context or counter-views, no report explaining their position, a factless simplification of complex issues - pure rhetoric. It bypasses the journalists. Wikipedia is founded on using reliable secondary sources of which Twitter is neither. Maybe all we need is a good essay that draws on the various policies. -- GreenC 20:26, 17 August 2018 (UTC)[reply]

I think at the very least, Wikipedia should have a policy that states that Wikipedia doesn't comment on Twitter drama until such time as the drama has independently sourced and long-term consequences. Simonm223 (talk) 17:21, 18 August 2018 (UTC)[reply]

There is already wp:twitter (ie. wp:socialmedia) is the policy. Also a guideline WP:Twitter-EL. It might help to have an essay that expands on these things in more detail with examples. -- GreenC 17:55, 18 August 2018 (UTC)[reply]

I think we should strengthen the policy towards Twitter, Facebook etc. The Web 2.0 public forum nature of these sites tends to lead to an even worse mess than the old (static) vanity websites. Daß Wölf 21:11, 18 August 2018 (UTC)[reply]

I wasn't aware of that policy and I haven't seen it cited previously so I appreciate that. Simonm223 (talk)

• The heart of the matter is people extending social media storms into WP. We are vulnerable to this as people mistake us for an extension of social media all the time. It is a matter of people misunderstanding the mission, which is described in WP:NOT. The relevant bit is WP:NOTGOSSIP (read it!) and also somewhat WP:NOTNEWS. These efforts to extend the storms into WP don't fit perfectly into either but NOTGOSSIP is closest. (There is also WP:NOTSOCIALMEDIA but that is directed more to people using WP like their own blog or twitter account...) Jytdog (talk) 16:00, 29 August 2018 (UTC)[reply]

  There's a few places where I want to pin item #3 of WP:NOTGOSSIP to the top of the talk page. In 140 point font. In bold. With underlines. Simonm223 (talk) 16:09, 29 August 2018 (UTC)[reply]

• Comment: WP:NOTNEWS and WP:NOTGOSSIP apply. The lasting impact of any given news cycle may not be known until the dust settles. And of course WP:BLP calls for a concervative treatment. That said, is there a concrete proposal here? K.e.coffman (talk) 23:17, 31 August 2018 (UTC)[reply]

The watchlist notification currently reads:

• You have 654 pages on your watchlist (excluding talk pages). Changes to pages you haven't visited since the changes occurred are shown with solid markers.

It's the second sentence that bugs me. It's awfully pedantic. I would like to change it to the following but have not been able to locate the template or its talk page, so I'm suggesting here that it be changed to the following:

• Changes to pages since you last visited them are shown with solid markers.

Thank you. Akld guy (talk) 06:24, 21 August 2018 (UTC)[reply]

Looks like a solid idea to me. Enterprisey (talk!) 06:26, 21 August 2018 (UTC)[reply]

• @Akld guy: I am not sure you copied the second sentence correctly, because this is what I am seeing: (compare with yours)

  Pages that have been changed since you last visited them are shown in bold with a green marker.

  and the message comes from MediaWiki:Wlheader-showupdated. Otherwise your suggestion looks okay.–Ammarpad (talk) 10:54, 21 August 2018 (UTC)[reply]

• Seems like a good idea to me - the complexity doesn't seem to provide anything Nosebagbear (talk) 14:20, 21 August 2018 (UTC)[reply]

The quoted text is from MediaWiki:Rcfilters-watchlist-showupdated and only seen by users with no checkmark at "Hide the improved version of the Watchlist" at Special:Preferences#mw-prefsection-watchlist. A checkmark gives MediaWiki:Wlheader-showupdated instead. Both messages can display in different ways depending on gadgets. PrimeHunter (talk) 14:49, 21 August 2018 (UTC)[reply]

TYVM, and please note that the bolding in my original post was for highlighting and does not appear in the displayed version. Akld guy (talk) 14:55, 21 August 2018 (UTC)[reply]

Update: I left a message on the Talk page of MediaWiki:Rcfilters-watchlist-showupdated, but there has been no response. In disgust, I have checked the "Hide the improved version of the Watchlist" in my preferences, thus going back to the watchlist's original version. A far nicer looking version, and it loads instantaneously versus the 3-4 seconds of the "improved version". Akld guy (talk) 21:59, 24 August 2018 (UTC)[reply]

I deactivated the ER, however if anyone would like to revisit it please verify and just set the answered= back to no. — xaosflux ^Talk 21:13, 26 August 2018 (UTC)[reply]

I did not withdraw my request, which I still feel has merit and has met with the approval of two other editors here. I am reinstating the request. Akld guy (talk) 21:23, 26 August 2018 (UTC)[reply]

And I would prefer not to have to reset but would still like the simple phrasing, as above — Preceding unsigned comment added by Nosebagbear (talk • contribs) 2018-09-04T15:05:53 (UTC)

@Nosebagbear: a requested change was made at MediaWiki:Rcfilters-watchlist-showupdated, did you want something else? — xaosflux ^Talk 16:03, 4 September 2018 (UTC)[reply]

In the climate pages were I edit (recent example Sea level rise, often there are numbers followed by units, and alternative units are presented in parentheses. This makes the text look intimidating to the non-nerd. Do we already have tools that allow editors to format their numbers with one system of measurement, and a button the reader can click to convert all such numbers to the reader's system of measurement when the page is rendered? That way the text would be clean lean mean but it would also be well globalized. NewsAndEventsGuy (talk) 14:12, 24 August 2018 (UTC)[reply]

@NewsAndEventsGuy: there is no tool to allow a reader to re-render a page with a different system of measurement. That is why we use {{convert}} (or similar templates) to present a measurement in one system with the alternative unit(s) in parentheses behind it. Imzadi 1979 → 21:24, 4 September 2018 (UTC)[reply]

Thanks, That's what I thought. IMO it would make science articles much more user friendly to allow some toggling in user preferences. Option-A like we do now, Option-B display first number entered in the template, Option-C convert first number (or only number) into system of user's preference. Would that be hard to code or hard to render NewsAndEventsGuy (talk) 21:44, 4 September 2018 (UTC)[reply]

One problem with this idea (which has been discussed before) is that it can be misleading. What is the correct conversion of "about four feet"? Of of "less than a millimetre"? In a sourced, encyclopedic context, I believe the correct approach is first to quote the source accurately, and then give a conversion to aid readers not familiar with the units in question. Peter coxhead (talk) 08:38, 5 September 2018 (UTC)[reply]

Now that this AfD has closed, I feel comfortable starting an RfC following up on this June 2017 RfC, specifically on what to do with articles meeting WP:NSPORT but remaining unsourced and with no sources forthcoming. This is intended to be a preliminary step before putting up an RfC to a) Give a sense of where community consensus stands and if it has changed significantly since 2017 and b) flesh out some options that are possible before putting it to the wider community. I see several options right now as to what should be done both in the interim and as a final result. First, it is possible to keep these articles in their current form, without further action, if community consensus has sufficiently changed towards including micro-bios on athletes. Tagging with the appropriate maintenance templates may be a more likely option. Alternatively, we can reformat these articles, perhaps merge them to consolidated articles (maybe a new type, associated with the events) or transwiki them to Wikidata. Finally, it may be possible to tag them then allow some time to find sources, after which the article can be delete​d or redirect​ed. Finally, if consensus has changed in the other direction, it may be that these articles will be delete​d. Draftify​ing is also possible, but I feel it would be counter-productive to improving the articles. If there are any options I have missed, or if you want to shout down this proposal, please comment below. Thanks!​​​— Alpha3031 (t • c) 09:53, 27 August 2018 (UTC)[reply]

I see no problem with tagging articles for improvement when improvement is necessary. But I don't want to open the door for mass deletions, since that'd disruptive to AfD. Maybe a merge would work if there were a logical place to merge them, but many of these events have 80+ competitors, and merging that many articles into one is unmanageable. Not to mention many of these athletes have competed at multiple events, or in multiple competitios, so where would they redirect/merge/consolidate? Smartyllama (talk) 10:54, 27 August 2018 (UTC)[reply]

I do find it both poor, unfair and imbalanced that the grounds for WP:NSPORT can be so much lower than for other articles - giving enormous numbers of athletes the same lower grounds that, say, populated locations have seems unjustified. Nosebagbear (talk)

That said, while I would institute higher requirements for new articles of this nature, I am a little torn about what to do about pre-existing ones. Clearly it would be a veritable deluge to delete/draftify all failing articles (whether now, or after a period of time). Obviously tagging would be the minimal requirement - I'm not sure if any other step should be taken. Nosebagbear (talk) 11:58, 27 August 2018 (UTC)[reply]

In any case, we'd need to establish consensus to change the guidelines before we go about deleting anything, even if we were to do that. And I wasn't seeing that consensus last time. Smartyllama (talk) 13:08, 27 August 2018 (UTC)[reply]

Obviously. Though at least a split/consensus lack on this is/would be less of an issue than the SCHOOLOUTCOMES saga, where the AfD Reviewer consensus clashes with the global RfC consensus Nosebagbear (talk) 13:46, 27 August 2018 (UTC)[reply]

Not allowing mass deletions is indeed sensible, and it was raised in the last RfC as well. I think there is a need to limit the rate these articles are reviewed at, or propose some other interim measure should consensus trend towards delete. Transwikiing might in fact be the simplest option after tagging, but I'm not sure if it's ideal. I'd agree that merging would seem to be one of the least favorable options. — Alpha3031 (t • c) 00:26, 28 August 2018 (UTC)[reply]

From the standpoint of notability, the subject-specific notability guides like NSPORT are meant to establish bounds for the presumption of notability that can be challenged later. That challenge is supposed to follow the advice of WP:BEFORE - the one nominating for AFD has to do the legwork to show that no sourcing appears to exist. That would likely mean in a case of this AFD getting local libraries in Jordan to review the newspapers of the time. Without that BEFORE, a proper test of the presumed notability cannot be made. So the AFD was launched on a bad note. But I do see a lot of people just iterating back "Notable because meets NSPORT" which is also not right. One can call out the bad challenge to notability by the AFD nominator, but re-iterating back NSPORT doesn't prove anything and its an empty !vote. When this type of AFD is raised, editors should be looking for sources. --Masem (t) 13:53, 27 August 2018 (UTC)[reply]

Exactly. Notability is fundamentally about sources, so it's demoralizing to see AfDs where no one is trying to demonstrate the availability of sources. Crying "Notable because meets NSPORT" is in essence saying "there are likely GNG-levels of coverage, none of which I am going to show to you even though that's what you're asking", i.e. the WP:MUSTBESOURCES fallacy. Conversely, a proper WP:BEFORE search should be presented by the nominator, although it isn't based on the presumption that the possible sources are of the most obscure kind. "Did you even go to the local library in his hometown and read through literally five decades worth of local newspapers they have in three languages?" is not an appropriate rebuttal. In the mass-media era, reliable sources that contribute to a volume of significant coverage about any given topic leave a substantial trail of records plus citations in secondary sources. WP:BEFORE recognizes this and explicitly sets the standard by listing the records you are supposed to search at minimum. – Finnusertop (talk ⋅ contribs) 14:46, 27 August 2018 (UTC)[reply]

In this specific case, we have a person that participated in the 1984 olympics, pre-2000 (my personal cutoff date where I'd expect finding digital information should be easy over print). One needs to look through Jordan national newspapers around that time (not a very large data set) to find if there is coverage. As I recall, the Olympics SNG for NSPORT is based on the fact that these people by virtue of participating for their country are going to get bios published in the country's national newspapers to build up on notability and expand the article, so that makes the target for finding sources very easy. --Masem (t) 15:05, 27 August 2018 (UTC)[reply]

• Articles should need sourcing. We should delete articles that lack sourcing to the level of verifiability.John Pack Lambert (talk) 01:46, 28 August 2018 (UTC)[reply]

  Johnpacklambert, since this pre-RfC is mainly intended to enumerate our options, what would you think about a transwiki to Wikidata? — Alpha3031 (t • c) 03:25, 28 August 2018 (UTC)[reply]

  For SNG-meeting articles (like this one) you need reliable sources to prove the SNG criteria was met (was he an Olympic athlete for Jordan?) WP:V is not optional. Yes, we want more in time, but that's the nature of the presumed notability of an SNG that we don't need deeper sources until they can be found (or shown they don't readily exist). --Masem (t) 03:45, 28 August 2018 (UTC)[reply]

  WP:V wasn't the issue in this AfD. We had citations from the IOC and from Sports Reference showing he did, in fact, compete in the Olympics and as such met WP:NOLYMPICS. Pretty much any Olympian is going to at least meet WP:V given Olympic competitors are well-documented. So is pretty much anyone meeting WP:NSPORTS in general - there is ample documentation of pretty much every sporting competition that would rise to that level. The issue is WP:GNG. Sports Reference and the IOC's website don't cover anything beyond the fact that the subject existed and competed at the Olympics, plus their results and brief biographical information. The delete !voters asserted there were no sources that met WP:GNG, not that there was no proof the subject even existed. Smartyllama (talk) 12:47, 28 August 2018 (UTC)[reply]

  Right, so why would the information need it's own page, then? If all we have is 1-2 lines of text to say about a subject, it is much more efficient to put it in another article. If all we have is a single line in a results table that we can possibly say about a person, the results table is sufficient. There's no need to have an article about a subject where there's not enough text to justify having a completely separate page. The information is sufficiently covered in other pages. --Jayron32 16:38, 31 August 2018 (UTC)[reply]

  I am surprised but maybe I'm just not searching right, but I would think that an article like "List of Olympics athletes representing (nation)" would be a reason set of lists to have and while for the big countries like US, China, Russia, etc. that send 100s of athletes, for these smaller countries this would be very maintainable, and could serve as redirect targets. If someone later comes to actually flesh out more than just a stub with reliable sources, great, otherwise we still have a searchable term and in a location that logically makes sense. --Masem (t) 17:09, 31 August 2018 (UTC)[reply]

  That would be reasonable. Following WP:SUMMARYSTYLE is always good; if a list is small enough to be maintained on one page that's fine, if the list becomes larger, then we break it into smaller lists. The issue is that having a separate page for every athlete is not necessarily the best way to organize this information. I'm not saying that information about such athletes needs to be scrubbed from Wikipedia, I'm just saying that having a bunch of separate pages to house tiny amounts of information each is not the best way to organize it. --Jayron32 17:30, 31 August 2018 (UTC)[reply]

  I have to think on this, but I wonder if for most SNGs, where a topic does meet the SNG but all you can say about the topic is a stub (1-2 sentences at most + infobox) if it should also be possible to have that information placed in a list/table article for redirection purposes until the stub can actually be expanded. It may be perhaps that we need something at WP:N and SNGs that strongly urge that SNG-meeting stubs should be assumed that they can be expanded, thus not deleted and remain search terms, but should avoid the stub nature if they can be grouped into logical lists that include the same information. But that's beyond this conversation's scope and represented a sea change in our approaches. --Masem (t) 17:37, 31 August 2018 (UTC)[reply]

  That explicit guidance has already been here at Wikipedia for at least as long as I've been active, 12 years or so. See WP:PAGEDECIDE which discusses when it is, and is not, appropriate to create stand-alone pages AND how to handle information when a stand-alone page is not the best option, to wit "Sometimes, understanding is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context. A decision to cover a notable topic only as part of a broader page does not in any way disparage the importance of the topic. Editorial judgment goes into each decision about whether or not to create a separate page, but the decision should always be based upon specific considerations about how to make the topic understandable, and not merely upon personal likes or dislikes." There's lots of other places where Wikipedia guidance encourages keeping the information together in one page rather than breaking out sub-stubs. --Jayron32 17:45, 31 August 2018 (UTC)[reply]

Leave them be, as long as they meet WP:V due to the IOC site. I don't see any good way to improve on the existing guideline at WP:NOLYMPICS. It will be easy enough to do a mass action in 10 years if consensus changes, or maybe editors will add other (likely non-English) sources. power~enwiki (π, ν) 16:42, 31 August 2018 (UTC)[reply]

I feel there is a strong case for any page on which discretionary sanctions has been authorised to indicate that in the edit/edit source tab of the article. Please read my explanation below and give me your thoughts

A hefty number of the pages on which discretionary sanctions are authorised don't actually let you know that is the case until you get sent the message. Mahammed Edit Page, Pakistan Edit page, Waldorf Edit Page etc.

This comes with a couple of potential issues. One, as discussed ad nauseam in a recent RfC, is the notices are generally sent (and/or perceived) in a rather hostile fashion - reducing the number sent because users are more careful because they are aware of DS being in place after clicking on edit would be beneficial. A more clear-cut issue is that of people forgetting that DS applies to a specific article after they've been warned - this can happen for edits who receive multiple ones (thus they blur) or received it a while in the past (since they stay "active" for so long).

Given the standard protection levels this point is more focused on intermediate/more experienced eds, since it shouldn't directly impact newcomers either way.

Homepathy Edit (a former DS topic) has a nice box that might work well (Template:Editnotices/Page/Homeopathy is the template)

Didn't want to dive in with this, in case there is some clear-cut reason why it isn't already done - but hoped there might be some initial support for it. Nosebagbear (talk) 15:17, 27 August 2018 (UTC)[reply]

Seems like a fine idea, so long as the notices are not very intrusive: as you said, the goal is to just remind people of their existence. Enterprisey (talk!) 15:56, 27 August 2018 (UTC)[reply]

As a practical matter, the discretionary sanctions process is solely under the scope of the Arbitration Committee, so you'll have to convince it of any proposed changes. Personally, I don't think it's inclined to change the current alert requirement by replacing it with an edit notice, as I think there is a strong desire to ensure that editors have been personally notified that a given area is under discretionary sanctions. isaacl (talk) 03:50, 28 August 2018 (UTC)[reply]

How many people do read editnotices? Jo-Jo Eumerus (talk, contributions) 06:10, 28 August 2018 (UTC)[reply]

isaacl - this most definitely would not alter the personally notifying set-up (including changing the fact that editors only count as warned once they have received a notice). This is a tack-on to help with the reasons given above. Additionally, if it has appeared over prior arbitration notices, that suggests their either ArbCom has agreed to it before (in which case it's just implementation) or that it doesn't need their agreement Nosebagbear (talk) 09:16, 28 August 2018 (UTC)[reply]

A check on the ArbCom page Alerts notes "Any editor may advise any other editor that discretionary sanctions are in force for an area of conflict." - it just doesn't count for formal alert purposes unless the template is used on someone's talk page. Nosebagbear (talk) 12:42, 28 August 2018 (UTC)[reply]

I find the banner editnotices in wikipedia quite helpful. I've not quizzed a statistically significant sample (though they'd have to either be completely useless or actively unhelpful to a significant group for it to be a counter-acting argument Nosebagbear (talk)

The first benefit you originally listed was to reduce the number of notices sent to individual editors; however with the current process this isn't achievable. Unless the process is changed to make an edit notice mandatory on applicable articles, editors can still be subject to discretionary sanctions if the edit notice is missing, which I'm not sure is what you are intending. isaacl (talk) 14:43, 28 August 2018 (UTC)[reply]

That point was to suggest that most people receive their formal DS notice once they do something that provokes irritation on the article. My suggestion was that if editors were aware that DS was in place from the start, then they might be less likely to make edits (esp unilateral edits) that caused said irritation (and thus the sending of notices). Nosebagbear (talk) 14:58, 28 August 2018 (UTC)[reply]

I'm all for the idea of using edit notices on DS topics to inform editors that an article is in a subject area under discretionary sanctions and what that means. That being said, I think there are a couple of issues here with what Jo-Jo Eumerus said about banner blindness -- we've seen that for years at Sega Genesis with editors ignoring an edit notice on what to do before suggesting a page move, and the edit notice banner there is bright and attention-grabbing. What we may have to do, and I recognize this is a side idea, is make edit notices more "noticeable". Making them a pop-up window instead of just a banner may be one idea, for instance, although I'm not qualified to comment on what might be the best answer from a technical perspective. It would also be helpful if those edit notices extended to mobile edits - as of right now, they don't, so users on a cell phone who are editing will never see the edit notice. Just some thoughts to consider here. Red Phoenix ^talk 03:16, 29 August 2018 (UTC)[reply]

A pop-up notice would be wildly OTT and drive users insane. People would have to be pretty banner-blind before it ceased to be of at least worthwhile usage. Not being a graphic designer I can't provide any great suggestions on what I'd use to make it more obvious without being more annoying than it's worth Nosebagbear (talk) 15:05, 29 August 2018 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

Neil's on wikibreak, since the 5th of this month. ^Thanks, L3X1 ◊distænt write◊ 21:12, 30 August 2018 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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
PAGE) 17:48, 5 September 2018 (UTC)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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. GMG^talk 23:35, 28 August 2018 (UTC)[reply]

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. GMG^talk 23:40, 28 August 2018 (UTC)[reply]

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)[reply]

(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:

This is a declared alternate account of User:2, for the sole purpose of proxy editing for User:1, for the reasons of accessibility or disability. Please note that proxy editing is allowed for users in good standing. All responses and other edits from this account should be treated as if they come from User:1, as all edits will be proxy edits for User:1.

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. GMG^talk 00:43, 29 August 2018 (UTC)[reply]

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. GMG^talk 00:51, 29 August 2018 (UTC)[reply]

• 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)[reply]

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)[reply]

Just as a note, original discussion here. I don't think we should replace {{official website|http://www.stockholmopen.se/en/}} with [http://www.stockholmopen.se/en/ 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)[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 https://www.google.com. But {{Official website|https://www.yahoo.com}} on Google will go to https://www.yahoo.com, even though it's placed on the Google article. GMG^talk 15:16, 1 September 2018 (UTC)[reply]

​ 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)[reply]

Oh. That seems like a bit of a silly category actually. Poor Abraham Lincoln's got no website at all. GMG^talk 16:03, 1 September 2018 (UTC)[reply]

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 (talk ⋅ contribs) 17:01, 1 September 2018 (UTC)[reply]

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)[reply]

Feel free to improve or suggest ideas about my new project Template:Wikipedia News. I'm going offline now and will be checking tomorrow on the discussion. Thanks, L293D (☎ • ✎) 02:58, 4 September 2018 (UTC)[reply]

Not clear what it is for. · · · Peter (Southwood) ^(talk): 06:02, 4 September 2018 (UTC)[reply]

What will this do that Signpost doesn't? --Redrose64 🌹 (talk) 18:33, 4 September 2018 (UTC)[reply]

Possibly, he hasn't discovered it yet. Any rate I am suspicious of anyone, who in a burst of initial enthusiam wants to reinvent the wheel. I have a long list of articles that need an immense amount of TLC that could use all that energy. --ClemRutter (talk) 19:09, 4 September 2018 (UTC)[reply]

Agreed that more context would be useful, but when I look at this I don't see anything like the Signpost (ongoing basis vs. every 1-6 weeks, short lines/notes/news vs. features/stories/op-eds...). Sure, some overlap, but if anything these sort of short bits would probably be better moved out of the Signpost and then transcluded/linked if others are interested to help out. What it does look to have some (a lot) of overlap with is Wikipedia:Goings-on. Looks like Enterprisey is involved at Goings-on, though -- pinging for $0.02 on this. — Rhododendrites ^talk \\ 19:21, 4 September 2018 (UTC)[reply]

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)[reply]

• 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
  PAGE) 16:50, 5 September 2018 (UTC)[reply]
  • 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)[reply]

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)[reply]

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)[reply]

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
PAGE) 20:33, 5 September 2018 (UTC)[reply]

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 deletion...it 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)[reply]

Berean Hunter, so basically you propose the current 2FA system, but without the key changing every single time... —TheDJ (talk • contribs) 11:40, 6 September 2018 (UTC)[reply]

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)[reply]

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
PAGE) 13:25, 6 September 2018 (UTC)[reply]

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)[reply]

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)[reply]

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 ( http://www.bitbabbler.org/ ). 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 ( https://www.veracrypt.fr/ ) 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)[reply]

• 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)[reply]

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 compromise...no 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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

It's opt-in. (Probably.) Enterprisey (talk!) 07:06, 8 September 2018 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

  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)[reply]

  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)[reply]