Mmm, I kinda wonder about the copyrights of many of the documents hosted there. While any user-generated upload platform has to deal with them, I wonder if they might be a bit too prone towards hosting copyvios.

Added Isaach (WMF) in light of T264455#6702608

In T17294#9547674, @Vermont wrote:

In T17294#9528943, @Dreamy_Jazz wrote:

In T17294#9527056, @Sj wrote:

@Dreamy_Jazz thank you for working through this. Do you need feedback on some of those comments from one of the stewards requesting this?

It would be useful to know how much of a use-case there is for allowing local wikis to disable a global block on an account.

This is the point :P

The reason I/we want global blocks is for the relatively few cases where a user is engaging in cross-wiki abuse, yet there are projects where they contribute constructively without issue (and where the project would like that to continue). I don't expect this to replace global locks, just allow more options for handling cross-project conduct moderation.

Also had this issue in the morning, not sure whether in VE or not but it was tied with the enWikipedia reply tool.

I am pretty sure that a global ban would still be enforced by a global lock. So I don't see (3) as an use-case. The example given for (2) sounds like it'd end up a whack-a-mole case, especially considering the sheer amount of blocks in the history, which is really the common failure mode of time-limited restrictions. I also worry that we'd end up overusing time-limited blocks.

One thing I wonder about is what features are needed for such a function. Just because normal blocks are appealed on a talk page doesn't mean that this is the desired functionality for a global block, which may be better handled on a central page. And is there really an usecase for expiring global blocks?

On enwiki, we have implemented template functionality that allows you to edit a Wikidata entry from enwiki. It has some issues (namely that it logs you out at times).

As I've noticed on enwikipedia Citoid does recognize the DOIs on TWL-proxied pages, but does not draw the information from it. Is that in scope for this task?

Not the task for this, but why does an empty link= parameter render the file unclickable? Shouldn't it verify that there is something in the parameter?

Looks like reopening the conversation, rejecting the unsaved change, then re-closing the conversation works as a workaround ... but reopening closed conversations is a big deal so we can't do this as a matter of routine.

Changed from "stalled" to "open" since apparently the Wikidata issues mentioned before were resolved.

My impression is that part of the question was about the usecase - most global locks are for things like spambots and cross-wiki vandals, not situations where expiries, talk page appeals etc. would be useful.

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.