Actually, I managed to make the list and send it to my now opted out mobile account. But I can't replicate the bug.

I've attempted to test this myself, but nowhere on the wiki does it explain how to fix a "Invalid content data" error if you try to make a MassMessage target list so I can't.

I think one big question is how sure we can be that all contributions by that IP were in fact done by that user.

Not an oversighter, but double cross for OS and cross for regular RD sounds intuitive.

Also "An exception occurred: TaskError: /mnt/nfs/labstore-secondary-project/gentoo-prefix/usr/bin/ffmpeg -y -i /srv/v2c/output/0f35cf2ec105137b/dl.unknown_video -max_muxing_queue_size 4096 -threads 16 -row-mt 1 -crf 20 -qmin 1 -qmax 51 -b:v 0 -vcodec libvpx-vp9 -tile-columns 4 -auto-alt-ref 1 -lag-in-frames 25 -speed 4 -f webm -an -pass 1 -passlogfile /srv/v2c/output/0f35cf2ec105137b/dl.unknown_video.an.vp9.webm.log /dev/null Exitcode: 1" on another

Seems like you may want to simply query for not locked+"WMF" and manually clean the resulting list from false positives.

It is however not what is commonly understood as "NSFW". If you take a word that means A and use it to name concept B you invariably end up with people assuming that it is about A.

Tough one. Many people in the various admin-appointment processes have criteria beyond trust - such as knowing policies in areas like deletion that have little to do with security - and I would not categorically assume that folks trusted to hold IE will also be trusted to hold full admin rights.

I am guessing you'd need to start the review steps at Writing_an_extension_for_deployment#Preparing_for_deployment.

No, it seems like the issue resolved itself soon after the first report. It was on Wikimedia's enwiki, for the record.

@PiRSquared17: T155967#2963144 implies that the titleblacklist triggers even from mere reads. A titleblacklistlog that only logs account creation isn't really useful or justified, anyhow.

To be fair, 76% is more consensus than 75%.

Yes.

Huh - I always thought that the reason why we have MediaWiki messages is specifically so that we can say different things per wiki. Especially since while the extension is on Commons, it carries out actions on enwiki (the deletion) as well.

Do note that currently, enwiki non-admins cannot upload files to filenames already "taken" by Commons files. And most instances of shadowing occur when the Commons file is uploaded later.

During this attempt the error code was "XprDRQpAMMAAAPpnAyAAAAAD" but I am not sure if it is always the same

Seems like we still have the issue, now at https://en.wikipedia.org/wiki/File:Everyday.jpg

@Billinghurst and others: I've created T246090 to discuss whether GET/read requests should be left unlogged, as it seems slightly unrelated to the issue here.

I believe what Doug Weller is trying to say is that enwiki oversighters are all admins and admins on enwiki hold the "review" permission. And yet sometimes there is a permission error for oversighters. Which is a bug as it shouldn't happen to users who have the "review" permission via their usergroup.

If it helps, it also seems that such files tend to fall off their categories. E.g these two files on Friday didn't appear on https://en.wikipedia.org/wiki/Category:Expired_proposed_deletions, once I null-edited them they appeared there, and now they don't display again.

Actually, editinterface has been around for a long time. It allows editing of all MediaWiki: namespace pages as they are not all super sensitive, the css and js extra permissions were created because js and css pages in the MediaWiki: namespace and elsewhere are more sensitive than the average MediaWiki namespace page.

No, GlobalBlocking is only about IPs.

Also, I wonder how well that would work for users in places where ISPs do change between IPs at a high rate. Some people on enwiki have said that some ISPs in the United Kingdom can cycle through several IPs in the same minute.

I am concerned that it will result in a lot of false positives that way.

I take that you are going to consider both false positives and false negatives - especially when it comes to declared paid editors - when training this, yes?

"As noted above, there are websites that can do TOTP if you can't install an authenticator app. Although I suppose some people might be opposed to doing that too. At some point there might need to be a cutoff for "don't want to"." Well yeah I'd expect that a lot of people don't want to trust a login that relies on a third party website/software, as they are often less than dependable & easy to use.

Well, on enWikipedia a few more issues have been raised:

• Not everybody has two devices available or is willing/able to pay for them.
• 2FA is not necessarily legal everywhere in the world.
• Not everybody can/will download an authenticator software in lieu of two devices, e.g when they are on devices they don't own.
• Technically complex. In my personal opinion, some folks who are tech savvy might be underestimating the complexity of such arrangements.
• The current system is prone to causing an account lockout.
• There are concerns of a slippery slope effect towards progressively less reasonable security measures.
• Only pertaining to sysop: Many people are not entirely convinced that the few instances of sysop accounts being taken over are worth these problems even if there were a solution for them.

T121186 is the task where password audits are discussed so far.

"TA" is for "technical admin" which I guess stands for "interface admin" (https://www.mediawiki.org/wiki/MediaWiki_1.32/interface-admin). I don't think that it has anything to do with editing robots.txt messages though, the https://en.wikipedia.org/wiki/MediaWiki:Robots.txt message can still be edited by normal admins.

Such changes-through-the-local-group approach also helps with another issue, that of local user right changes not showing on the local user rights log. That is often a source of confusion.

Maybe a randomized selection would work? So if there are 3 candidates with 3 images it displays one at random?

You know, I was thinking that this task was about enabling such a functionality in Wikimedia but actually the GlobalBlocking function does not allow account blocks if https://www.mediawiki.org/wiki/Extension:GlobalBlocking is accurate. Maybe this task needs to be split?

I don't see an EDP either.

I presume that VisualEditor does not necessarily know about which format to use.

This looks like a somewhat vague query. Do you want that MediaWiki automatically protects deleted files against creation? Or a prompt to do so when they delete the page? For what it's worth one could add a prompt on the MediaWiki:Deletedtext message.

Um, which Wikipedia do you want it enabled in? Is there a consensus on that Wikipedia to do so?

Actually, the suppression reasons are sometimes used by admins on enwiki ... when we get across something that probably merits suppression we often hide it pre-emptively before informing the oversight team to get it out of sight faster. The oversight team then has to judge whether it merits the full memory hole.

Other files with this issue are https://en.wikipedia.org/wiki/File:Japan_election_2005_prior.png, https://en.wikipedia.org/wiki/File:GPS-broadcast-signal.png, https://en.wikipedia.org/wiki/File:Fyodor_Petrovich_Tolstoy_2.jpg, https://en.wikipedia.org/wiki/File:Free_text.png, https://en.wikipedia.org/wiki/File:DubCrtHouse.jpg, https://en.wikipedia.org/wiki/File:Dover_Hotel,_Petty_Street,_Dover,_Stewart_County,_TN.jpg, https://en.wikipedia.org/wiki/File:DJ_Z-Trip_(2006).jpg, https://en.wikipedia.org/wiki/File:Plutoandcharon.jpg, https://en.wikipedia.org/wiki/File:Bond_hill,_cincinnati.JPG, https://en.wikipedia.org/wiki/File:Camera_phone_sharing.JPG, https://en.wikipedia.org/wiki/File:Ryan_Miller_(musician).jpg, https://en.wikipedia.org/wiki/File:RRF_TRF.GIF and https://en.wikipedia.org/wiki/File:RussiaNorthOssetia.Highlight.png

There are a few instances of this bug on enWikipedia as well: https://en.wikipedia.org/wiki/File:Neak_Pean_back.jpg, https://en.wikipedia.org/wiki/File:Picture_172.jpg, https://en.wikipedia.org/wiki/File:Velasco_Hall.jpg, https://en.wikipedia.org/wiki/File:Transylvania13cent_diocesan_div.PNG, https://en.wikipedia.org/wiki/File:Ta_C_wear_(original).jpg, https://en.wikipedia.org/wiki/File:Skin_shade_map.png, https://en.wikipedia.org/wiki/File:Sign_of_Albertaco%27s_in_the_Cypress_location.JPG, https://en.wikipedia.org/wiki/File:Senate_ES_Composition_2000.png and https://en.wikipedia.org/wiki/File:San_Giovanni_Lipioni_seen_from_Il_Monte_mountain(2006).jpg are compound files that cannot be split because of this bug.

Yes, that sounds like a minefield of privacy violations...

To me that sounds like a problem with these permissions, then. I think that any extension should check for the relevant user rights when it needs to check, not for some related user right.

See, I thought that having separate "view deleted stuff" and "delete and undelete stuff" permissions was exactly to cover such cases.

I don't know about other projects but on enwiki we usually indef block accounts engaging in behaviour that gets accounts locked. And when an expiry is applied anyway, what typically happens is that the account is gone completely after the block has expired or that the misbehaviour continues, requiring more work at cleaning it up/more readers seeing vandalized or spammy content.

A bit more courtesy may be warranted.

Works for me at this time.

This was declined at T13386 a decade ago.

How reliable is MaxMind? I recall from some enwiki discussions that it sometimes defaults to an incorrect "default" location.

How many names would need a localization, anyway? I don't know if Wikidata would be considered fit for this purpose.

I believe that such a concern would belong in T6714 since that is the task for edit summary length.

Seems like such a construction would increase the time it takes for an edit to be rolled back, which is a problem for vandalism on highly visible pages (I've seen pages on enwiki with 100,000 or so views per day) and for wikis with lots of readers and lots of rollback actions (even if the added delay only increases the number of readers that see a vandalized version by 0.01 readers/rollback, this stacks up on a wiki with 1000 rollbacks per day to 10 readers) since it increases the visibility of vandalism. No opinion on what the cost/benefit ratio is at the end.

Well, no, stalking and following around does not have to be invisible. As for blocking other people from following you, some editors make bad edits and need to be followed around to clean up behind them.

T91192 is one possible way to implement this, although it may be too narrow in scope and carry technical risks.

The rationale for such accounts is to create an email address that people can send oversight requests, arbitration queries and the like to.

Seeing as this has been rolled out locally already, one wonders if the questionable use pattern mentioned here has been encountered anywhere.

Folks are still working on the patch linked above, seems like.

As noted T149522#3057977 and my post beneath it, it is not clear if such is warranted. (Incidentally, I am not sure if "Books that are not free in US should not be uploaded to any Wikimedia project" is correct - certainly I do have the impression that dewiki uses the copyright policies of Germany, Austria and Switzerland instead. I never understood why)

We have had issues in the past with small wiki uploads becoming swamped with copyright violations. So we need to check very carefully that there are rules in place about non-free content, and there aren't many copyright law experts and Tulu speakers about.

enwiki recently introduced userspace noindexing, but it was not for privacy reasons. I am not aware of many other projects which do this, a dip sample of some major (commons and itwiki) and some minor (dewiktionary, dewikiquote) projects indicates that some do index userspace and others (dewiki, eswiki) don't.

Maybe the font size on your phone is just too small? https://www.samsung.com/us/support/answer/ANS00039821/ has an explanation on how to change it.

The user-side of deletion logs does not inherently have a search function, unless the specific actions are marked with a tag.

Image use policy means that you need a policy explaining what kind of uploads are allowed and which aren't. Copyright is a particular concern in thar regard.

Perhaps what is wanted is to allow page curation to supports variations on the workflow I proposed above. That would mean Page Triage, but with the messages/tags/notifications customizable (including no notification). And where a deletion discussion is posted would also be customizable. And how many iterations of these workflows are possible. I don't know if this all is technically feasible.

@MarcoAurelio's proposal seems to be the right one. As far as I know, most workflows for deletion involve:

• A tag on the article, linking to the place where the discussion is held
• A notification on the talk page of the user who made the article
• Either:
  • A dedicated page like "Project:X/Articletitle" (e.g Commons:Deletion requests/File:Spam.png)
  • A section on a dedicated page like "Project:XY#Articletitle" (e.g Wikipedia:Files for deletion/20 September 2017#File:Spam.png), typically with Y being a date
  • No discussion at all (PROD and speedy processes)

The developers of the component in question, I'd imagine.

I was just contesting the claim that people will figure out by themselves how these things work.

Citation templates might be a good start, as they are frequently copied between projects. That said, is it already agreed upon _where_ they will be put? The task title implies this but I don't see any discussion which came to a consensus on that question.

There already are such messages; https://www.mediawiki.org/wiki/MediaWiki:Centralauth-error-locked and https://www.mediawiki.org/w/index.php?title=MediaWiki:Centralauth-login-error-locked&action=edit&redlink=1

The explanation is needed because otherwise the feature is unused or people make bad markup for things that don't have the feature.

MP3 files are commonly used for music. Said music is typically non-free and there is the concern that allowing MP3 uploads will lead to a number of improper uploads of non-free MP3s by users who were up to now held up by the "no MP3 allowed" restriction.

Bit concerned that deleting the user talk page could be used to evade/reduce scrutiny. Also, what happens to a deactivated account if it tries to edit?

Not convinced that replacing magic links with yet more magic links is a good way to go about this. Perhaps going around the affected wikis and adding the requisite templates so that people only need to learn to add {{templatename|somenumber}} works better.

Not sure that the template markup "{{PMID|somenumber}}" is in any way messier and unreadabler than "PMID somenumber". The very existence of this task is kind of proof that the magic links can make problems. As well as a number of "RFC somenumber" making false positive links on enwiki.

There is a gadget on https://en.wikipedia.org/wiki/MediaWiki:Group-sysop.js that alerts an admin when they are about to block a sensitive IP.

Hum. Why did performance issues occur just now? Special:AllPages has been around for a long time.

I think you should decide whether to have non-Commons images or not. If no, local upload isn't necessary. If yes, people will ask what you want to upload locally - we've had issues with shoddy copyright practices in smaller projects that allow uploads.

Seems like. Also, the concern I noted before about this privilege allowing one to potentially sidestep editing restrictions on user CSS/JS pages needs to be resolved.

https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves#Using_the_MergeHistory_special_page does exist on enwiki

To my understanding, big part of the issue with this is old contributions in the databases that can throw up if reassigned.