Wikipedia talk:Protection policy

RFC: Changing protection icons

I have noticed some of the icons have icons instead of a letter. So, why not change the letters to icons too? –User456541 16:20, 17 July 2020 (UTC) The proposed new icons are (they may require tweaking):

Versions	Pending changes	Semi protection	Extended confirmed protection	Template protection	Interface protection	Creation protection	Move protection	Upload protection	Full protection	Cascade protection	Office protection
Old icons
New icons

–User456541 16:20, 17 July 2020 (UTC)

What problem is this solving? GeneralNotability (talk) 16:33, 17 July 2020 (UTC)

@GeneralNotability: They are more descriptive than a letter and can be used on multiple language Wikimedia wikis. For example, the "WMF logo" on office protection makes people know that this page was "protected by the Wikimedia Foundation". –User456541 16:39, 17 July 2020 (UTC)

No comment if this is needed in general, but if so for interface prot, may be better to go with some code looking symbols instead of the wikilink one, /* perhaps. — xaosflux ^Talk 16:42, 17 July 2020 (UTC)

This sort of thing comes up every 6-12 months - before you choose the colour to paint the bikeshed, first establish that the bikeshed needs painting. Or, is there a demonstrable issue with the current set - are people saying that they are finding them hard to understand? If not, we're in WP:IDONTLIKEIT territory, which is always a dead end. --Redrose64 🌹 (talk) 20:57, 17 July 2020 (UTC)

I like the new "Office protection" lock, I strongly dislike the new "Extended confirmed protection" lock because it's hostile to colorblind users (identical to "Semi protection" except for color), and I weakly dislike the other changes, just because they're "meh" in general. Also, a random suggestion: for "Interface protection", perhaps use the MediaWiki logo instead of an opening wikilink. Jackmcbarn (talk) 04:34, 10 August 2020 (UTC)

How about, for Extended confirmed, if the person has a little crown on his head or other badge of office? EEng 04:46, 10 August 2020 (UTC)

I like only the office protected icon, since extended confirmed and autoconfirmed are the same to colorblinds, and full protection does not prohibit all editing. Also, I strongly dislike the interface and template protected icons, since this means that transclusions and links are protected. Anyway, I have thought up of adding a mediawiki icon to the interface protected, and have the creation protection changed to just a simple white paper. ThesenatorO5-2^{argue with me} 11:48, 15 August 2020 (UTC)

I like the new template and full protection icons. The office one makes sense too, however it might need little more padding inside the shackle. – Majavah ^{talk · edits} 20:38, 15 August 2020 (UTC)

Oppose This proposal feels very much like change for the sake of change, that accomplished nothing. * Pppery * _{it has begun...} 15:58, 16 August 2020 (UTC)

• I agree that the current system needs change to make it more accessible to readers, but I don't think the proposed changes go far enough. The four icons readers are most likely to encounter in mainspace are pending changes, semi, extended-confirmed, and full. However, the design of these has no solid hierarchy: it's impossible for a reading to tell without clicking through whether e.g. pending changes is lower or higher than extended-confirmed. This needs to be fixed by any potential redesign, and the proposal doesn't do so. {{u|Sdkb}} ^talk 21:06, 7 September 2020 (UTC)
• I like the office one in general (it could do with some tidying up perhaps, more distance off the bottom?). I explicitly dislike the change to extended-confirmed. Full and TE protections will take some adjustment at minimum, and overall I'm indifferent about both. Agree to changing your proposed IA one per xaos. Surprised you didn't change move protection, as that's always been one I never quite vibed with for some reason. Basically, Jack sums up my views. Full/TE could do with a change probably, but the proposed ones aren't quite there yet. ProcrastinatingReader (talk) 01:26, 8 September 2020 (UTC)

Support changes - Minor change, makes us more consistent with other Wikimedia projects, but, would propose using a different icon for extended confirmed protection. We can't forget that the design was originally changed to make the icons more accessible (see Wikipedia:Village pump (proposals)/Archive 155). Not having a distinct design defeats that purpose, so I instead propose using commons:File:Extended-protection-shackle-keyhole.svg Ed talk! 17:04, 8 September 2020 (UTC)

Support I like the designs better than the ones with just a letter. A letter is fine, but a {{ or [[ might be better. It's a minor change, but it should be a welcome one. Arsonxists (talk) 18:52, 14 September 2020 (UTC)

More New icons

The interface protected icon should have a {}, which is the base for most code, especially CSS and JS. File:Inteface Protected Icon.png ThesenatorO5-2^{argue with me} 12:05, 15 August 2020 (UTC)

The RfC statement, whilst certainly brief, is decidedly not neutral. --Redrose64 🌹 (talk) 19:55, 15 August 2020 (UTC)

@ThesenatorO5-2: there is an entire discussion open just above this one on changing icons, why are you starting yet another RfC on only a subset of that one instead of just commenting there? — xaosflux ^Talk 20:08, 15 August 2020 (UTC)

If I saw this lock and had to guess which protection level it represented, I'd guess template protection. IMO, that makes it a poor choice for interface protection. (Perhaps angle brackets instead?) Jackmcbarn (talk) 23:18, 15 August 2020 (UTC)

@Jackmcbarn and Jackmcbarn:: Got the message. Drawing new one. 10:22, 16 August 2020 (UTC)ThesenatorO5-2^{argue with me}

Oppose This proposal feels very much like change for the sake of change, that accomplished nothing. * Pppery * _{it has begun...} 15:58, 16 August 2020 (UTC)

I'm turning off the RfC so we can have a local discussion first. This isn't going to be a very clean outcome if we're still changing the proposal. --Bsherr (talk) 14:31, 18 August 2020 (UTC)

Pending changes protection Icon

— Preceding unsigned comment added by ThesenatorO5-2 (talk • contribs) 01:27, 17 August 2020 (UTC)

The issue is that these icons mostly are used at size 20px. Thus: . The white symbol on colored field is intended to provide legibility at that small size. The detail of this proposed icon is simply lost at that size, and the similarity of the colored field to the icon colors exacerbates the issue. --Bsherr (talk) 15:06, 18 August 2020 (UTC)

@ThesenatorO5-2: I'm a bit lost in this section - what is WP:PCR and what does it have to do with this section about "New interface protected icon"? — xaosflux ^Talk 15:41, 18 August 2020 (UTC)

Took me a minute too. It's a proposal for a pending changes protection icon. --Bsherr (talk) 18:43, 18 August 2020 (UTC)

@Bsherr: ok thanks - this entire l2 section is going to where, I'm upmerging it in to the already open discussion above about icon redesigns. — xaosflux ^Talk 18:47, 18 August 2020 (UTC)

The image has an invalid license claim. Its file description page claims that it was not previously published, that its author is ThesenatorO5-2, and that the license is {{cc-zero}}. All of these are disprovable: the image is clearly a composite of three, including a blank padlock similar to e.g. File:Pending-protection-shackle-no-text.svg and an eye similar to e.g. File:FlaggedRevs-2-1.svg, but there is no acknowledgement of the sources of these two components nor of their authors. Far worse is the inclusion of the Wikipedia puzzle ball File:Wikipedia-logo-v2.svg, which is not just the property of the Wikimedia Foundation but is also licensed CC BY-SA 3.0, so the use of any other license for a composite image including this logo, without acknowledging the original author in any way, is a violation of the licensing terms.

Also, why is the image stored in PNG format when the components are SVG? --Redrose64 🌹 (talk) 21:40, 18 August 2020 (UTC)

Got the message, changing license. ThesenatorO5-2^{argue with me} 00:06, 19 August 2020 (UTC)

@Redrose64: That is because I made that image in photoshop and do not know how to convert to SVG.ThesenatorO5-2^{argue with me} 00:06, 19 August 2020 (UTC)

Photoshop is absolutely useless for manipulating SVG images. Combining two SVG images is a simple matter of using a plain text editor (such as MS WordPad) to open both in separate windows, and moving the desired elements from one to the other. That is how I made File:Speed skating current event.svg from File:Speed skating pictogram.svg and File:Current event template.svg, There is never any need "to convert to SVG" because they are SVG to begin with. --Redrose64 🌹 (talk) 19:51, 19 August 2020 (UTC)

See e.g. File:Wikipedia Reviewer.svg for how to do the attribution and licensing properly. --Redrose64 🌹 (talk) 16:06, 24 August 2020 (UTC)

Move and upload protection

"Move protected pages, or more technically, fully move-protected pages, cannot be moved to a new title except by an administrator." "Upload protected files, or more technically, fully upload-protected files, cannot be replaced with new versions except by an administrator." Are these phrases true? For example, Special:Log/protect includes "[Move=Require autoconfirmed or confirmed access]". --NGC 54 (talk | contribs) 14:34, 15 September 2020 (UTC)

As I have pointed out several times before (most recently at Module talk:Protection banner#Move-protected), there are five levels of protection for every protectable action. A page that is move- or upload-protected need not be fully protected for that action; they might be template- or EC-protected, but it is pointless setting either of these to semi-protected. --Redrose64 🌹 (talk) 18:33, 15 September 2020 (UTC)

Extended Confirmed Protection

So I checked this in August, and it said it had to be at least 100 edits. Then a little bit later, I came back and it said “at least 400 edits”. Now in the Extended Confirmed Section it states that we need at least 500 edits to become an Extended Confirmed User. I tried looking in the edit history but it didn’t show any edits from 400 - 500. Is it a suppressed edit or is it something else? EpicRice (talk) 05:25, 17 September 2020 (UTC)

The threshold has been 500 edits ever since the protection level was first implemented, hence the moniker 30/500. Where exactly did you see the figures of 100 and 400 mentioned? --Redrose64 🌹 (talk) 09:28, 17 September 2020 (UTC)

Stated: “Granted automatically to registered users with at least 30 days tenure and 100 edits.” and “Granted automatically to registered users with at least 30 days tenure and 400 edits.”EpicRice (talk) 02:38, 18 September 2020 (UTC)

@EpicRice: it has been 30/500 the entire time, if you can point to a specific revision that had the wrong text we can probably see what happened? If you see this, also look at the revision history and see if it was fixed after someone just vandalized the description. — xaosflux ^Talk 02:40, 18 September 2020 (UTC)

Unless it was suppresed, I don’t see any edits or vandalism, I guess I must have viewed the wrong page last time. - EpicRice (talk) 02:57, 18 September 2020 (UTC)

The use of salting

In a recent discussion, it transpired that there are about 41,000 salted article titles (salting here refers to indefinite full creation protection). There's no doubt that the majority of these pages will never need to be created, but there is a certain number of titles that may later become eligible. For example, if an article about a person is deleted and salted at one point in time, ten years later a different person with the same name may become notable and the initial salting will get in the way of article creation. Or a different article may get created for which the salted title would make for a good redirect. It's hard to guess the numbers, but from the one page of log entries that were given in that discussion (presumably as an example of a set of particularly bad titles), it turned out that about 14% would make for acceptable redirects. Salting has undoubtedly saved us a lot of headaches, but it does come with its drawbacks.

The general understanding is that salting was mostly used in the past before extended confirmed protection was available. However, it still very much actively employed. I got curious and had a look at the last 20 saltings, going back about two weeks.

Salted pages of the last two weeks

Page Logs Creator editcount 1 Trilla Venus [1] 74 2 Gulf State Software LLC [2] 19 3 Marisa Peer [3] 327 4 Sasikanth Senthil [4] 8538 5 Harsh Beniwal (YouTuber) [5] 51 6 Jeff huber [6] 11 7 Aaryan Zaveri [7] 85 8 Melissa B. [8] 111 9 Naman Mathur [9] 57 10 Ashish Chanchlani [10] 179 11 Darajae J. Brown [11] 60 12 Sarojit Biswas [12] 19 13 Isaac Oladipupo [13] 3605 14 Laurence de Valmy [14] 154 15 Punta Gorda bus fight [15] 74 16 Hari Mari [16] 18 17 Baby Had an Accident [17] 28385 18 Sin Factor [18] 28385 19 Harpz Kaur [19] 332 20 Joe Tasker (Presenter) [20] 332 This was taken from the last page of the log. It excludes the three titles (Newton Arunaye‏‎, Soumita Saha‏‎, TerrytheVoice‎ ) whose full creation protection had a time limit.

Now, protection was probably justified in all of those cases. But in most of them, it's difficult to see why the protection was full rather than EC. For only four of the pages was the creator an extended-confirmed editor (and even then, for three of those cases it's not immediately obvious why full protection was used: the creator of #17 and #18 was indefinitely blocked, whereas for #4, a page speedied per G11, there appears to have been genuine disagreement on the creator's talk page about the notability of the subject). The remaining 16 pages were created by non-EC editors, and with a median edit count of 74, none look likely to pass the 500 mark any time soon. As far as I can see, for only two of the twenty pages the choice of protection level (full vs. EC) appears obvious: #13, where the creator has EC permissions, and #10, where the page had previously been recreated many times.

Is there anything I'm missing here? I would think that higher restrictions shouldn't be used when lower ones would do just as well. And how about the duration of protection? The assumption appears to be that salting should last forever: that's what the text in the policy page implies, and that's what appears to be done in practice (46 of the last 50 saltings were indefinite). But why is this so? Sure, some titles (like X is gay) will remain bad forever, but in the majority of cases salting appears to be used to tackle localised incidents of sockery, paid editing or vandalism, where it's not clear that the incidents would recur for years to come. Wouldn't it make sense to encourage admins to use protection for a long, but still limited, period of time? – Uanfala (talk) 14:23, 24 September 2020 (UTC)

100% agree with this analysis. #17 and #18 probably shouldn't be protected at all, given that (1) they weren't repeatedly re-created, only re-created once, and (2) both re-creations were by the same editor. That editor is blocked, and the block is all the prevention that seems to be needed for those titles. Plus, they are viable titles. "Sin Factor" may not be a notable album, but Googling it shows it's also the name of two books (probably not notable) and a plausible spelling of "sine factor", so it could make a useful redirect. A similar article, Sin Dome, was also re-created (once) by the same user; that title is not protected at all, it seems, and yet no disruptive re-creation. "Baby Had an Accident" might not be the name of anything notable that I can find right now, but it's hardly an offensive or disruptive title; it strikes me as quite plausible that "Baby Had an Accident" might be the name of some notable work, either now or in the future. BTW, the user wasn't blocked for re-creating the articles; from what I can tell, they were blocked for gross incivility, and these re-creations were all done on Sep 10, the same day as the gross incivility and block happened. I.e., this is not about problematic titles that consistently get recreated, it's about one user acting out, and the block, not the protection, is what prevents that disruption. I'd ask Floquenbeam to unprotect those two titles (and any other indef-full-protected titles that were only re-created by this one user).

I don't understand why #4 was protected at all, as it hadn't been repeatedly recreated either; judging from the logs, it looks like the "recreations" were redirects created as the result of draftification.) As for the rest, they didn't involve ECP editors, so I'm not seeing why we need a level of protection higher than ECP.

In my view, policy should be changed to this:

1. Full creation protection should only be used if there are 3+ ECP editors repeatedly recreating a "prohibited" title out of process. If it's only one or two ECP editors, just partial block those one or two editors instead. If the editors aren't ECP, then full protection should not be considered, only up to ECP protection.
2. If full creation protection is used, it should only be for a maximum of one year, at which point it should drop down to ECP (or no protection). If, again, there are 3+ ECP editors repeatedly recreating a title out of process, the protection can be bumped back up to full for up to one year. If it happens a third time, then indefinitely protect it (at that point, there will have been disruption by 3+ ECP over 2+ years, which is solid justification for full indef protection).
3. When it comes to ECP editors, blocks, not protection, should be the go-to tool. Lev!vich 16:38, 25 September 2020 (UTC)

I've unprotected the pages mentioned above. Fair enough. --Floquenbeam (talk) 16:47, 25 September 2020 (UTC)

Recent change to user talk

I just want to make sure we're all on the same page regarding the recent change to the wording regarding user talk protection. My understanding is that this wasn't a change in practice but a change to reflect practice. I support this, and other, such changes since policy and practice are intertwined. I just want to confirm that this is the best wording for that - I would hate for this new wording to inadvertently change practice. I don't have some other wording to suggest but throw this out there in case someone does. Best, Barkeep49 (talk) 15:20, 29 September 2020 (UTC)

Wrong description in tooltip

The full protection icon has the wrong tooltip text "This article is extended-confirmed protected", and the wrong alternative text "Extended-protected article" — Preceding unsigned comment added by 2A02:A313:A348:3780:E029:4D18:C077:F94D (talk) 02:15, 4 October 2020 (UTC)

Can you give an example of a page where the icon has the wrong tooltip? I checked one at random, and I didn't notice anything unusual. – Uanfala (talk) 13:19, 4 October 2020 (UTC)

Sure, for example, Margot_(activist)

<div class="mw-indicators mw-body-content">
	<div id="..." class="..."><a href="/wiki/Wikipedia:Protection_policy#full" title="This article is extended-confirmed protected"><img alt="Extended-protected article" src="..." decoding="async" width="20" height="20" srcset="... 1.5x, ... 2x" data-file-width="512" data-file-height="512"></a></div>
</div>

That's because Margot was extended-confirmed protected, later was full-protected, but the ECP icon was never modified. (CC) Tbhotch^™ 21:48, 4 October 2020 (UTC)

That shouldn't happen. It seems that {{pp-30-500}} is showing a tooltip that is appropriate for the name of the template, but displaying the correct icon for the actual protection level - a gold padlock marked "F", denoting full protection. I amended the article to use the generic {{pp}} template, which autodetects the prot level for both tooltip and padlock, but even so, Module:Protection banner (which is the module underlying Template:Pp-extended) needs investigating.

Note that this issue is nothing to do with this talk page, which is for discussing improvements to the page improving the page Wikipedia:Protection policy. --Redrose64 🌹 (talk) 22:20, 4 October 2020 (UTC)

Can admins edit all pages?

I have a question about your protection policy, can administrators edit all pages? Or are there pages that not even admins can edit? Gioguch (talk) 01:12, 7 October 2020 (UTC)

Gioguch, at the technical level, admins may edit any page except for users' personal Javascript and CSS pages, and those may be edited by interface administrators (which is an additional permission on top of "administrator" limited to a handful of trusted admins). At the policy level, the Wikimedia Foundation may "office-protect" pages, which means that only Foundation staff may edit; this is only a policy control, though, and admins are able to edit those pages (though if they do so, they may find their admin permissions removed in short order). Office protection is extremely rare. GeneralNotability (talk) 02:31, 7 October 2020 (UTC)

Most Special pages cannot be edited by anyone. There are also other interface pages which can be edited only by a certain user group. --Izno (talk) 02:34, 7 October 2020 (UTC)

And because there is always something else technical -- noone locally can edit in the Gadget namespace (such as the page Gadget:Invention, Travel, & Adventure) . — xaosflux ^Talk 13:57, 7 October 2020 (UTC)

But also from a "policy" perspective, if a page is fully protected out admins "may not" edit it except for certain reasons, admins do not have any extra "editorial" control of content than any other editor. — xaosflux ^Talk 14:03, 7 October 2020 (UTC)

@Izno and Xaosflux: Do you mean anyone and no one by "including administrators?" Actually, administrators technically can modify special pages, on Help:Special page it says:

Although special pages are not themselves editable, they generally contain standard text which is modifiable (although only by administrators).

And if Gadget:Invention, Travel, & Adventure can't be edited by admins by your definition, why does it say "fully protected?" By definition, fully protected means admins can edit. See Wikipedia:Protection policy#Overview of types of protection. Gioguch (talk) 23:44, 7 October 2020 (UTC)

Never mind, it doesn't say fully protected. It just tells you that you don't have permission to change pages in the Gadget namespace. Gioguch (talk) 23:47, 7 October 2020 (UTC)

Yes, on special pages there are often parts of them that use "messages" which are like templates - those are in the MediaWiki namespace, editable by admins. Some special pages don't have any messages though, for example Special:MathWikibase. — xaosflux ^Talk 00:25, 8 October 2020 (UTC)

Special pages aren't editable by anybody. This is because they don't exist except for a fleeting moment: when you follow a link to a special page, the server is triggered into running a query to collect the necessary information (an obvious example of this is with Special:RecentChanges which changes many times a second), assembles the page from the results of that query slotted into a kind of template that is partly built into the MediaWiki software and partly transcluded from pages in the MediaWiki: namespace (such as MediaWiki:Recentchanges-summary), then it serves the result to your client in the appearance of a "page", following which it is deleted again. So there is nothing physical which may be edited, except for those pages in MediaWiki: namespace.

Pages in MediaWiki: namespace are, by default, editable by admins only. This is not due to any protection - the restriction is built into the MediaWiki software: if I go to MediaWiki:Recentchanges-summary and select the option to change its protection level, it shows the present prot levels as "Edit: Allow all users" and "Move: Allow all users" - essentially, it's unprotected. There is a further restriction (which is also nothing to do with page protection) that pages in MediaWiki: namespace whose names end with either .css or .js can only be edited by WP:INTADMINs. Related to this, .css and .js pages in User: space can only be edited by their "owners" and by WP:INTADMINs - this means that I may edit User:Redrose64/common.js but nobody else's. At one time, all admins were also intadmins, but that changed in August 2018 when all admins lost the intadmin right and had to apply for it separately. Very few people have been granted it since then. --Redrose64 🌹 (talk) 08:17, 8 October 2020 (UTC)

Pages discussing Wikipedia's protection policy

• https://www.vox.com/recode/2020/11/2/21541880/wikipedia-presidential-election-misinformation-social-media
• https://slate.com/technology/2020/10/theresa-greenfield-iowa-senate-race-wikipedia-page.html
• https://thewire.in/tech/sushant-singh-rajput-death-wikiped-page-battle
• ...

CapnZapp (talk) 10:10, 3 November 2020 (UTC)

Change name

Gotta take Mark Esper out, listed as Sec Def. Need to update to current Sec Def Christopher C. Miller as of 11.09.2020