Last modified: 2014-10-23 04:43:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25133, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23133 - Write and implement Commons upload blacklist feature for Main Pages and other special pages
Write and implement Commons upload blacklist feature for Main Pages and other...
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 27335 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-10 04:29 UTC by MZMcBride
Modified: 2014-10-23 04:43 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2010-04-10 04:29:29 UTC
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
Comment 1 Andrew Garrett 2010-04-16 15:20:56 UTC
This is a shitty implementation, surely we can come up with something better.
Comment 2 MZMcBride 2010-04-16 15:25:37 UTC
(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.
Comment 3 Bryan Tong Minh 2010-04-17 08:58:11 UTC
(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.
Comment 4 p858snake 2010-04-17 09:53:46 UTC
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?
Comment 5 Bryan Tong Minh 2010-04-17 11:53:46 UTC
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.
Comment 6 MZMcBride 2010-04-17 19:16:07 UTC
(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.
Comment 7 Bryan Tong Minh 2011-02-11 19:51:07 UTC
*** Bug 27335 has been marked as a duplicate of this bug. ***
Comment 8 Jeff G. 2011-02-12 04:58:34 UTC
(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.
Comment 9 Jeff G. 2011-02-12 19:33:01 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links