*.esa.int works for what we know. The only images I've seen so far have been on the two specific domains listed.

I have no idea if the same person is behind this, or it's just a bit of haphazard pointy trolling, but this seems far too easy to disrupt email lists with cross-posted spam:
https://lists.wikimedia.org/pipermail/gendergap/2017-April/006589.html
Example from today, directed at me.

Yes, the inconsistency is worrying. However I'm also concerned that the recommended "fix" is slightly stupid from the GLAM uploads perspective. I am not going to tamper with perfectly okay original EXIF data, that matches the EXIF data in external archives, just because on Commons we invented an arbitrary and non-intelligent filter.

I suggest this task is closed. There's too much push back against the task description for this to be realistic. If someone wishes to propose a new task aimed at the blacklist filter process helpfully parsing url redirects, perhaps for a limited number of iterations, and checking those against the blacklist again before rejecting a text, that would be positive.

@Billinghurst See the discussion at https://commons.wikimedia.org/wiki/Commons:Bureaucrats%27_noticeboard#Upload_project_spam_blacklist_exception_.27right.27 which was started at the same time this task was opened.

@matmarex This task is not about adding links to the spam-whitelist for a single GLAM upload project that has already completed. It is pointless to list individual bit.ly links, when what is requested is a generic solution in order to support and encourage "officially agreed" batch upload projects.

@Billinghurst that's the point of this task, to avoid volunteers like me having to write ever extending amounts of code to by-pass blacklists. We have the same problem with filename blacklists. I already have around 10 types of error trap in my upload process, I see little benefit in creating my own unique parser for all metadata fields on an GLAM import when the results post absolutely no risk whatsoever to Wikimedia Commons or our reusers and readers.

With regard to later edit, my edit today to https://commons.wikimedia.org/w/index.php?title=File:Marcha_das_Mulheres_Negras_(23137414611).jpg&action=history would have been impossible as the text contained a bit.ly link. So, I dispute impossible.

As Pharos and his folks are working to a deadline, I heartily endorse white-listing the site. This is no-risk as Pharos can ensure that test runs prove to everyone's confidence that licensing has been addressed and that the metadata is nicely handled, including credit templates and links to the license evidence, even if that requires an OTRS ticket.

Nudge. Why has this taken over 10 weeks?

Uploads will be from https://finds.org.uk/, will *.finds.org.uk cater for that?

The licence is CC-BY as stated at https://finds.org.uk/info/termsandconditions.

I mentioned BotPasswords as my understanding of https://www.mediawiki.org/wiki/Manual:Pywikibot/BotPasswords, was that it's just a password like any other, hence only as secure as the conventional login. However OAuth uses access tokens which provides an additional level of security. If the WMF is recommending that sysop accounts use 2FA, then my presumption would be that BotPasswords should be avoided on bot accounts with sysop rights for the same reasons.

Thanks, I was unsure if those were the response. I do not see any moves to ensure the advice to administrators is enforced. I doubt there will be any new policies until the analysis itself.

Nudge It's coming up to 2 weeks since the OurMine hack became public knowledge. Please at least issue an interim analysis, I'm sure there is a good understanding of what happened and how. In the absence of any official analysis, volunteers are working on assumptions right now, such as whether administrators using longer passwords is sufficient protection and whether BotPasswords is okay to use on bot accounts with sysop rights, rather than OAuth.

It may be that publishing dates of password changes would be more than can be queried from the public database, however a table of admins showing which had adopted 2FA is the type of thing that I would struggle to imagine as any significant extra risk and has good value as part of the community agreeing new policies for trusted accounts. In terms of targeting, this is probably a lot less significant than sharing user_properties or analysing edit patterns, which are available to anyone.

After digging into login.py, I'm wondering if we should be recommending that BotPasswords is avoided. Authorizing OAuth for user accounts wanting to simply run scripts for themselves, rather than making apps for others, happens automatically without needing any human approvals. For Pywikibot, once the user has their credentials, they simply add paste them into their local user-config.py, no other steps needed to get them to work.

More examples from different sources:
https://commons.wikimedia.org/wiki/File:Recycling_Center_reduces_tons_of_waste_output_130626-M-ZH183-010.jpg
https://commons.wikimedia.org/wiki/File:Bald_eagle_vocalizing_at_Eastern_Neck_National_Wildlife_Refuge._(21818868859).jpg

This is due to the NYPL uploads, which are coming to an end, though maybe with some final runs and housekeeping. As it happens I've started a wikibreak and packing to travel away on holiday, so my activity drops to zero from this weekend when I'll be forced by my husband to stay AFK until I get back, probably from 25 July. As you've raised this ticket, it's pushed my hand to drop any idea of maintaining remote access. :-)

This was a major headache for my NYPL uploads, due to being unable to get ['exists-normalized'] ignored. This bug is a real bear trap for batch uploads and is quite unobvious to debug.

With respect to the photolib, I say yes let's add it to the whitelist too. The images are described as /mostly/ public domain (i.e. NOAA) however some have restrictions. So far I have only noticed where there are credits to donors. Anyway, the concern to be careful on checking copyright is that of a future batch uploader to investigate, which may well end up being me in a few months.

@AWossink Thanks for the reply. Even for a modest 500-ish images, as the intention is for an ongoing partnership, please consider running an on-Commons project page to help with future feedback and to help working collegiately with Commonsists. There are many examples under https://commons.wikimedia.org/wiki/Commons:Batch_uploading or if you have several partnerships you want to collect together and maintain under your own area, like I do with https://commons.wikimedia.org/wiki/User:Fæ/Project_list. Drop a note on the GLAMtools email list if you set something up.

Is there a project page that explains why the chapter website is being used for training?

A bit of trial and error, shows that the fault can be suppressed by commenting out twinkle in my common.js:

importScript('User:Kanonkas/twinkle.js');

There were errors being raised in JavaScript, mainly around depreciated items. Swapping skins and custom CSS did not seem to make any difference.

Yes, that makes sense. I've been using Chrome, and when I shift over to Firefox the Commons image page renders its Filename perfectly well.

The issue is that the accented name appears fine in links, popups etc. see the first image below, but when the exact same unicode text is used for a filename, it gets displayed as bad character marks on the Wikimedia Commons image page, see second image.

In T128580#2079661, @Aklapper wrote:

Unrelated to Commons hence removing that tag from this task. Adding Tools instead.

I agree this is a broken process.

Just in case anyone investigates this TIFF problem, as a third route to upload I tried pushing 8 sheets of the Podunk score through the GLAMwiki toolset. None uploaded. The errors look like:
''''{

    "logid": 149907345,
    "ns": 6,
    "title": "File:No title",
    "pageid": 0,
    "logpage": 0,
    "params": {
        "metadata-record-nr": 2,
        "message": "This file did not pass file verification.\noriginal URL: http://link.nypl.org/KkaiBy1rR0W2fOc2hoCLTwd\nevaluated URL: http://link.nypl.org/KkaiBy1rR0W2fOc2hoCLTwd"
    },
    "type": "gwtoolset",
    "action": "mediafile-job-failed",
    "user": "F\u00e6",
    "timestamp": "2016-01-27T16:09:57Z",
    "comment": "music test tranche"
},''''

Update Here are the figures for 1-24 January for upload of "blanks". The numbers have remained small. As my uploads do a double-check for blanks and then re-write the text page, this has basically become invisible for my uploads but is still a regular failure and quite a bad thing to build into batch upload scripts without flagging it somewhere:

Probably 5 connections is sufficient. Some of my reports rely on more that one database link at the same time to make the SQL, though most are one at a time even when multiple queries are made for the report.

I thought that was covered by explaining on Phab how use of '-once' makes multiple jobs impossible for the BLP report. As multiple jobs are impossible, there is no reason to expect that this type of job could create a job backlog. All the other Faebot jobs run just a couple of times a day and cannot pose any sort of risk for a future outage, while the BLP report was running every 5 minutes as it was a popular vandalism prevention tool.

For anyone looking into the relationship between poor colour rendering and TIFF colour profiles; for the NYPL upload project I have started to add TIFF info data using Python PIL Image.info. Some of these can be searched out using https://commons.wikimedia.org/w/index.php?search=insource%3A%2FData+extracted+from+TIFF+info%2F&title=Special%3ASearch

Perhaps someone could write up the situation with the most relevant links is and the prospect for getting it solved? Ideally I would like to be able to link to an on-wiki guideline/advice to avoid having volunteers spending their time or reformatting TIFF colour profiles (or writing more Phab requests), if our official view is that this is going to be resolved by the browser developers long term.

FYI As well as the original browsers on a Mac with a vanilla OSX Yosemite, I have now tested viewing the same TIFFs on the default Chrome 47.0 browser under Android 5.1.1 with Cyanongen 12.1.1, and the colours display perfectly on that mobile platform.

As an example of the impact of the throttling, the "thanks report" https://meta.wikimedia.org/wiki/User:Faebot/thanks has not been updated since its last run in August 2015. There was going to be a Signpost article about the thanks feature based on this information, but that's a non-starter now.

I think the line you want to work this out is:

T50615 was not an improvement, has a doubtful use case and would have failed user testing had any been done.

In T50615#1817333, @Florian wrote:

For Special:RecentChanges see T119084: Options form at the top of old Special:RecentChanges needs cleanup.

@Fae: I don't really understand your use case. What is the intention of "see the results and then decide if it is worth hiding any more"? I think the use case of the Watchlist would be "What items I want to see, edits by bots? No. Edits by anonymous users? Yes. Click Submit". So I think a user already knows the groups of items he wants to see, no matter what amount of items are expected. If you want to reduce the number of items on the page, you probably want a limit option :)