Commons:Village pump/Proposals/Archive/2019/01

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Wikimedia Commons sitelinks on Wikidata (external RfC)

In case the above link doesn't work well, I've started a request for comment regarding Wikimedia Commons site links on Wikidata at "Wikidata:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links". I don't know where to properly announce it so I'll place a link here and at the regular village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:52, 15 January 2019 (UTC)

Give autopatrolled users more upload options

PROPOSAL PASSES:

The extended uploader right will be depreciated and all those with that right will be granted autopatrolled (if they do not already have it). The autopatrolled user group will gain the upload_by_url flag and the filter will be updated to allow autopatrolled users to upload .MP3 files. --Majora (talk) 02:58, 17 January 2019 (UTC)

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

Note: this proposal depends on phab:T89131 (implement server side Flickr reviewing). If accepted, it will not be implemented before {{FlickrVerifiedByUploadWizard}} has been replaced/complimented by {{Flickrreview}} and/or MediaWiki is given the ability to perform server side reviewing. They are, in a way, waiting for us. If we accept this, T89131 won't take long.

The actual proposal is below the intro, you can skip the intro if you already know what this is about.

Intro/background

Extended uploaders is a user group for users who are trusted with the following:

  • Uploading files from a URL (limited to this whitelist)
  • Uploading MP3 files (regular users need to convert their MP3 files to Vorbis, Opus or FLAC before uploading, a process in which quality is lost for Vorbis and Opus)
  • Uploading files from Flickr using UploadWizard (nothing you couldn't do without Extended Uploader, it's just more convenient.. not to mention Flickr2Commons)

There are currently 67 extended uploaders. From those, only 3 (three) have ever uploaded more than 6 (six) files from Flickr using Upload Wizard: Koavf (39 files), GreenMeansGo (45 files) and Ixocactus (79 files). You will understand in a moment why that's important.

But first, let's think about autopatrolled users. Autopatrolled users (we have 5953 of them right now) would be deemed smart enough not to upload albums from Madonna and Robbie Williams. Else they wouldn't be autopatrolled. So allowing autopatrolled users to upload MP3 files, I don't see why not. Uploading files from a URL, with the whitelist restriction which is already in place, has minimal potential for abuse. Even less so for autopatrolled users.

Leaving one thing: uploading files from Flickr using UploadWizard. There has been some controversy around Flickr2Commons with some users suggesting to put a ratelimit on Flickr2Commons. Which didn't happen. But for Flickr import using UploadWizard, I will include an option for that. This is why I had to tell you about the three users: if we decide to do this with a ratelimit, only three users will be somewhat affected. And even they probably won't notice if we don't pick some extremely low number.

On to the votes. If there are not enough supporters for this proposal without ratelimit, we will see if there is enough support with a ratelimit. - Alexis Jazz ping plz 10:31, 9 December 2018 (UTC)

The actual proposal

Allow all autopatrolled users to upload files in MP3 format, upload files from a whitelisted URL and upload files from Flickr using UploadWizard.

Support, with or without UploadWizard-Flickr-specific ratelimit

Support, with UploadWizard-Flickr-specific ratelimit, don't forget to include a maximum number of UploadWizard-Flickr uploads per minute!

  • (none yet)

Leave everything as it is (oppose)

  • (none yet)

Discussion

Umm...Not particularly fond of the idea of extending the Flickr url upload until its fixed. Did we ever figure out why you have to button mash the upload button and get 9000 license review errors when you do? It was still broken as of 6 December. GMGtalk 12:12, 9 December 2018 (UTC)

Or maybe opening it up to lots of people will give an incentive to actually fix it? GMGtalk 12:14, 9 December 2018 (UTC)
@GreenMeansGo: the abuse filter has been fixed for extended uploaders by Kaldari on 6 December. Replacing/complimenting {{FlickrVerifiedByUploadWizard}} with {{Flickrreview}} is not technically complicated, and if this proposal is accepted there will be a clear incentive to patch it. - Alexis Jazz ping plz 16:49, 9 December 2018 (UTC)
Okay. Well, as long as we're not getting a zillion files that need fixing, or a zillion comments from people who haven't figured out yet that if you just button mash you can bypass the initial error you get. (I now realize why no one on wiki or on IRC knew the answer to the problem, because only three of us have ever actually used this feature apparently.)
I'm still a little wary about MP3s though. From the perspective of monitoring latest files...yeah...if someone uploads Aaron Copland...obviously that a copyright violation. If someone uploads whatever is on Tamil or Mandarin radio, there ain't no google image search for that. GMGtalk 17:28, 9 December 2018 (UTC)
When UploadWizard adds {{Flickrreview}}, nobody will get any error. And there are actually more people who use the feature, but they are license reviewers and administrators. So they never got any error. As for MP3s: it's still only autopatrolled users. And any user (even without autopatrol) can upload .ogg, .opus, .wav and .flac. We just use the description, license, source and have people who understand the language look at it. If somehow huge problems arise (which I don't believe) that can't be solved by taking the autopatrol status for problem users away, another proposal to take MP3 away again will be here soon enough, I'm sure. - Alexis Jazz ping plz 18:27, 9 December 2018 (UTC)

Not sure how you got your stats. I am convinced I have used the upload wizard to upload from Flickr albums. --Fæ (talk) 13:34, 11 December 2018 (UTC)

@Fæ: so have several administrators. You are not listed as an extended uploader, therefore you are not in the stats. - Alexis Jazz ping plz 23:41, 11 December 2018 (UTC)
Oh, I vaguely remember the discussion where this was created, but I no longer remember the logic of why I am not an extended uploader and presumed I was one. Can't keep in all in my head. :-) --Fæ (talk) 00:01, 12 December 2018 (UTC)

So just to be clear on what is being proposed here. The following flag is going to be added to the autopatrolled user group, upload_by_url as well as modifying the abuse filter to include autopatrolled. Just so you know, flickr is already included on the upload_by_url whitelist so granting that flag should allow that ability via the upload wizard. If this passes, what then would be the point of the extended uploader group? Really the only specific flag that is granted by that group is the upload_by_url and the abuse filter exemption. Both of which are being proposed here to be added to the autopatrolled group. Therefore, this proposal would make extended uploaders obsolete. Correct? --Majora (talk) 22:39, 13 December 2018 (UTC)

@Majora: absolutely 100% correct. The original title (which I changed before publishing) was something like "Make all autopatrolled users extended uploaders". But stating it so bluntly directly in the title without any nuance didn't seem quite right. And there is the option of supporting this proposal with a ratelimit, that could technically be a difference for extended uploaders who wouldn't have that limit. Although only three users (Koavf, GMG and Ixocactus) would realistically be somewhat affected.. and two of them have already supported the proposal.
Another thing (well, related): does what you say mean that anyone who has upload_by_url has the "Share images from Flickr" button? Who else (that isn't a license reviewer) has upload_by_url? Gwtoolset I guess? - Alexis Jazz ping plz 01:57, 14 December 2018 (UTC)
@Alexis Jazz: It is my understanding from a cursory look at the extension that yes, anyone with the upload_by_url flag should have the "share images from Flickr" button. Per Special:ListGroupRights, image reviewers, bots, extended uploaders, GWToolset users, and administrators have that flag. If this proposal comes to pass I really don't see the need to have two user groups that have the same basic function so retiring extended uploaders would probably be for the best. --Majora (talk) 19:32, 14 December 2018 (UTC)
@Majora: I noticed you didn't vote. You don't have to, obviously, but I'm curious how you feel about this proposal. If you see any particular issues, I could perhaps work on that. - Alexis Jazz ping plz 17:51, 10 January 2019 (UTC)
I'm pretty neutral on the idea to be honest, Alexis Jazz. I don't see any problems with this but I also really don't see the need to collapse user groups either. Sorry, I just don't really have an opinion on this one either way. --Majora (talk) 21:43, 10 January 2019 (UTC)
@Majora: a major issue (that keeps popping up) is the state of Flickr2Commons and its lack of maintenance. I think this is the third time it has recently been proposed to disable Flickr2Commons. We really should have alternatives and UploadWizard's Flickr import feature is the most feasible, but out of reach for most users. - Alexis Jazz ping plz 23:36, 10 January 2019 (UTC)
Like I said, I don't really see any problems with this proposal. Seeing as the upload_by_url right is restricted anyways to URLs that have been whitelisted I don't see issue with granting it to more individuals. If the community wants to do that via expanding autopatrolled so be it. --Majora (talk) 21:23, 11 January 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Make the "more upload options" proposal apply to all user accounts with autopatrol flag

7 days, no opposition, enough support to show that that community is fine with this. Good enough for me. I'll add this to the already open phab ticket. --Majora (talk) 02:05, 28 January 2019 (UTC)

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

Pinging everyone who responded to the original proposal: Pinging @Koavf, GreenMeansGo, Yann, Donald Trung, Fæ.

Also see phab:T214003 and User talk:Alexis Jazz#upload by url.

Due to an interpretation of words that I personally don't really see in the original proposal, only users in the autopatrolled user group are now getting the extra options. Patrollers and bots, who also have the autopatrolled flag and are thus autopatrolled users, are not getting the additional options. An admin could simply add them -all 687 of them- to the autopatrolled group, but that'll probably cause some muscle strain. Don't ask me to explain this, because I hardly understand it. But it's easier to nod and say yes in this case. - Alexis Jazz ping plz 17:12, 20 January 2019 (UTC)

Proposal: more upload options for autopatrolled things

Proposal: make the previous proposal apply to all users and all user accounts and all people and in fact all beings who have, carry, possess, own and/or are the legal guardian of a working autopatrolled flag, autopatrol bit, autopatrol user right or are autopatrolled by magical intervention. (sorry, gotta cover my bases this time..) Offer void in Nebraska outside Wikimedia Commons.

Discussion: more upload options for autopatrolled things

@Donald Trung: the autopatrolled flag was added to the patroller group, making the autopatroller group redundant for patrollers. Admins, for example, are not in the autopatrolled group either. We voted on autopatrolled users, which I take as anyone with the autopatrolled flag, but in this case was interpreted to mean the autopatrolled user group.

I told you not to ask me to explain it, I suck at this. - Alexis Jazz ping plz 18:02, 20 January 2019 (UTC)

We did and we didn't just have a RfC on this. You must separate user groups from user rights. User rights are assigned to groups and then the group is granted to individual editors. Technically any right can be assigned to any group and there are a lot of rights as can be seen in the interface for some of the global groups which can actually be manipulated by stewards instead of having to get the devs involved. There was obviously a slight confusion between the difference between groups and rights and in the last RfC the question that appeared to have been raised was to add the upload_by_url right to the autopatroller group. That is the way I read the proposal, that is the way I closed it, and that is the way the devs are implementing it. I did not read it as add upload_by_url to any and all accounts that have the autopatrol flag. Since the current implementation of the original RfC is proceeding as I originally interpreted it we would need to verify consensus to add any additional flags to any additional groups. Bureaucratic red tape, I know. But this way the devs know exactly what we are asking for when it comes to user rights. --Majora (talk) 18:19, 20 January 2019 (UTC)
And before anyone asks why I didn't ask what the "correct" interpretation of the original RfC should have been before I closed it, I did. I was told my interpretation was correct, although that might have been due to the confusion between groups and rights again. --Majora (talk) 18:48, 20 January 2019 (UTC)
Yes, I either read or assumed (doesn't matter, can't remember) you meant all users with an autopatrol flag. I was unaware you were differentiating there between users with the flag and users in the group. I thought your only question was if the proposal meant the extended uploader group would become obsolete, to that I answered "correct", unaware you meant more. - Alexis Jazz ping plz 19:55, 20 January 2019 (UTC)

Does Wikimedia Commons have the snowball clause ("COM:SNOW"?) so the developers could quickly add this to the "Patrollers" user group and "other autopatrollled users"? Or is there a minimum amount of time that this has to remain open. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:58, 21 January 2019 (UTC)

This has been opened for 24 hours on a holiday weekend in the United States where a great number of contributors live. There is absolutely no reason why this has to be done immediately. Both groups have lived without the ability to upload by URL for years and years. A few more days isn't going to hurt them. The phab ticket isn't going to go anywhere. My personal opinion is that RfCs should be open for a minimum of 7 days to give the greatest number of people the opportunity to comment. --Majora (talk) 17:16, 21 January 2019 (UTC)
And if any patroller asks about it, those who ask can be added to the autopatrolled group for a few days by any admin. - Alexis Jazz ping plz 22:09, 21 January 2019 (UTC)
@Donald Trung: Commons:Village pump/Proposals/Archive/2018/07#Speedy deletions: Selfies was closed as "done" in 6 days, by the proposer, that's the fastest one I can think of. - Alexis Jazz ping plz 22:17, 21 January 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Update padlock icons that Wikimedia Commons use to the ones that the English Wikipedia uses

CHANGES IMPLEMENTED:

- Full protection

- Semi protection

- Move protection

- Cascading protection

- Upload protection

--Majora (talk) 02:07, 30 January 2019 (UTC)

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

The pad lock icons that Wikipedia uses are actually somewhat more descriptive on the image itself of what type of protection has been put into place. Even a user that does not know the meaning behind a particular protection name, the Wikipedia padlock icon gives away somewhat of a hint. The current old style(what Wikipedia used to use), only differentiates the padlock icons of different types of protection by color. Not only is that not much descriptive, it could also be deceiving to a color blind person. The updated Wikipedia padlock design has somewhat little bit taken care of this issue as well, a majority of the low level padlocks are black in color (thus causing no issues to color blind people).Aceing Winter Snows Harsh Cold (talk) 06:45, 19 December 2018 (UTC)

It's not clear at all to me what exactly what you are proposing here. Please give links and/or examples: Which set of files should be used instead of which other set of files for which purpose? Thanks, --El Grafo (talk) 09:25, 19 December 2018 (UTC)
The English Wikipedia changed to use the icons in Category:Page Protection Padlock Redesign (2018) to denote levels of page protection. GMGtalk 11:51, 19 December 2018 (UTC)
Wikipedia:Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible.--BevinKacon (talk) 00:01, 20 December 2018 (UTC)
Thanks for the clarificatiopns, GreenMeansGo and BevinKacon. TBH, I never even noticed we had different padlock icons for different purposes cat Commons. I guess I wouldn't mind if somebody wanted to implement the new ones here. --El Grafo (talk) 09:27, 20 December 2018 (UTC)
Well we can't really implement these exact ones. We could adapt them, but using letters derived from English meanings is problematic on an multi-lingual project where many users don't even speak a language in a Latin script. GMGtalk 11:24, 20 December 2018 (UTC)
Is it possible that they would only appear if a user has set their standard language to "English"? And even though people say that Wikimedia Commons is "a multilingual project" for all intents and purposes it's still primarily an English language project, even if you change your settings to "Vietnamese" or "Chinese (Traditional - Taiwan)" you would still see "Category:" And "File:" Rather than "Thể loại:" Or "Tập tin:" As they would appear at "w:vi:Tập tin:Bao-Dai-Thong-Bao.png" but if you were to click on the blue part of "Tập tin này từ Wikimedia Commons. Trang miêu tả nó ở đấy" it will bring you to "File:" yes, you can add multilingual descriptions and things like the MediaWiki Upload Wizard are in more than one language but the de facto language of Wikimedia Commons is still in English and if these padlocks are more descriptive for us English speakers (who make up the majority of this project as all policy conversation is conducted in this language) then it would be beneficial to the largest demographic on the project, what harm would that cause? Sure, it's chauvinistic, but it's still beneficial at large. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:03, 21 December 2018 (UTC)
Well, I'm not sure it makes sense to make a change intended to increase accessibility for the visually impaired, and in doing so, make the site less accessible for anyone who doesn't speak English. Having said that, only four of them are based on letters, so it shouldn't be too difficult to find more culturally universal symbols to replace them. GMGtalk 11:32, 21 December 2018 (UTC)
I agree 100% (one-hundred percent), and those padlocks could also be used on Wikidata and other multilingual Wikimedia projects, maybe someone here reading this could create them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:02, 21 December 2018 (UTC)
We definitely need to get rid of the letter initials if these locks are used in multilingual environments. XYZtSpace (talk) 23:23, 29 December 2018 (UTC)
@Nemo bis: you mean the current ones from English Wikipedia or..? Because the current ones here are just the exact same lock with different colors. (nearly useless for the color blind I imagine..) I wouldn't call that "expressive". - Alexis Jazz ping plz 01:28, 14 January 2019 (UTC)

Update padlock discussion

Type of protection Current design Proposed design Suggested alternatives
Full protection
Fully protected
Fully protected
A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white capital letter F.
Fully protected

A symbolic representation of a double padlock, gold and silver in color with a grey shackle.  A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white 🚫 sign.

Semi protection
Silver padlock
Semi-protected
A symbolic representation of a padlock, dark grey in color with a grey shackle.
Semi-protected
 A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with an account icon in two shades and a grey shackle.
Move protection
Green padlock
Move protected
A symbolic representation of a padlock, green in color with a grey shackle. On the body is a black right arrow.
Move protected
Cascading protection
Turquoise padlock
Cascade protected
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link.
Cascade protected
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link with two links.
Cascade protected
Upload protection
Purple padlock
Upload protected
A symbolic representation of a padlock, purple in color with a grey shackle. On the body is a white up arrow above a horizontal line.
Upload protected
The following icons are not used on Commons but included in the table in case other wikis want to adopt them/harmonize padlock icons:
Template protection
Template-protected
Template-protected
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a white capital letter T.
Template-protected
 A symbolic representation of a padlock, magenta in color with a grey shackle. On the body are curly brackets. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a tilted puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece.
Creation protection
Blue padlock
Create protected
A symbolic representation of a padlock, light blue in color with a grey shackle. On the body is a white plus sign.
Create protected
Pending changes protection
White padlock
Pending changes protected
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body is a white check mark.
Pending changes protected
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body are double ticks.
Pending changes protected
Extended confirmed protection
Dark blue padlock
Extended confirmed protection
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a white capital letter E.
Extended confirmed protection
 A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a check mark. A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is an account icon.
Protection by office action
Black padlock
Protected by Office
A symbolic representation of a padlock, black in color with a grey shackle. On the body is a white circle.
Protected by Office
A symbolic representation of a padlock, black in color with a grey shackle. On the body is the WMF logo.
Protected by Office
  • I really don't know. Arrows might be confusing vis a vis the arrow on the move protection. It'd be a lot easier if we could use numbers, but we run into the same problem as letters. GMGtalk 14:05, 29 December 2018 (UTC)
  • Nice. I like any of the grey shackles puzzle pieces. I assume jigsaw puzzles are fairly cross cultural in meaning. So we really only need a clever idea for ECP. GMGtalk 15:37, 29 December 2018 (UTC)

 Question We don’t have extended-confirmed here, do we?—Odysseus1479 (talk) 01:05, 30 December 2018 (UTC)

Reckon that all of the padlocks are now made both language and script neutral, right? I don't see anything which could be seen as exclusively Anglophone in the new proposed designs. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:28, 31 December 2018 (UTC)

  • Umm...Wait. Can a local project opt out of office actions? That doesn't seem right, even if it isn't included in local policy. Office actions aren't subject to local consensus. GMGtalk 11:48, 31 December 2018 (UTC)

Full protection lock

There is obviously consensus here to update the padlocks of semi, move, cascading, and upload protection to the ones used by the English Wikipedia at this time. The only complaints that appear above are regarding the use of Latin letters. This only really affects the full protection padlock of which there is moderate consensus to implement since most people didn't really mention it either way. I'm fully prepared to implement the changes now as this has been opened long enough for everyone to have their say but I wanted to leave this here to see if any of the previous commentators have an opinion on the alternatives to the full protection lock. If no one comments the original request passes, in full, regardless. The ones used by enwiki will be put into place and that includes the full protection lock with the "F". I'll leave this open for a little bit to get some feedback before I implement the change. --Majora (talk) 05:32, 29 January 2019 (UTC)

In that case I oppose the "F" full protection lock.
  • I prefer personally but would also support if the double lock isn't going to happen.
  • For cascade protection, I prefer but will also accept if that's not going to happen.
4nn1l2 supports and , BevinKacon said "same as 4nn1l2". Davey2010 supported "the new ones" which I think includes at least . (if Davey2010 doesn't respond I'll search the page history..)
Pinging @Aceing Winter Snows Harsh Cold, Jeff G., Vulphere, Davey2010, 4nn1l2 do you have any preference/changed your mind? - Alexis Jazz ping plz 06:21, 29 January 2019 (UTC)
Pinging @B dash, Jc86035, Bluerasberry, Bidgee do you have any preference/changed your mind? - Alexis Jazz ping plz 06:21, 29 January 2019 (UTC)
@Majora and Alexis Jazz: I prefer or over the "F" full protection lock due to the latin "F". For cascade protection, I'm with Alexis, 4nn1l2, Bevin, and Davey because more clearly depicts a chain.   — Jeff G. ツ please ping or talk to me 06:53, 29 January 2019 (UTC)
@Majora and Alexis Jazz: I prefer for Full protection and agree with Jeff G. better depicts the chains, Thanks, –Davey2010Talk 10:09, 29 January 2019 (UTC)
  • Thinking about it now I suppose F only makes sense on EN because it's English, As noted below If it was German, Polish or Bulgarian Wikipedia then it would be (V)oll, (P)ełny and (п)ълен respectively.... so I support instead as not everyone here is English and would have no idea what "F" would stand for, Thanks, –Davey2010Talk 14:07, 29 January 2019 (UTC)
F stands for "Full" in English, so it is comprehensible for those with some English knowledge. According to Google Translate, German and French languages use "voll" and "pleine" for "full" respectively. I guess other languages use other words for "full" which do not necessarily start with the letter "F". I don't mention the languages which do not use the Latin script at all (including Persian, Arabic, Indic, Chinese, Japanese, Korean, etc). Is choosing a padlock with an F letter the best option in an International environment like Commons? I think we should have spread the word to other language variants of VP (such as Forum, Bistro, Café and such). 4nn1l2 (talk) 11:19, 29 January 2019 (UTC)
  • I'm with 4nn1l2. Hash mark and unstylized chains. The F lock is a non-starter, and replacing the Latin letter I presumed was mostly a settled issue. GMGtalk 11:31, 29 January 2019 (UTC)
  • Prefer . The two lock design looks too different. Blue Rasberry (talk) 12:23, 29 January 2019 (UTC)
  • Prefer as well. The double lock sign seems confusing that it can be full protection or semi-protection. --B dash (talk) 13:28, 29 January 2019 (UTC)
  • Thanks for pinging me.  :) I prefer the double lock icon for full protection. The reason for this is that full protection can be considered somewhat unique to the other forms of more used protections. In full protection only admins can edit pages where as in other forms of confirmed protection there are a much larger set of users that can edit the page. For confirmed protection, the image depicted inside the padlock gives clues to who is allowed to edit that page. There is a issue with full protection with this. The letter "F" really would only symbolise the name of the protection that is being used, and not much info about the users that are allowed to edit that specific page. This would pose a slight problem to users that are new to Wikicommons/Wikimedia who probably would not know the meaning behind full protection. The double padlock icon for full protection would be a lot more descriptive in showing that very high leveled users are only allowed to edit that specific page.
A better solution to a full protection pad lock would be a image similar to that user and key logo that Windows 98 era of Windows used to use for the admin account logo. However we would have to make a free equivalent variant of that, plus make the image small enough to fit inside the padlock icon. That would be to much to do and would be very difficult, thus forget about that and I suggest as above that the double padlock logo should be used for the full protection padlock logo.
I would also like to say on a side note, there are issues where creation protection can be used. Example of these can be rouge unessasary spam non-upload pages. Realistically speaking, this page was created obviously in a similar manner of how, Wikipedia pages in the Wikipedia domain were created on Wikipedia. Thus, repeat offenders who repeatedly create a spam page can be stopped by creation protection. I could be wrong and might be mixing up salted red-link pages with creation protection. Aceing Winter Snows Harsh Cold (talk) 21:07, 29 January 2019 (UTC)
Well that garnered responses much more quickly than I thought it would. Ok. File:Full-protection-shackle-block.svg it is. As well as the alternative cascading option. I'll go ahead and make the changes. --Majora (talk) 02:01, 30 January 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Drop security support for IE6 and IE7

Also see phab:T27707 and Commons:Village pump/Technical#How to propose a change to the MediaWiki software?.

It appears that all we can do is vote to hopefully get a local exception. I will also create this proposal on some other wikis.

When a photo has HTML code in the EXIF metadata like "<a href=example.com>Photo by me</a>", it can't be uploaded to Commons. For example, https://www.flickr.com/photos/tinto/30943950124/. The reason for that is because Internet Explorer 6 and 7 (Microsoft dropped support for IE7 entirely in April 2016) don't understand they should render such files as images. The image file is perfectly valid and all, no harm, but IE6 and IE7 are not very smart.

As long as these are listed on mw:Compatibility#Browser support matrix, which will be forever because no procedure exists to propose a change to that list, we will continue to suffer from the flaws of these Microsoft products. While MediaWiki as a software product may continue to support a dead browser, we could end that support locally. - Alexis Jazz ping plz 16:55, 25 January 2019 (UTC)

Proposal: Create a local exception for Commons to skip useless security checks for IE6 and IE7 exploits that hamper uploads.

  • Let’s not mix matters up. Not upgrading from Windows XP to a newer version can be due to low-end or aging machine and using it with Windows XP instead of installing a Linux flavor can be made necessary by existing workflow needs (that was my own personal story until very recently) — but none of that excuses or explains the use of IE6 or IE7. Anyone who’s still using Windows XP today must be resourceful enough to have changed to another browser long ago (my last continued use of MSIE was in 2003 and even that only due to corporate imposition). As for upgrading from desktop to mobile, well, that’s really like going from this to this and call it an improvement. -- Tuválkin ✉ ✇ 22:46, 25 January 2019 (UTC)
  •  Support Legitimate uploads under a free licence useful for educational purpose should not be blocked due to anything other than extrordinary reason. If somebody were to write a clone of Firefox 1.0 which refuses to open images that start with a vowel, we would not block those (I hope). ℺ Gone Postal (〠 ✉ • ✍ ⏿) 19:55, 25 January 2019 (UTC)
  •  Support Abzeronow (talk) 20:51, 25 January 2019 (UTC)
  •  Support - I agree we shouldn't stop people uploading just because of their browser, For instance prior to laptops I was using a Playstation PSP and the internet broswer (Opera Mini I believe) was shite but there was nothing I could do about it - Not all devices allow browser changes so as I said people shouldn't be turned away all because their device isn't top of the range brand spanking new etc etc. –Davey2010Talk 21:53, 25 January 2019 (UTC)
  • I'm sure WMF will reject this. Don't waste your time. Bye. (I won't respond to remarks here. Also, NOTE: This comment is made 100% on a personal capacity.) — regards, Revi 21:56, 25 January 2019 (UTC)
  •  Support -- Tuválkin ✉ ✇ 22:46, 25 January 2019 (UTC)
  •  Support - too old browser. Rudolphous (talk) 05:13, 26 January 2019 (UTC)
  •  Support It is worrying that the official line from the WMF is "go away, we are not touching this", when it is entirely fixable. Trapping and blanking blacklisted EXIF elements is easy to specify and should be relatively trivial to roll out. Even if this were not implemented to action at upload time, an API error trap could flag the issue and tools could separately do the stripping. --Fæ (talk) 09:30, 26 January 2019 (UTC)
  •  Support Please let files be uploaded to Commons easily. Look at Commons:FAQ#What does the upload error This file contains HTML or script code that may be erroneously interpreted by a web browser. mean? This is a common issue which continues to frustrate uploaders (i.e. potential content creators). I have one serious question: Why does Flickr, a professional website about images which WMF seeks advice from its designers, allow uploading files with HTML on their metadata, but Wikimedia Commons does not? 4nn1l2 (talk) 23:42, 26 January 2019 (UTC)
  • Comment: why should Commons support a full Frankenstein production line of EXIF markup? I mean, the mission of Commons is to host images and the text needed to explain and attribute them. It seems like there are a huge number of ways to have programs secretly store records of who did what with the camera and the image editor and so on when, all done sort of on the downlow, supposedly to track down child porn makers and more realistically people who record police shootings. (Bad things happen to them, always) But for our purposes, we don't need anything hidden in the image file per se; we can just have a text markup everyone can read, and a flat image in a verified EXIF-free format, and if someone really *wants* the EXIF then it could always be added to the file on the fly at the moment it is downloaded. So I don't see a need to have the metadata in the image at all, and certainly not a need for HTML that would appear to guide that metadata out of the realm of mere "information" and into the realm of "links", which is to say, I would suspect it might be subject to all kinds of extra threats and punishments for "taking a person to a site" rather than just "saying where it is", as if there were a difference. On the other hand ... is WMF afraid that damaging these magic links by turning them into mere text without the holy markup might expose them to lawsuits that they "damaged attribution"??? If I had a magic wand that could turn all the believers of censorship and copyright into chocolate ice cream I would eat real well tonight. Wnt (talk) 03:09, 27 January 2019 (UTC)
    • EXIF data is important for a large variety of reasons, it could indicate the device type or location and it can be used to better use a file due to the various factors that play in how the photograph was taken. Even if one would ignore the numerous ways that such metadata is vital for many parties, EXIF data can also be telling of authorship and the deletion requests where I've seen users point out faulty or inconsistent EXIF data exposing it as a copyright violation are numerous, EXIF data and other forms of metadata aren't trivial, they're vital. We need more data, not less. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:47, 27 January 2019 (UTC)
  • oppose As a point of principle we should be supporting the widest browser set possible. In this case I'm not sure the feature we would be adding support for is particularly desirable.Geni (talk) 19:39, 27 January 2019 (UTC)
  • IE6 is already unsupported by MediaWiki: it's in the lowest grade of support. While I agree that no efforts or resources of our copyleft projects should be spent supporting such proprietary relics, I'm not sure this specific trade-off in favour of IE6/IE7 users is a significant cost we should seek to remove. Can we solve the problem in an easier way, e.g. by making flickr2commons and friends "sanitise" such EXIF? Nemo 21:15, 27 January 2019 (UTC)
  • Weird I cannot speak to the technical costs, but it seems that the WMF position is that executing this would take one or more staff people a lot of work ("it'd probably take a few months to do"), which seems like this is a US$50,000 problem. The counterarguement from the community perspective is that we are creating a barrier for many contributors to engage in Wikimedia editing for the benefit of the minority of users who have not updated their browser since 2016, with there being a claim that some non-Microsoft browsers since 2003 are new enough. There is the claim that our traffic reports show no traffic from these non-compatible browsers. Obviously no one wants to break the wiki, and wiki discussion is not necessarily a way to arrive at security truth, but it seems like we have a case where there is a community problem with a seemingly easy technical solution which might be a major security risk. Someone should publicly articulate that security risk, right? Blue Rasberry (talk) 12:34, 29 January 2019 (UTC)
Phab:T27707 is an articulation of the security risk, and everything written there is CC-BY-SA, so can be copied and reused. --Fæ (talk) 13:07, 29 January 2019 (UTC)
  •  Support Looks sensible to me. Yann (talk) 13:37, 29 January 2019 (UTC)
  •  Oppose The proposal makes no sense. Commons supplies images to other Wikimedia projects, so how would Commons having an opt-out, but other projects not, work? I have not seen anyone quote browser usage stats that actually apply to Wikipedia page views, vs views of some tech website. The proposal (and discussion on the other forum) are loaded with inflammatory language, and reflect a First-World tech-user viewpoint. Do we have any stats on how common it is for a JPG to have HTML embedded in the EXIF? I suspect we have all wasted more of our short lives on this mess than it deserves. By all means ask the developers for a fix/work-around, but the proposal here is pure political games IMO. -- Colin (talk) 14:42, 29 January 2019 (UTC)
Your reasoning makes no sense. Replied in the discussion section. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
  •  Support This seems like a bug in the browser. We shouldn't ban uploads to work around bugs in minor browsers. That said, though, if this proposal doesn't pass and you want to upload a specific image, surely you can edit the EXIF? Here is a site that does it online: https://www.thexifer.net/ --GRuban (talk) 15:41, 29 January 2019 (UTC)
GRuban, yes, but that's a massive undertaking for thousands of images and causes FlickreviewR to fail, forcing human license reviewers to spend time on them. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)

Discussion: Drop security support for IE6 and IE7

{{atop|status=Proposal passes|result=Closed by Jdforrester (WMF) because such exemptions may not be voted on by contributors. See this edit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:37, 25 January 2019 (UTC))

@Donald Trung: Thanks for undeleting. I'm actually reopening this. Jdforrester (WMF) may be a Lead Product Manager, but on Commons, he's ultimately nothing but an autoconfirmed mortal. @Jdforrester (WMF): you can't delete proposals you don't like. You can apply for the mop, but as it stands, you don't have a mop. So you can't mop up threads you don't like.
We can vote on this. If this proposals passes and WMF decides to ignore us, that'll be different matter. You shouldn't silence us at this stage. @Gone Postal: you wanted to comment I think? - Alexis Jazz ping plz 19:49, 25 January 2019 (UTC)
@Alexis Jazz: Please read m:Limits to configuration changes. This farce of a proposal is a massively disrespectful waste of fellow volunteers' time. Please, withdraw it. Jdforrester (WMF) (talk) 19:52, 25 January 2019 (UTC)
@Jdforrester (WMF): I see a farce alright. Developers who are hell-bent on supporting dead browsers without any way to propose a change to that policy. That's a farce alright! We can vote on this, even if you'll ignore us. We should work together, but your stance makes that impossible. - Alexis Jazz ping plz 20:04, 25 January 2019 (UTC)
@Alexis Jazz: Also, in a personal capacity, I very much do have the mop, as you put it. Obviously as I'm professionally engaged here I'm not going to involve myself personally, but please be more aware when you dismiss others' points of view. James F. (talk) 19:57, 25 January 2019 (UTC)
So you should have used your administrator account. You can't expect me to search for alternative accounts. But this only makes it worse. - Alexis Jazz ping plz 20:04, 25 January 2019 (UTC)
Let's not place admins on a pedestal, or are you referencing that only admins can close discussions here? His actions were done as a Wikimedia developer 👩‍💻, an actual admin who administrates the software we use. But now that we're on this discussion anyhow, @Jdforrester: would there be a way that those files could be imported without breaking browser support? Maybe by letting people who use those browsers not be able to view those files if that is technically possible. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:38, 25 January 2019 (UTC)
@Donald Trung: "or are you referencing that only admins can close discussions here?" indeed, I don't see any scenario in which a valid proposal (which means: something that can be voted on, not vandalism or a question that may be moved to the help desk) would be closed by a non-admin. Let alone deleted. That would be reserved for vandalism. Jdforrester actually turning out to be an admin only makes his action worse. - Alexis Jazz ping plz 20:59, 25 January 2019 (UTC)
@Alexis Jazz: I've already told you that the discussion was not deleted, please stop using that term. Nick (talk) 21:03, 25 January 2019 (UTC)
Technically speaking nothing is actually ever "deleted" on Wikimedia websites, just hidden from general view, you ("User:Nick") could view "deleted" files, but this is just a comment on semantics so everyone could ignore this comment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:12, 25 January 2019 (UTC)
@Nick: if I removed your comment from this thread, you'd say I deleted it. - Alexis Jazz ping plz 21:46, 25 January 2019 (UTC)
@Alexis Jazz: No, I wouldn't. That's mainly because I know the difference between blanking and deletion of content. Nick (talk) 21:51, 25 January 2019 (UTC)
This is a serious breach of trust, being an act of apparent censorship, and is sufficient for a desysop request. Jdforrester is misusing their sysop privilages, and taking actions as a WMF employee that they should be held to account for under their ordinary sysop account. This means they no longer care to use their ordinary account and clearly do not need those privilages. A desysop vote would give plenty of space for Jdforrester to account for this action and how they believe it follows the Administrators policy.
I am away from my normal desktop, could someone please raise this on AN for pre-desysop discussion? Thanks --Fæ (talk) 20:19, 25 January 2019 (UTC)
Please let's assume some good faith here, imagine if making such major changes to the MediaWiki software 👩‍💻 by exempting a single Wikimedia Wiki would force the developers to place it on a different development cycle or could potentially break compatibility or something. All I see is an expert bloke who develops the software we use as his job giving his expert insight into the matter and closed a thread in a rather unorthodox way. There is no need to attack either Jdforrester (WMF) the Wikimedia employee or Jdforrester the human being, let's discuss this all as adults, I'm sure that Jdforrester had good intentions with his edit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:32, 25 January 2019 (UTC)
There was no administrator tool use involved, so there's nothing to request a de-sysop over, so no, no AN pre-desysop discussion I'm afraid. James removed a section, Donald Trung restored it. Bold, Revert, Discuss in action. Nick (talk) 20:34, 25 January 2019 (UTC)
@Donald Trung: realistically, to do this the useless security check would be made optional in the software so it could be disabled locally on any wiki. Which will actually be a great feature for MediaWiki, and Jdforrester should be thankful the community brings up these issues. - Alexis Jazz ping plz 21:10, 25 January 2019 (UTC)
I don't understand why it's apparently so important to the MediaWiki devs to keep supporting such outdated browsers and insecure. Google, for instance, stopped supporting IE6 in 2010 and IE7 in 2011 for its web apps. Surely it would be better to tell users still using those browsers to suck it up and upgrade instead of presenting them with a degraded experience and hamstringing the rest of us. clpo13(talk) 20:36, 25 January 2019 (UTC)
I suspect it's because Wikimedia Foundation wants to keep projects accessible to users with donated second hand IT equipment, as can be the case in developing countries. Nick (talk) 20:44, 25 January 2019 (UTC)
That's a fair point, which I hadn't considered. Still, even Windows XP can use IE8. clpo13(talk) 20:46, 25 January 2019 (UTC)
@Clpo13: Not to mention you'll be better off using Firefox. And if at all possible, install something like Ubuntu. IE8 support ended in January 2016. Actually April 2014 for IE8 on Windows XP. Firefox support on Windows XP ended in June 2018. Google Chrome support for Windows XP lasted until April 2016. The last Opera version appears to be from August 2016. Searching for what browsers might actually still be supported on Windows XP, I found https://www.makeuseof.com/tag/browser-secure-old-windows-xp-system/. Which linked an article with a title that's just brilliant: If You’re Still Using IE6 You Are A Problem. But really: if we disable this useless security check, is that going to cause people who still use IE6 or IE7 from collecting as much malware as will fit in their memory? I don't think so. They are vulnerable to everything and their mother, and files that get uploaded here are still scanned by a virus scanner, policed by the community and processed by the thumbnailer before being served on most pages. - Alexis Jazz ping plz 21:38, 25 January 2019 (UTC)
This is a rather extreme measure taken against Jdforrester (WMF) who was acting in good faith, could we please try to discuss this topics without resorting to emotion now?

As Jdforrester (WMF) is blocked now, could we address the technical issues why this thread was removed now? But as Jdforrester can still edit with his “personal account” I still want to ask him the technical motivations as to why a local exemption to this cannot be discussed. Supporting internet browsers is important and in order to let as many people as possible access the free knowledge we create here. But as Alexis Jazz stated on Phabricator ”According to @matmarex this is an issue in IE5-7. MS dropped support for IE7 entirely in April 2016. IE8 was released in 2009. According to https://en.wikipedia.org/wiki/Internet_Explorer_7, as of May 2012, estimates of IE7's global market share were 1.5-5%. According to netmarketshare.com the market share is now 0.16%.” which means that the MediaWiki software is supporting an unpopular unsupported internet browser, of course as was stated above donated second-hand equipment to developing countries would run these, but even on Windows XP Microsoft Internet Explorer 7 isn't the latest version of the Internet Explorer series of web browsers. Can browser support for these browsers not simply be tweaked to ignore these exceptions? From what I can tell these images cannot be uploaded because a line of code in their EXIF data tricks IE6 and IE7 into believing it is a security concern.

Another question, imagine even if the Wikimedia Commons community would vote to (locally) drop support for these ancient browsers, would the Wikimedia developers actually be forced into making this exception? Or is this closer to a non-binding (advisory) referendum? It could just show the developers that some of their choices are hurting content creators, but could they actually implement these changes without also hurting the (very, very few) people who use Microsoft's Internet Explorer 6 and Internet Explorer 7 web browsers? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:48, 25 January 2019 (UTC)

"imagine even if the Wikimedia Commons community would vote to (locally) drop support for these ancient browsers, would the Wikimedia developers actually be forced into making this exception?" No. The developers, the wmf and the security team control the software, as you control images (commons) and articles (wikipedia). The communities provide input, no more. If you want to force something, you should become part of one of those three groups and convince the rest of the group. —TheDJ (talk • contribs) 23:28, 25 January 2019 (UTC)

 Comment, as I just saw -revi's comment "I'm sure WMF will reject this. Don't waste your time. Bye. (I won't respond to remarks here. Also, NOTE: This comment is made 100% on a personal capacity.)" where the suggestion is made that the Wikimedia Foundation will reject this, wouldn't it be better if this discussion be closed? I deliberately closed this proposal after restoring it because having a proposal that goes nowhere (with good intentions) could only add bitterness. Although if a WMF developer could respond to this proposal it would be most welcome, as it would showcase that the community isn't actively being ignored. --Donald Trung 『徵國單』 (No Fake News 💬) ([[Commons:WikiProject Numismatics|WikiProject Numismatics]] 💴) (Articles 📚) 22:54, 25 January 2019 (UTC)

  • Establishing a consensus here is fine. It helps other groups focus on the issue, and consider alternative solutions, such as allowing upload to the WMF server, but filtering blacklisted elements from the EXIF before publishing to live. --Fæ (talk) 23:49, 25 January 2019 (UTC)
  • I think it's good to have this proposal open. If the Commons community were to reject it, it would show the WMF and WMF developers that they are doing the right thing. If we accept it, they should start scratching their heads.
    On a technical note: The thumbnailer already strips nearly all text from the metadata, only the "copyright" field is retained. Technically, MediaWiki could generate a thumbnail and check the first kilobyte of the thumbnail instead of the first kilobyte of the uploaded file. If the WMF is truly concerned with supporting dead browsers, they could disable downloading of original files (as opposed to thumbnails) for IE6 and IE7 users. Note that anything that isn't the original file is a thumbnail in this context, this 1500 × 2359 image is a "thumbnail". This may all sound very convoluted, and it isn't the easiest of solutions (the easiest solution is the one proposed!), but it's infinitely less convoluted than anything Jdforrester suggested. - Alexis Jazz ping plz 00:11, 26 January 2019 (UTC)
  • Question: What security checks do modern browsers do to ensure that the EXIF cannot execute malicious code? How confident are we that these checks are universal across all browsers with significant current usage? -- King of ♥ ♦ ♣ ♠ 03:43, 30 January 2019 (UTC)
@King of Hearts: browsers use the MIME type. For files on your computer, the magic number and/or file extension could be used. Wikimedia takes care of using the right MIME type, files with a bad magic number of file extension are not allowed to be uploaded. IE6 and IE7 are essentially dumb in that they scan the first 255 bytes of any file for occurences of HTML tags and when found treat the file like HTML, including javascript. Presumably this was done as a workaround for webservers that were misconfigured. A workaround that really never should have existed in the first place. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
  • Colin above:

The proposal makes no sense. Commons supplies images to other Wikimedia projects, so how would Commons having an opt-out, but other projects not, work? I have not seen anyone quote browser usage stats that actually apply to Wikipedia page views, vs views of some tech website. The proposal (and discussion on the other forum) are loaded with inflammatory language, and reflect a First-World tech-user viewpoint. Do we have any stats on how common it is for a JPG to have HTML embedded in the EXIF? I suspect we have all wasted more of our short lives on this mess than it deserves. By all means ask the developers for a fix/work-around, but the proposal here is pure political games IMO.

— Colin in his vote
Because you're the expert when it comes to proposals. Still harboring a grudge over the GFDL thing? Which also only applies to Commons. Netmarketshare is not "some tech website". Later I also found the version-specific information on https://analytics.wikimedia.org/dashboards/browsers/#desktop-site-by-browser. According to that, 0.8% uses IE6 and 0.2% uses IE7. But this proposal doesn't even ban those browsers (which their users could upgrade, less outdated browsers like Firefox, Chrome and IE8 are available for Windows XP) from Wikimedia projects. It merely skips a redundant check as the files are still scanned by a virus scanner and policed by the community and possibly bots. You ask for stats on "how common it is for a JPG to have HTML embedded in the EXIF". The question should be where the stats are on how common it is for a JPG to have malicious code embedded that is triggered by this behaviour in IE6 and IE7. Except even the answer to that question is largely irrelevant, because any security measure that is aimed exclusively at IE6 and IE7 is a huge joke. It's like installing smoke detectors in a house that's already on fire. If this check didn't exist and we were to propose implementing it today for some dead browsers, breaking uploads in the process, nobody in their right mind would support that. The proposer for such a thing may even have his mental sanity being questioned, and rightfully so. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
According to Brion on phab:T27707#4915179, IE6-8 on Windows XP fail to work anyway due to lack of SNI. So there goes any "but what about the third world" argument. Only IE7 on Vista is affected. Who the hell still runs Vista? No no no no correction: who the hell runs Vista, period? The answer is absolutely nobody, because after may 2018 it's market use on Wikimedia dropped below 0.1% and can't even be accurately measured anymore. And from that <0.1%, only the fraction that actually also uses IE7 counts. 0.00041789% of users in December 2018. Vista users can install IE8 or IE9. - Alexis Jazz ping plz 07:09, 30 January 2019 (UTC)
Do you think it is possible for you to communicate without making personal attacks and insults? The analytics show IE6 usage is 1.2% on 2018-09-30. That is a heck of a lot of people, if the stats are to be believed. Also, see Usage share of web browsers for why user-agent detection is not particularly reliable. But fundamentally, the proposal I opposed was "Create a local exception for Commons..." which makes no sense, as I said. Wrt how often JPGs have HTML EXIF, you have't answered the question. So basically, you are wasting everyone's time on a "problem" you haven't even quantified. The number of people/images with HTML EXIF represents people/images that can't be uploaded at present -- how many are we talking about. You say we should instead be worried about how common malicious code is? This represents a misunderstanding of security. On Monday there may be nobody using a given exploit, say. On Tuesday, your local NHS hospital computers are infected with ransomware. All it takes is one malicious file. Anyway, I'm unwatching this as life is too short for such nonsense. -- Colin (talk) 11:34, 30 January 2019 (UTC)
Colin, "it is possible for you to communicate without making personal attacks and insults?" You are the expert here... Alexis' analysis above and below is quite useful, so if you don't have anything useful, you better shut up. Regards, Yann (talk) 12:07, 30 January 2019 (UTC)
Yann, since you pinged me, where is your useful contribution to this discussion? Why do you even ask "if you don't have anything useful" when my post supplies information and asks perfectly valid questions? Why are we proposing this when we don't even know how much it bothers anyone? How would a Commons exemption work? The stats should be taken with a pinch of salt. However, the charts on that website seem broken since May last year for Windows versions. There is a tablular form which shows Vista at between 0.2% and 0.3% in the last few months. This page estimates 30 million unique devices accessed just en/de/fr Wikipedias each day. 0.3% of that is 90,000 Vista users every day. And 1.2% of that is 360,000 IE6 users every day.These are not small numbers. Unlike the number of JPGs this proposal is aimed at, which appears to be an imaginary number. I don't know if we can trust those user-agent numbers or any other numbers proposed here. Now, please don't ping me about this silly proposal again. -- Colin (talk) 13:01, 30 January 2019 (UTC)
30 million? Actually 23.3 million on avarage, but who's counting. 0.0004% Vista users with IE7 makes.. 93 users who actually aren't affected because Wikimedia serves files with the correct MIME type, file signature and extension. Oh, and their house is on fire. There's that. You know damn well there are no statistics for what you're asking, because how would one even collect those? We know the phabricator ticket was opened in 2010, so this already caused problems back then. We can search the exact error message, which will not show every instance of a user running into this, giving us 39 results. Most users probably won't even bother reporting it and just turn away and any reports that do not mention the exact error message in English are not found this way. - Alexis Jazz ping plz 13:28, 30 January 2019 (UTC)
I agree with Yann here. As for the reported IE6 usage, I can think of two explanations. One, it's falsified by some users for shits 'n giggles. Two, they are actual IE6 users who use a proxy that strips the S from https. What they do is not supported and their security is out of the window for too many reasons to explain. The 4 per million users, actually less when you subtract those who are not logged in, using IE7 on Windows Vista are also screwed, but not by this exploit, at least not on Wikimedia as it wouldn't be exploitable here anyway, with or without the security check we are discussing. - Alexis Jazz ping plz 12:43, 30 January 2019 (UTC)
  • Ghouston said:

It's a bit hard to find information about this problem online, since it affects browsers that became obsolete in 2009 when a newer version of IE was released. Perhaps Microsoft even patched the bug in the old versions, if they supported them for several years afterwards?

I found an article http://www.h-online.com/security/features/Risky-MIME-sniffing-in-Internet-Explorer-746229.html which describes the problem and gives some interesting information. It only affects the browser when the user goes directly to the file, as in downloading, like https://upload.wikimedia.org/wikipedia/commons/e/e9/Dehallen.jpg. It doesn't affect images when embedded in HTML pages.

Also, if the file extension, MIME type, and file signature (the first few byes of the file) are all in agreement, the browser won't do it's crazy scanning thing. I don't know what file extensions it accepts. It may be possible to disable the check for the problem is the file extension is good.

This is surely a bug that nobody would bother actually trying to exploit. Why go to the effort, when the chance that one of the users of these old browsers will actually visit the direct link of your file is practically zero? And all you can do is Wiki actions, which are reversible anyway.

— Ghouston on Phabricator ticket T27707
As Wikimedia serves the correct MIME type anyway, file extensions are restricted to a whitelist and invalid file signatures are also rejected, this exploit is basically not exploitable. Even if you were crazy and wanted to take advantage of basically nothing with this exploit, you couldn't. - Alexis Jazz ping plz 07:09, 30 January 2019 (UTC)

Discussion: Implementing changes without dropping support?

@Fæ: , I saw that you proposed implementing a change that would not necessarily have to force us to end supporting these ancient browsers left by a civilisation long passed, could someone from the Wikimedia Foundation confirm that this work around is possible? And could community members implement these without the help of the Wikimedia Foundation? That way everyone could leave this discussion pleased. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:47, 26 January 2019 (UTC)

You don't need someone from WMF to tell what's possible; WMF writes only a minuscule minority of our code. The EXIF could be sanitised when it's uploaded, sure, but if we did so in MediaWiki core we would be spending more resources on Internet Exploder rather than less. The easy way out it to implement a workaround in some upload methods, whichever are most likely to need it (if we find them; see above). Nemo 21:23, 27 January 2019 (UTC)
Yes, of course it's possible. It's not even technically a hard thing to write a Use Case for, which could then pin down how much programming and test time it would take to implement. Subscribe to Phab:T27707#4915036 if you want to track this happening off-wiki, though I recommend you do not write anything on that task, as the CoC could get you permanently banned from all projects if you appear "non positive" in any undefined subjective way as judged by a body that acts behind closed doors.
As for not needing the WMF to tell us what is possible, the "official" strategy here was to shut up the community, as, I guess, us volunteers have such massive egos that some of us believe we should have a voice and be able to reach a consensus for what improvements and changes should happen on our the WMF's project. --Fæ (talk) 12:41, 29 January 2019 (UTC)

Fix SVG upload to remove bad SVG previews and to integrate SVG Checker into the workflow

The Problem: The standard workflow creates false previews of SVG files that aren't validated, resulting in buggy SVG uploads and user frustration. Workflow:

  1. Choose to upload an SVG file for use on wikipedia.
  2. When you've chosen a "Source filename" it shows a graphic preview of the file that you wish to upload. This preview is not accurate- it is using the browser to render the SVG file, which is not how Wikimedia renders SVG files into PNGs for use on wikipedia. The file is also not validated by wikimedia at this point.
  3. Your only option is then to execute the upload, which puts the file in the wikimedia server and initiates wikimedia PNG conversions that wikipedia uses for the Web site.
  4. Some minutes or hours later, your SVG has been converted to PNG files that are live on wikipedia and maybe full of rednering bugs.

The Solution: The workaround is to verify your file first using c:Commons:Commons SVG Checker. That tool shouldn't be a secret people need to find- it should be integrated into the workflow.

I think the best fix is to replace the file preview that appears after "Choose File" with a "Validate and Preview SVG" button instead, then have that button open the SVG checker on a new browser tab for the chosen file. This way wikipedia won't be showing false previews, the very useful svg checker functionality will be integrated into the workflow so people can find it, and people can still work as they do now without using the SVG Checker if they don't need it (e.g. for a typo fix).

Thoughts?--Efbrazil (talk) 23:22, 30 January 2019 (UTC)

One consideration is file size. In order to carry out validation, an actual upload must take place; and for some files this can introduce a very significant delay into the procedure. For instance, File:Turgot map of Paris - Norman B. Leventhal Map Center.jpg is 35,690 × 28,030 pixels for an actual file size of 853.45 MB, which at 8 Mbit/second would take around a quarter of an hour to upload. True, this is a JPEG and not a SVG - but SVGs can be large too, such as maps where the textual content (place name labels, etc.) has been done in the form of a path element. The uploader may not understand why, having selected the file for upload, they are then unable to fill in the rest of the form for some minutes. --Redrose64 (talk; at English Wikipedia) 10:36, 5 February 2019 (UTC)
Yep, that's why the upload for the SVG Checker is optional in the proposal. The keys are not showing the bad preview, and exposing svg checker as an option.--Efbrazil (talk) 18:19, 7 February 2019 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2019/01&oldid=342176216"