Write and implement Commons upload blacklist feature for Main Pages and other special pages
OpenPublic

Description

Some of the larger wikis have issues with images from Commons being used on highly visible pages, as it creates the possibility of vandalism happening on unprotected Commons images. The general workaround has been to upload copies of the images locally, usually using a bot[1], which is hackish and needs a better implementation.

With the implementation of GlobalUsage, it should be possible to create a local upload blacklist at Commons, similar to the bad image list or spam blacklist. This upload blacklist would be in a format like:

  • enwiki|Main Page

When a non-admin tries to upload an image on Commons that matches by title and wiki to a globalimagelinks entry and that matches to an entry at this Commons upload blacklist, the upload would be disallowed for non-admins.

Assuming that the globalimagelinks table updates quickly enough, this should make the current bots and manual updates[2] unnecessary.

[1] http://en.wikipedia.org/wiki/User:MPUploadBot
[2] http://commons.wikimedia.org/w/index.php?title=User:Zzyzx11/En_main_page&action=history


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz23133.
MZMcBride created this task.Via LegacyApr 10 2010, 4:29 AM
werdna added a comment.Via ConduitApr 16 2010, 3:20 PM

This is a shitty implementation, surely we can come up with something better.

MZMcBride added a comment.Via ConduitApr 16 2010, 3:25 PM

(In reply to comment #1)

This is a shitty implementation, surely we can come up with something better.

Not helpful. Explain _why_ this is shitty.

bzimport added a comment.Via ConduitApr 17 2010, 8:58 AM

Bryan.TongMinh wrote:

(In reply to comment #1)

This is a shitty implementation, surely we can come up with something better.

Absolutely. I was thinking of a special page where you enter a wiki and a page title and then have all images on that page automatically protected. I even have some code... on my laptop.

Peachey88 added a comment.Via ConduitApr 17 2010, 9:53 AM

Your opening post discusses two things:

  • Issue One: Files being used from commons on a project main page and then applying protection to them.
  • Issue Two: Files being used from local projects on their main pages and no commons file existing. ---
  • Issue One: We already have file protection, you just need to ask someone at the project to do it, what would you prefer a solution where you can protect files remotely from another wiki?
  • Issue Two: When there is a local file and remote file, the local one already takes precedent and is displayed, so what is the issue there?
bzimport added a comment.Via ConduitApr 17 2010, 11:53 AM

Bryan.TongMinh wrote:

I don't think the bug report refers to being able to protect remote image from a local wiki.

The request is to have a feature, using which Commons admins can protect files that are embedded on a certain remote page.

MZMcBride added a comment.Via ConduitApr 17 2010, 7:16 PM

(In reply to comment #4)

  • Issue One: We already have file protection, you just need to ask someone at the project to do it, what would you prefer a solution where you can protect files remotely from another wiki?

Dynamic content, like a Main Page's "In the news" section, makes this process very error-prone. The people updating the content need to always remember to ask someone on Commons to protect the image there, or they implement bad hacks like uploading the image locally and protecting it with a bot.

There should be a way to have this seamless protection of the images. The original idea here is to prevent re-uploading of Commons images if they're used on designated pages (by checking the global image links table). Though, it seems others might be suggesting variations on this idea or completely different implementations altogether. That's not as important, the end result just needs to be some form of automated protection of this content. Something that doesn't rely on bots or people, something integrated into the software.

  • Issue Two: When there is a local file and remote file, the local one already takes precedent and is displayed, so what is the issue there?

Using content from Commons directly (without uploading locally) leaves a breach in the security of the content. Requiring people to constantly upload locally is a broken hackish workaround.

bzimport added a comment.Via ConduitFeb 11 2011, 7:51 PM

Bryan.TongMinh wrote:

*** Bug 27335 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitFeb 12 2011, 4:58 AM

RSYQFIOJGWZA wrote:

(In reply to comment #7)

> *** Bug 27335 has been marked as a duplicate of this bug. ***

I added the following text to bug 27335 relevant to this bug:

Summary: Implement technical measures to prevent image vandalism on English Wikipedia Main Page
URL: http://en.wikipedia.org/wiki/Main_Page
The problems are highlighted on

http://commons.wikimedia.org/wiki/Commons:Administrators/Requests/%CE%94 .
Solutions could include: cross-platform cascade protection; technical measures
to prevent commits of edits to that page if any of the included images are not
protected with edit=sysop and move=sysop or are not on English Wikipedia;
technical measures to prevent display of any of the included images which are
not protected with edit=sysop and move=sysop or are not on English Wikipedia;
creation of a new right to edit that page; etc.

Currently, the only vandalism by non-admins that can happen there (the English

Wikipedia Main Page http://en.wikipedia.org/wiki/Main_Page ) is through images ... An unprotected image from Commons is used: a vandal uploads a replacement
image on Commons. ... that page "has been viewed
167010381 times in the last 30 days." (an average of over 5.5 million hits per
day) per http://stats.grok.se/en/latest/Main_Page .
Another suggested solution on that request page is creating a new user group "Protectors" on Commons with right "Change protection levels and edit protected pages (protect)" to allow a non-admin bot (or one or more humans in case of bot failure) to apply the protection on Commons.

bzimport added a comment.Via ConduitFeb 12 2011, 7:33 PM

RSYQFIOJGWZA wrote:

This bug relates to bug 18483, which shows that cascade protection, as currently implemented on English Wikipedia, is too slow to immediately protect local images placed on the Main Page because it uses the job queue.

werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:45 PM

Add Comment