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

(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.

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.

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?

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.

(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.

Bryan.TongMinh wrote:

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

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.

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.