Help

Commons:Administrators' noticeboard: Difference between revisions

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

← Older edit Newer edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 23:50, 6 January 2017

Shortcut: COM:AN

Community portal
- introduction

Help desk

Village pump

Administrators' noticeboard

This is a place where users can communicate with administrators, or administrators with one another. You can report vandalism, problematic users, or anything else that needs an administrator's intervention. Do not report child pornography or other potentially illegal content here; e-mail legal-reportswikimedia.org instead. If reporting threatened harm to self or others also email emergencywikimedia.org.
Vandalism ^{[new section]}	User problems ^{[new section]}	Blocks and protections ^{[new section]}	Other ^{[new section]}
Report users for clear cases of vandalism. Block requests for any other reason should be reported to the blocks and protections noticeboard.	Report disputes with users that require administrator assistance. Further steps are listed at resolve disputes.	Reports that do not suit the vandalism noticeboard may be reported here. Requests for page protection/unprotection could also be requested here.	Other reports that require administrator assistance which do not fit in any of the previous three noticeboards may be reported here. Requests for history merging or splitting should be filed at COM:HMS.
Archives
22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1	114, 113, 112, 111, 110, 109, 108, 107, 106, 105, 104, 103, 102, 101, 100, 99, 98, 97, 96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1	39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1	96, 95, 94, 93, 92, 91, 90, 89, 88, 87, 86, 85, 84, 83, 82, 81, 80, 79, 78, 77, 76, 75, 74, 73, 72, 71, 70, 69, 68, 67, 66, 65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1

^{Translate this page}

Unfree Flickr files: ~0

Recent unfree Flickr images: ~4

Media uploaded without a license as of 2024-07: ~226

Other:

Duplicates: ~2
Advertisements/spam: ~7
Personal photos/selfies: ~9
Other speedy deletions: ~59
Categories for discussion: 84 months
Media requiring a split up: ~2
Requests for unblock: ~2
Undeletion requests: ~12

Protected edit requests:

Full protection: ~6
Interface admin: ~15
Technical: ~0
Template protection: ~1
Protection level: ~0

See also: DR, HMS, …

Influx of files with embedded data (CSD#F9) – continuation

Previous discussion; Abuse filters: JPEG, PNG, GIF and large newbie uploads; Reports: Absurd overhead, Wrong Extension (zero pixel check)

Info I am writing to let you know that pirates have switched from JPEGs and PNGs to GIFs: Special:DeletedContributions/Windowuploaderminmya1996. --jdx ^Re: 10:30, 15 December 2016 (UTC)[reply]

Well, the GIFs are multi-frame usually, and the old algorithm may no longer work. :( --Zhuyifei1999 (talk) 11:11, 15 December 2016 (UTC)[reply]

That's why I have created Special:AbuseFilter/165 for GIFs with coefficients chosen according to the "rule of thumb". BTW. Due to wide flux of fake PNGs, two days ago I turned on "disallow" action for rule #162. It seems that a valid PNG has not been rejected yet. --jdx ^Re: 11:38, 15 December 2016 (UTC)[reply]

May I ask what is the story behind this? MechQuester (talk) 15:14, 15 December 2016 (UTC)[reply]

@MechQuester: some pirates discovered that we are a fast, free and anonymous file host if they just append their archives to JPEGs, PNGs or GIFs. See the archived thread and phab:T48921. Storkk (talk) 15:25, 15 December 2016 (UTC)[reply]

Not regular pirates, but Zero pirates. See phab:T129845 for more history --Zhuyifei1999 (talk) 17:09, 15 December 2016 (UTC)[reply]

BTW. I've just noticed that Abuse Filter has a (new?) variable called user_wpzero. It is not mentioned on mw:Extension:AbuseFilter/Rules format. --jdx ^Re: 10:33, 16 December 2016 (UTC)[reply]

@Jdx: That's gerrit:280468 (phab:T131211), implemented within mw:Extension:WikimediaEvents so not part of the standard AbuseFilter installation, and therefore not so good to add to mw:Extension:AbuseFilter/Rules format that documents a standard AbuseFilter installation.

Regarding the use of that variable, many of the Zero pirates do not use Zero themselves; one reason may be that being tagged by Special:AbuseFilter/149 may have their uploads deleted sooner. Eg. Special:AbuseFilter/149 did not catch Windowuploaderminmya1996. --Zhuyifei1999 (talk) 13:00, 16 December 2016 (UTC)[reply]

I did work years ago in User:Dispenser/GIF check to check the compression ratio and found a GIF with PHP exploit code. Dispenser (talk) 15:48, 15 December 2016 (UTC)[reply]

Question Could a video guru look at File:Arottegoesercom.webm, especially "Transcode status" section? I've tried to reset transcode status three times, but without success. Also, isn't the size somewhat too big for a 17 seconds video? Of course the file has been uploaded by one of these guys who try to upload fake images. --jdx ^Re: 20:19, 16 December 2016 (UTC)[reply]

phab:T153488. I'll look into that file size shortly --Zhuyifei1999 (talk) 05:47, 17 December 2016 (UTC)[reply]

Video remuxed. I honestly don't see how AF is gonna work here. The bitrate of videos are very arbitrary depending on the quality. --Zhuyifei1999 (talk) 06:23, 17 December 2016 (UTC)[reply]

I can't see it either. It seems that a full blown validator is needed for validating files during upload. :-/ --jdx ^Re: 08:39, 17 December 2016 (UTC)[reply]

IMO, uploads of accounts uploading fake images/videos should be deleted straight away and the accounts blocked indefinitely. The accounts are not here to provide useful multimedia documents. Investigating each of their uploads is a waste of time and energy. Regards, Yann (talk) 10:36, 17 December 2016 (UTC)[reply]

I looked into possible recognition of such videos. I was unable to find a way to detect (and truncate) the file ending precisely similar to the old PIL method. But I see one method might be use ffmpeg to remux the file, and use strace to find where ffmpeg starts to read the input file but produce no output at all. This should be able to detect such a file. However, junks smaller than 32768 bytes may be difficult to detect with this method. I'll try to get a proof of concept working soon.

I tend to AGF towards these uploaders if it weren't for Zero abuse. Files can be tagged with "no permission" safely after truncation/remuxing for uploaders to prove their innocence. --Zhuyifei1999 (talk) 11:21, 17 December 2016 (UTC)[reply]

I would AGF only if the account has an history of uploading useful stuff. Regards, Yann (talk) 12:34, 17 December 2016 (UTC)[reply]

It was a six year old youtube video - deleted on copyright violation Ronhjones ^(Talk) 15:19, 17 December 2016 (UTC)[reply]

Question Are we not treating the symptoms and not the disease with all these filters? It's a bit like a Hydra, as we chop off one route, two more appear. I would like to suggest one of the following.

Range Block the entire Telenor range - we might need a check user to tell us the range - I've added all the ones I've blocked to Category:Sockpuppets_of_Wunnakyaw1 - I suspect there may be more though! If we did that I would go back to Telenor at ticket:2016120310005375 and tell them. That I would hope get them to make a FUP and stop this farce.
Do some sort of "auto-confirm" like en-WP - maybe 20 uploads of less than 10MB and 30days before confirmed.

Any other suggestions? It does not look like it's going to go away, and the more they try then the more likely they are to find a loophole that we would struggle to filter out. Ronhjones ^(Talk) 16:38, 17 December 2016 (UTC)[reply]

Indeed, I think this is pretty hopeless. Like I said a couple weeks ago, when you plug this up for one file format, you'll just get the same problem with another. Perhaps we haven't gotten any archives embedded in, say, PDF files, but it's only a matter of time.

Big range blocks, or contacting the user's ISP to get them to send the user a sternly-worded letter, could work. Or, from the technical side, as a last-resort we could prevent unprivileged users from downloading original versions of files. (We'd still let everyone view transcodes and thumbnails and such, which should limit the inconvenience to legitimate users and the damage to Commons' principles, but it's still something I'd feel quite uneasy about.) Matma Rex (talk) 17:02, 17 December 2016 (UTC)[reply]

@Matma Rex: How about preventing downloading original versions for users in Zero range only? --Zhuyifei1999 (talk) 17:25, 17 December 2016 (UTC)[reply]

I imagine it should be technically possible. No idea how that would sit with the specific Zero provider agreements. I actually have no idea how they work, but wmf:Wikipedia Zero Operating Principles promises "A full Wikimedia experience", which this really wouldn't be if we applied this limitation to Zero users only. It's something that would have to be consulted with WMF Legal (or whoever else is responsible). Matma Rex (talk) 21:15, 17 December 2016 (UTC)[reply]

The OTRS ticket correspondent didn't get back to me as promised, so I used that opportunity to remind them and explain that we are getting overrun with this issue. I'm hoping it will enable a FUP to be applied. Ronhjones ^(Talk) 22:57, 17 December 2016 (UTC)[reply]

Question Telenor have replied, asking what we think a reasonable daily cap should be? As far as I can see the uploads have been in the range 250 to 800MB in size. I was therefore thinking in the order of 200MB max per day. I asked if they could just cap wikimedia.org and not wikipedia.org - I think that would impact less on normal usage. Ronhjones ^(Talk) 23:34, 18 December 2016 (UTC)[reply]

Update. Good news is that Telenor is setting a daily cap of 150MB for all users, unfortunately it is unlikely to be functioning until second week of January. That means that not only will they not be able to upload the files (unless they use another route), but Telenor users won't be able to download them anyway. Obviously we still need to keep the filters on and watch for uploads, but this should, when active, block a large hole. Ronhjones ^(Talk) 19:49, 20 December 2016 (UTC)[reply]

P.S. They are unable to apply to just Wikimedia, so the cap is for all usage. Ronhjones ^(Talk) 19:52, 20 December 2016 (UTC)[reply]

Looking at the 2013 48x48px thumbnail audit (21,435,219 requests), it averages 2.5 KB/icons. Now looking at the mobile website with Chrome's Inspector, I see about ~100 KB/page, ~20 KB/page with cache, and ~100 KB/image in media viewer. So 150 MB/day gets you about ~1,500 articles/day or 1,500 images/day. Mind you these pirates manged to cram a 67 minute porn movie into a 62 MB file, so its only a little deterrent. —Dispenser (talk) 04:13, 21 December 2016 (UTC)[reply]

Info Telenor users are using some VPN for bypassing ip block and to upload on Commons, and then download via WP0. Here is their method. Ninja✮Strikers ^«☎» 05:55, 21 December 2016 (UTC)[reply]

Yeah, very typical of Zero abuse. Pinging @Teles, NahidSultan, and Gunnex: as they might be interested --Zhuyifei1999 (talk) 06:39, 21 December 2016 (UTC)[reply]

Info Please take a look on Loader mm's uploads and Smalleryuper89's uploads. These may aslo contain embedded data in invalid ogg files. Ninja✮Strikers ^«☎» 07:55, 21 December 2016 (UTC)[reply]

Info It seems they have moved to OGG now: File:Deccoryyu.ogg ★ Poké⁹⁵ 03:41, 23 December 2016 (UTC)[reply]

99.1% of files on Commons are under 25 MB (68–95–99: 68% <2.4 MB, 95.6% <10 MB, 99.7% <85 MB). Request Abuse filter to flag upload > 25 MB and accounts under 100 edits? Dispenser (talk) 18:31, 23 December 2016 (UTC)[reply]

Excellent! Thanks for doing the queries. IMO a new AF rule is a good idea, especially that I was going to create one for audio files bigger than 100 MiB. --jdx ^Re: 19:25, 23 December 2016 (UTC)[reply]

Sounds like a great idea to me, It gets my vote. Ronhjones ^(Talk) 20:01, 23 December 2016 (UTC)[reply]

Flagging >25MB is ok, but will give us quite a few false positives (0.9% is still quite a few files). I'd suggest starting out with the limit significantly higher (200MB?) - they don't seem to be trying to upload many smaller files (yet). It can always be decreased if necessary. Storkk (talk) 20:06, 23 December 2016 (UTC)[reply]

I think we could set up three thresholds: for video, for audio and for remaining files, i.e. for still images + PDFs and DJVUs. @Dispenser, could you do appropriate queries? --jdx ^Re: 20:52, 23 December 2016 (UTC)[reply]

Commons File Size (Megabytes, All users)
Type	Mime	Files	84.1%	97.7%	99.0%	99.9%	99.95%	Largest
AUDIO	application/ogg	688,839	0.1	5.2	13.4	68.1	117.6	279.7
AUDIO	audio/midi	4,800		0.1		0.3		0.4
AUDIO	audio/wav	2,445	49.3	214.6	319.0	696.2	801.0	1,093.8
AUDIO	audio/x-flac	2,682	26.2	256.3	355.6	550.0	567.4	715.3
BITMAP	image/gif	147,313	0.3	2.6	4.9	23.0	32.2	133.0
BITMAP	image/jpeg	30,862,391	4.8	10.7	14.3	26.5	35.0	709.3
BITMAP	image/png	1,846,587	0.7	6.3	11.8	41.1	58.7	627.6
BITMAP	image/tiff	723,926	63.6	173.4	207.0	344.6	412.4	3,251.9
BITMAP	image/vnd.djvu	48,327	29.9	79.8	94.4	180.7	211.0	939.9
BITMAP	image/x-xcf	927	6.2	35.1	41.0	69.1		104.7
DRAWING	image/svg+xml	1,065,736	0.5	5.6	9.6	11.6	12.7	85.1
MULTIMEDIA	application/ogg	316	2.4	27.3	42.9	55.9		74.0
OFFICE	application/pdf	314,193	8.0	46.2	66.9	239.1	344.1	1,206.5
VIDEO	application/ogg	60,856	32.2	97.2	210.3	1,193.1	1,643.8	3,292.0
VIDEO	video/webm	29,657	136.8	674.2	949.9	2,576.3	3,209.7	4,079.3

@Jdx: Annoyingly manual. Excluding established users (100+ edits) should cut the noise. Dispenser (talk) 23:58, 23 December 2016 (UTC)[reply]

@Dispenser: Thanks! But I have a few questions:

Shouldn't the header of the 5th column be 99.7% (μ ± 3σ)?
What does 84.1% mean, given that 68.2% is μ ± σ and 95.4% is μ ± 2σ?
Just out of curiosity, WTF is type="MULTIMEDIA" + MIME type="application/ogg", given that there is type="VIDEO" + MIME type="application/ogg"?
When you write MB you mean MiB, right?

--jdx ^Re: 00:54, 24 December 2016 (UTC)[reply]

@Jdx: I'm bad at statistics. This is a survey—not samples. I've added largest size to make this clearer. I used numbers from w:File:PR and NCE.gif, but that's wrong if the data is not normal (a good possibility). I look at as 99.9% = 1 in 1,000 files will be flagged. But a good method for screening as only 2.5% of files >25 MB are uploaded by users under 100 edits (compared to ~50% <25 MB).

application/ogg (MULTIMEDIA) is Opus. Also, MediaWiki misMIME-types audio/webm as video/webm

Yes, MiB. Base-10 computer units are for liars.

Dispenser (talk) 03:11, 24 December 2016 (UTC)[reply]

I've added a 99.0% column. If I added a 50% column it would be median rather than the mean (μ) as I erroneously thought. Do not assume a normal distribution with this data. Dispenser (talk) 14:40, 3 January 2017 (UTC)[reply]

Comment The block duration for 37.111.0.0/20 (Telenor ip) is set to be expired on 29 December 2016. I would like to suggest to extend the block duration until the Telenor set the bandwidth limitation. Currently, the users are still uploading pirated data as ogg (simply changing file extension) and webm files via VPS/proxy. Ninja✮Strikers ^«☎» 15:04, 26 December 2016 (UTC)[reply]

@Ninjastrikers: Since Telenor's daily usage cap is expected to start the 2nd week of January, I pushed this out to the middle of the 3rd week (the 20th). Revent^talk 15:40, 26 December 2016 (UTC)[reply]

Please take a look File:Kjukiloja.webm. 30 seconds duration with 640 × 360px occupied 373.64MB. Another type of embedded data file? Ninja✮Strikers ^«☎» 16:56, 26 December 2016 (UTC)[reply]

Almost for sure it's a fake. E.g. today's media of the day is 7+ times longer, it's FullHD (i.e. it has 3× bigger V & H resolution) and its size is less than 1/3 of the size of the file you mentioned. --jdx ^Re: 17:32, 26 December 2016 (UTC)[reply]

Confirmed and Deleted. About 968455 bytes of valid webm, and about 390821355 bytes invalid (that's 99.75%). MIME detection shows RAR archive. (I don't have rar extractor so idk what's inside) --Zhuyifei1999 (talk) 18:15, 26 December 2016 (UTC)[reply]

How about Morganfreeman007's uploads? Less than 20 minutes duration and the file size is nearly 1GB. Ninja✮Strikers ^«☎» 07:25, 28 December 2016 (UTC)[reply]

Whatever else this does seem to be an ongoing issue. In the past 24 hours I've deleted a number of this type of file. In some cases it looks fairly obvious to me that puppet accounts are being used in this and I've blocked these. In passing - thanks to @Ninjastrikers: for their work in tagging these files. --Herby ^{talk thyme} 13:27, 28 December 2016 (UTC)[reply]

This is sick. I'll code an adminbot for auto speedy deletion and get it running in January; sounds like a better plan than last one? --Zhuyifei1999 (talk) 13:40, 28 December 2016 (UTC)[reply]

Err, I found some unusual tif files with large file size. Please take a look here. Ninja✮Strikers ^«☎» 14:57, 28 December 2016 (UTC)[reply]

Or for those of an admin inclination... here ('cos they've gone now ;-) --Herby ^{talk thyme} 15:19, 28 December 2016 (UTC)[reply]

FYI I blocked a couple of accounts for "Uploading embedded data.". Yann (talk) 15:27, 28 December 2016 (UTC)[reply]

It would be easy to get rid of these if we can get an automatic hidden category added. Regards, Yann (talk) 15:34, 28 December 2016 (UTC)[reply]

Interesting new twist - User:Oscar2099 uploaded 13 webm videos (all with youtube as source, so I deleted them as copyvios), at same time tried to upload very large jpgs with data (triggering filter 160). Maybe trying to hide their uploads in a sea of "normal" uploads? Trying to test filter to see how big they can upload? User is, of course, now blocked. Ronhjones ^(Talk) 17:21, 28 December 2016 (UTC)[reply]

Info Yesterday I created rule #166 based on the data provided by @Dispenser (see the table above). So, please watch its log and delete suspicious crap. Ideas how to improve the rule are welcome. --jdx ^Re: 20:00, 28 December 2016 (UTC)[reply]

Any extra filter must be better, 166 has triggered 3 and one was bad - other two had large upload log, just big images! In general if it's their only contribution, then that is a bad sign. Ronhjones ^(Talk) 00:22, 29 December 2016 (UTC)[reply]

In most .ogg files it is the same audio file wich is being uploaded with the embedded "copyvio". Could that audio be extracted somehow and find a way for us to match against that audio upon uploads? Since they are most likely just adding "their file" after the audiofile in the source code...? [Josve05a question moved here by jdx from rule #166 notes]

@Josve05a: AFAIK AbuseFilter can't do this because it has no access to file content, it has access only to basic metadata such as file (MIME) type and file size. --jdx ^Re: 22:27, 29 December 2016 (UTC)[reply]

FYI: Commons:Bots/Requests/Embedded Data Bot --Zhuyifei1999 (talk) 07:22, 30 December 2016 (UTC)[reply]

I like it. --jdx ^Re: 23:19, 30 December 2016 (UTC)[reply]

@Jdx: How about adding a user registered within a month condition to the Special:AbuseFilter/166? Another false positive, File:Woburn-abbey-panorama1.jpg, is uploaded by a user registered two years ago. --Zhuyifei1999 (talk) 12:15, 31 December 2016 (UTC)[reply]

@Zhuyifei1999: Sure, it's a good idea. I would even say that a week, max. two is enough. But I'm busy in the next few hours and later I'll be drunk.

--jdx ^Re: 12:40, 31 December 2016 (UTC)[reply]

Done Special:AbuseFilter/history/166/diff/prev/1379 --Zhuyifei1999 (talk) 12:47, 31 December 2016 (UTC)[reply]

FYI: Two false negatives by the filter, just under the threshold --Zhuyifei1999 (talk) 10:51, 1 January 2017 (UTC)[reply]

Should we not change filter 166 to just deny uploads, the amount of false positives has dropped right off with change to a week old account. Ronhjones ^(Talk) 16:31, 1 January 2017 (UTC)[reply]

See my previous comment. I'd rather have my bot delete them on sight rather than having a AbuseFilter set with disallow. Btw: that filter literally finds all sorts of hour long videos, even at low resolution and without appended embedded data (eg. File:Kskskw.webm). Just for comparison, video2commons has a requirement of autoconfirmed (user age > 4 days) + 50 edits. If we need to add disallow here, I'd suggest lowering the requirement, as many pirate's very first edit is the upload that triggers the filter. --Zhuyifei1999 (talk) 17:23, 1 January 2017 (UTC)[reply]

Btw: When that filter catches something large that my bot doesn't, I'll download it to Labs to do the analysis (my own internet connection is too slow), in order to check if the pirates used new tactics that my algorithm can't detect yet (I know a few ways to workaround the checks, and keep the overhead at the same time). Downloading to Labs require it to be undeleted, as pywikibot doesn't seem to support downloading deleted images. --Zhuyifei1999 (talk) 17:32, 1 January 2017 (UTC)[reply]

I agree that the accounts are always very new, even 4 days would trap them. Ronhjones ^(Talk) 20:57, 1 January 2017 (UTC)[reply]

The filter should be renamed "Large files uploaded by a new user" to avoid admins deleting false positives. Lower: FLAC/WAV/XCF to 84.1%, these are unusual files on Commons. Raise: JPG/PNG to the 99.9% or 99.95% since we have better filters for them. MIDI to 0.5 MB (100%, still too small to be useful). Everything else raise to 99.0% from 97.7% level. The function should be inverted, so approve sizes and formats fixing the catch all, !( ... & file_size < int( ... )). Dispenser (talk) 23:49, 6 January 2017 (UTC)[reply]

Okinawa locator maps problem

Is it my computer/system, am I missing something, or is there an actual problem? On several maps that are supposed to be locating communities on the island of Okinawa, I can see no location indicator on the maps at all. These include (but are not limited to):

Category:Locator maps of municipalities in Okinawa prefecture:

Category:Maps of Okinawa prefecture

Etc, etc.

Am I missing something? --Calton (talk) 14:15, 2 January 2017 (UTC)[reply]

On my screen each map has one section colored a brownish orange. Dankarl (talk) 21:42, 2 January 2017 (UTC)[reply]

Same here. These maps don't use dots as point markers for the location but the relevant area is coloured somewhat differently. I think though that this "brownish orange" was a rather poor choice because it doesn't stand out very well. A better contrast would be desirable. De728631 (talk) 11:59, 3 January 2017 (UTC)[reply]

OK, I've checked a couple by flipping back and forth between them, and I see what you're talking about. God, that's a horrible design choice, even if there had been some sort of key designating the color. --Calton (talk) 15:53, 5 January 2017 (UTC)[reply]

I went ahead and changed the colours in all these maps so the locations should now be more obvious. De728631 (talk) 17:47, 5 January 2017 (UTC)[reply]

Speedy deletions needed

I've just done a mass upload from Flickr. I inadvertently included some (near-)duplicates, and some images which, though open-licensed, are clearly third party stock images, rather than tagging all 65 individually, I've put them in Category:Temp: Pigsonthewing uploads for speedy deletion. Could someone delete them, please? Andy Mabbett (talk) 01:12, 3 January 2017 (UTC)[reply]

@Pigsonthewing:

Done. Sebari – aka Srittau (talk) 02:06, 3 January 2017 (UTC)[reply]

Thank you. Srittau. I've added a few more; that should be it, now. Andy Mabbett (talk) 11:20, 3 January 2017 (UTC)[reply]

Isabel Borrego

Please can someone rescue the old version of File:Isabel Maria Borrego Cortes.png, which was recently overwritten by an entirely different image? Andy Mabbett (talk) 13:31, 3 January 2017 (UTC)[reply]

I thought about doing it, until I looked at entire gallery of uploader which is now nominated for deletion. Cheers! Ellin Beltz (talk) 15:21, 3 January 2017 (UTC)[reply]

{{DRnav}} missing for Deletion requests in 2017

Administrators,

I noticned that the DRs for 2017 has been not pre-created with the {{DRnav}} header, that caused it is missing from the latest DRs. Could admin run a bot to create them? --Amitie 10g (talk) 13:35, 3 January 2017 (UTC)[reply]

Revert of i18n

Please revert this corrupting editofTemplate:On Wikidata/i18n/cs. The system obstructs a simple revert and link to a translation tool but I didn't find how to revert with the tool. --ŠJů (talk) 20:09, 3 January 2017 (UTC)[reply]

It seems to be corrected now. However, the impossibility of simple reverts of vandalism is a problem. --ŠJů (talk) 20:14, 3 January 2017 (UTC)[reply]

File:Flight427 wreckage.jpg

Can an admin please remove any personal names from this pic's medadata. Thank you. — Preceding unsigned comment added by DrNegative (talk • contribs) 03:28, 04 January 2017 (UTC)[reply]

@DrNegative: Please upload a new version without metadata, we can then version delete the old version. Sebari – aka Srittau (talk) 04:13, 4 January 2017 (UTC)[reply]

As requested, thanks. DrNegative (talk) 14:05, 4 January 2017 (UTC)[reply]

@DrNegative: Unfortunately it seems the latest version still contains meta data with personal info. Sebari – aka Srittau (talk) 06:14, 5 January 2017 (UTC)[reply]

Want a copy of a deleted file

Could someone please help me with a copy of this deleted file File:Indian_radio_license.jpg for some private use elsewhere. I can be reached by email (see commented address here) Shyamal L. (talk) 04:24, 4 January 2017 (UTC)[reply]

If an admin wants to fulfill the request: the e-mail address is in the deleted revision. Sebari – aka Srittau (talk) 04:57, 4 January 2017 (UTC)[reply]

Here is a similar image that could be downloaded. De728631 (talk) 11:08, 4 January 2017 (UTC)[reply]

I really need the one that I scanned and uploaded for some checks. My access to the hardcopy is a bit hard at the moment. I did not realize it is this difficult for retrieval. Shyamal L. (talk) 01:29, 5 January 2017 (UTC)[reply]

Done Ronhjones ^(Talk) 00:28, 6 January 2017 (UTC)[reply]

@Ronhjones: - gratefully received. Thank you. Shyamal L. (talk) 04:22, 6 January 2017 (UTC)[reply]

Protection

I think this template should be fully-protected against vandalism. This is a highly used template.--ILWC (talk) 09:10, 4 January 2017 (UTC)[reply]

It is used six times and there is no evidence that it is a target of vandalism.

Oppose. Storkk (talk) 09:48, 4 January 2017 (UTC)[reply]

@ Storkk thank you. — Preceding unsigned comment added by ILWC (talk • contribs) 11:54, 04 January 2017 (UTC)[reply]

Not done Request by vandalism sock. Sebari – aka Srittau (talk) 06:13, 5 January 2017 (UTC)[reply]

Inquire about undeletion

Hello.If the file was created by a church in Egypt in 1980, It should be restored (or uploaded) in 2031 (after 51 years)?Thank you --ديفيد عادل وهبة خليل 2 (talk) 08:24, 5 January 2017 (UTC)[reply]

Hiديفيد عادل وهبة خليل 2,

Could you say which file you are talking about? Regards, Yann (talk) 10:09, 5 January 2017 (UTC)[reply]

@Yann: Any file deleted or can be uploaded in the future, Should it be here after 51 years?Thank you --ديفيد عادل وهبة خليل 2 (talk) 10:15, 5 January 2017 (UTC)[reply]

Any deleted file can undeled at a later date. Just add it in Category:Undelete in 2031. Regards, Yann (talk) 10:18, 5 January 2017 (UTC)[reply]

@Yann: Well, please review this request for 2029 and 2035.Thank you --ديفيد عادل وهبة خليل 2 (talk) 10:53, 5 January 2017 (UTC)[reply]

Auto-protected edit request

Could an admin please fix cats for File:Reina restaurant Istanbul (cropped).JPG like this: +Category:Reina (nightclub); –Category:Ortaköy –Category:Restaurants in Istanbul (I can't cause it's currently auto-protected). Thx :-) --.js (((☎))) 13:13, 6 January 2017 (UTC)[reply]

@@ Line 14: / Line 14: @@
 == Influx of files with embedded data ([[COM:CSD|CSD#F9]]) – continuation ==
-: ''[[Commons:Administrators' noticeboard/Archive 61#Influx of files with embedded data (CSD#F9)|Previous discussion]]; Abuse filters: [[Special:AbuseFilter/160|JPEG]], [[Special:AbuseFilter/162|PNG]], and [[Special:AbuseFilter/165|GIF]]; Reports: [[User:Dispenser/Absurd overhead|Absurd overhead]], [[User:Dispenser/Wrong Extension|Wrong Extension (zero pixel check)]]''
+: ''[[Commons:Administrators' noticeboard/Archive 61#Influx of files with embedded data (CSD#F9)|Previous discussion]]; Abuse filters: [[Special:AbuseFilter/160|JPEG]], [[Special:AbuseFilter/162|PNG]], [[Special:AbuseFilter/165|GIF]] and [[Special:AbuseFilter/166|large newbie uploads]]; Reports: [[User:Dispenser/Absurd overhead|Absurd overhead]], [[User:Dispenser/Wrong Extension|Wrong Extension (zero pixel check)]]''
 {{info}} I am writing to let you know that pirates have switched from JPEGs and PNGs to GIFs: [[Special:DeletedContributions/Windowuploaderminmya1996]]. --'''[[User:Jdx|<span style='color: #02d6b0;'>jdx</span>]]''' <sup>[[User talk:Jdx|<span style='color: #924685;'>Re:</span>]]</sup> 10:30, 15 December 2016 (UTC)
@@ Line 259: / Line 259: @@
 :::Btw: When that filter catches something large that my bot doesn't, I'll download it to Labs to do the analysis (my own internet connection is too slow), in order to check if the pirates used new tactics that my algorithm can't detect yet (I know a few ways to workaround the checks, and keep the overhead at the same time). Downloading to Labs require it to be undeleted, as pywikibot doesn't seem to support downloading deleted images. --[[User:Zhuyifei1999|Zhuyifei1999]] ([[User talk:Zhuyifei1999|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:32, 1 January 2017 (UTC)
 ::::I agree that the accounts are always very new, even 4 days would trap them. [[User:Ronhjones|<b style="border:1px solid #dfdfdf;color:green; padding:1px 3px;background:#FFD">Ron<span style="color:red">h</span>jones&nbsp;</b>]]<sup>[[User talk:Ronhjones|&nbsp;(Talk)]]</sup> 20:57, 1 January 2017 (UTC)
+::::: The filter should be renamed "Large files uploaded by a new user" to avoid admins deleting false positives.  Lower: FLAC/WAV/XCF to 84.1%, these are unusual files on Commons.  Raise: JPG/PNG to the 99.9% or 99.95% since we have better filters for them.  MIDI to 0.5 MB (100%, still too small to be useful).  Everything else raise to 99.0% from 97.7% level.  The function should be inverted, so approve sizes and formats fixing the catch all, ''!( ... & file_size < int( ... ))''.  [[User:Dispenser|Dispenser]] ([[User talk:Dispenser|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 23:49, 6 January 2017 (UTC)
 == Okinawa locator maps problem ==