Image cascading protection issues
Closed, DeclinedPublic

Description

Author: royal_broil

Description:
Since before March 22, images on the main page for the English Wikipedia are not automatically getting protected by cascading protection. The "Did You Know" admins like myself know to protect all images, but other images on the main page have been vandalized. Discussions can be found at:

http://en.wikipedia.org/wiki/Wikipedia:ERRORS#Protection
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_58#Main_page_cascading_protection_not_working


Version: unspecified
Severity: minor
URL: http://en.wikipedia.org/

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz18483.
bzimport created this task.Via LegacyApr 16 2009, 1:29 AM
bzimport added a comment.Via ConduitApr 16 2009, 1:39 AM

Prodego wrote:

Most likely because they are on commons.

werdna added a comment.Via ConduitApr 16 2009, 1:42 AM

Updated summary

bzimport added a comment.Via ConduitApr 16 2009, 3:38 AM

royal_broil wrote:

Commons images have always a problem, that's why a temporary local copy is downloaded from Commons. The problem is with unprotected images that reside on the English Wikipedia. Here's the deleted history from an image that was vandalized while on the main page: http://en.wikipedia.org/wiki/Special:Undelete/File:Lyon0002soft.JPG (admin powers on English Wikipedia needed to view). The vandalism happened from vandal editor The O o . For a long time, all images on the English Wikipedia were automatically protected by cascading protection. Now it's not working anymore. I've tested it myself. The typical all-pink screen for a protected image doesn't come up anymore after the image gets placed on the main page. Non-admin DYK helper Shubinator tested another image here and found no protection: http://en.wikipedia.org/wiki/Special:Undelete/File:Sloat_House,_Sloatsburg,_NY.jpg . This is a serious problem that needs to be addressed. Royalbroil

werdna added a comment.Via ConduitApr 16 2009, 3:54 AM

(In reply to comment #3)

Commons images have always a problem, that's why a temporary local copy is
downloaded from Commons. The problem is with unprotected images that reside on
the English Wikipedia. Here's the deleted history from an image that was
vandalized while on the main page:
http://en.wikipedia.org/wiki/Special:Undelete/File:Lyon0002soft.JPG (admin
powers on English Wikipedia needed to view). The vandalism happened from vandal
editor The O o . For a long time, all images on the English Wikipedia were
automatically protected by cascading protection. Now it's not working anymore.
I've tested it myself. The typical all-pink screen for a protected image
doesn't come up anymore after the image gets placed on the main page. Non-admin
DYK helper Shubinator tested another image here and found no protection:
http://en.wikipedia.org/wiki/Special:Undelete/File:Sloat_House,_Sloatsburg,_NY.jpg
. This is a serious problem that needs to be addressed. Royalbroil

WFM at http://test.wikipedia.org/w/index.php?title=File:Testimage.png&action=edit

bzimport added a comment.Via ConduitApr 16 2009, 4:03 AM

royal_broil wrote:

You have changed the description to describe a different problem than what I'm reporting. I concern is LOCAL images on the English Wikipedia that should be automatically protected by cascading protection while on the main page but are not being protected. Admins like myself are having to manually protect them so that they don't get vandalized. Protecting images on the Commons shared image repository protection is NOT the issue that I'm bringing up. That's a separate problem that would be a helpful improvement, but it's beyond the scope of the bug that I've brought up. Cascading protection worked back in January, I don't know what changed so that it doesn't work anymore.

werdna added a comment.Via ConduitApr 16 2009, 4:08 AM

(In reply to comment #5)

You have changed the description to describe a different problem than what I'm
reporting. I concern is LOCAL images on the English Wikipedia that should be
automatically protected by cascading protection while on the main page but are
not being protected. Admins like myself are having to manually protect them so
that they don't get vandalized. Protecting images on the Commons shared image
repository protection is NOT the issue that I'm bringing up. That's a separate
problem that would be a helpful improvement, but it's beyond the scope of the
bug that I've brought up. Cascading protection worked back in January, I don't
know what changed so that it doesn't work anymore.

That's what I'm telling you, though. Local cascading protection *is* working, and I haven't seen a scrap of evidence to the contrary.

See
http://en.wikipedia.org/w/index.php?title=File:Example.jpg&action=edit, an image that is clearly protected by cascading protection. See also these images on the main page, which are protected using cascading protection and it's working (but two of which have not been reuploaded to English Wikipedia, and are therefore vulnerable to vandalism:

http://en.wikipedia.org/w/index.php?title=File:Niobium_crystals_1.jpg&action=edit
http://en.wikipedia.org/w/index.php?title=File:Po%C5%BCar_w_Kamieniu_Pomorskim_13.04.2009_16_cropped.jpg&action=edit
http://en.wikipedia.org/w/index.php?title=File:FillmoreHouse.jpg&action=edit
http://en.wikipedia.org/w/index.php?title=File:Harriet_quimby.jpg&action=edit
http://en.wikipedia.org/w/index.php?title=File:Darnley_stage_3.jpg&action=edit

bzimport added a comment.Via ConduitApr 16 2009, 4:24 AM

royal_broil wrote:

Of those images, only File:Darnley stage 3.jpg is actually protected by cascading protection! Two of the images were manually protected. The other two images are Commons images that are not protected (SHAME - that's scary!). Otherwise, is there a delay before cascading protection takes over? Several months ago there used to be no delay. I've tested several images after I've updated the DYK template, and I've theoretically always been able to vandalize the image immediately after I've updated the Did You Know DYK template and purged the main page cache.

werdna added a comment.Via ConduitApr 16 2009, 4:27 AM

(In reply to comment #7)

Of those images, only File:Darnley stage 3.jpg is actually protected by
cascading protection! Two of the images were manually protected. The other two
images are Commons images that are not protected (SHAME - that's scary!).
Otherwise, is there a delay before cascading protection takes over? Several
months ago there used to be no delay. I've tested several images after I've
updated the DYK template, and I've theoretically always been able to vandalize
the image immediately after I've updated the Did You Know DYK template and
purged the main page cache.

I think it's on your end. For me, I get the following:

Editing File:Niobium crystals 1.jpg

WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy.
  • Wikipedia:Main Page/1
  • Wikipedia:Main Page/2
  • Wikipedia:Main Page/3
  • Wikipedia:Main Page/4
  • Wikipedia:Main Page/5
  • Main Page
  • Wikipedia:Main Page/Protection

Editing File:Pożar w Kamieniu Pomorskim 13.04.2009 16 cropped.jpg

WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy.
  • Wikipedia:Main Page/Tomorrow
  • Wikipedia:Main Page/1
  • Wikipedia:Main Page/2
  • Wikipedia:Main Page/3
  • Wikipedia:Main Page/4
  • Wikipedia:Main Page/5
  • Main Page

Editing File:FillmoreHouse.jpg

WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy.
  • Wikipedia:Main Page/1
  • Wikipedia:Main Page/2
  • Wikipedia:Main Page/3
  • Wikipedia:Main Page/4
  • Wikipedia:Main Page/5
  • Main Page

Editing File:Harriet quimby.jpg

WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy.
  • Wikipedia:Main Page/1
  • Wikipedia:Main Page/2
  • Wikipedia:Main Page/3
  • Wikipedia:Main Page/4
  • Wikipedia:Main Page/5
  • Main Page

Editing File:Darnley stage 3.jpg

WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy.
  • Wikipedia:Main Page/1
  • Wikipedia:Main Page/2
  • Wikipedia:Main Page/3
  • Wikipedia:Main Page/4
  • Wikipedia:Main Page/5
  • Main Page
bzimport added a comment.Via ConduitApr 16 2009, 11:49 AM

royal_broil wrote:

You are correct - it appears that the problem is sporadic. Even a sporadic problem of this magnitude needs to be addressed. There have been some problems, as I have indicated above. I have started a thread asking the Did You Know people to test this problem and leave messages here. I don't know how many have access to Bugzilla. Anyhow, you can follow the thread here:

http://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Sporadic_problems_with_cascading_protection_on_main_page_images

bzimport added a comment.Via ConduitApr 16 2009, 2:38 PM

Prodego wrote:

Perhaps too obvious, but... You did clear your browser cache, right?

Lejonel added a comment.Via ConduitApr 16 2009, 11:07 PM

Can this have to do with the job queue? Depending on the length of the job queue it takes some time before the link tables are updated after a template is changed. And before the image links from the main page are updated in the imagelink table, the cascade protection protects the "old image" instead of the "current image".

bzimport added a comment.Via ConduitApr 17 2009, 2:24 AM

royal_broil wrote:

Lejonel, that makes sense. I've noticed that it often takes tens of minutes for the links to the previous image to be released. I've already deleted an image that exists as the temporary local English Wikipedia image from the main page, just to find the the MPUploadbot has uploaded this same old image back because it thought that the old image was still on the main page. Can you change the priority of the task in the job queue so that it updates the imagelink table within a few seconds instead of tens of minutes?

bzimport added a comment.Via ConduitApr 18 2009, 10:41 AM

royal_broil wrote:

5 minutes ago I posted an update to Did You Know, and I left the local image unprotected. I put up a template to make it look like it's protected. It's still not protected. The image is http://en.wikipedia.org/wiki/File:Hmserebus1826.jpg . See for yourself. You can edit the image.

bzimport added a comment.Via ConduitApr 18 2009, 10:57 AM

royal_broil wrote:

I used my alternative non-admin account to successfully do a null edit 22 minutes after inserting on main page http://en.wikipedia.org/w/index.php?title=File:Hmserebus1826.jpg&diff=284594901&oldid=284593053 .

bzimport added a comment.Via ConduitApr 18 2009, 11:23 AM

royal_broil wrote:

I asked a trustworthy non-admin make another null edit 40 minutes later to test to see if it's my browser cache, RFD had no problems! This edit could have been someone uploading a picture of their penis! http://en.wikipedia.org/w/index.php?title=File:Hmserebus1826.jpg&diff=284596826&oldid=284594901

bzimport added a comment.Via ConduitApr 18 2009, 12:38 PM

royal_broil wrote:

Still not protected, 2 hours later

werdna added a comment.Via ConduitApr 18 2009, 12:56 PM

(In reply to comment #16)

Still not protected, 2 hours later

There isn't a need for a running commentary. It is known that cascading protection takes a while to take effect due to deferred updates. I was under the impression that we solved this by having a 24-hour buffer for it to take effect, by virtue of [[Wikipedia:Main Page/Tomorrow]].

If this isn't working with "Did You Know?", then I would recommend manual protection.

Peachey88 added a comment.Via ConduitApr 18 2009, 1:00 PM

(In reply to comment #16)

Still not protected, 2 hours later

The file is protected, just the edit tab isn't changing to "View Source", it chucks up the following error message saying it is protected when you try to save:

This page is currently protected from editing because it is transcluded in the following page, which is protected with the "cascading" option:

  • Main Page
bzimport added a comment.Via ConduitApr 18 2009, 1:52 PM

royal_broil wrote:

The Tomorrow template includes only the current version of Did You Know, it gets manually updated every 6 hours or so. The tomorrow solution sounds like it works for Picture of the Day and Today's Featured Article. Tomorrow explains why only Did You Know and In the News images have been vandalized. I don't have any suggestions for In the News, but I do have one for Did You Know. There are 6 staging queues where hooks and images get placed by administrators before they appear on the main page. They could be placed under a template with cascading protection, similar to Tommorrow. There's still the problem of In the News.

What fixed the problem? The image hadn't been protected at 2 hours, I cleared my browser cache and the page's cache before clicking edit on the image and it wasn't protected - the error message that p858snake mentioned wasn't there until after your posts. I didn't trust the "view source" tab. Did you clear the main page cache, Andrew? If so, I wonder, could a task be set up on a server to clear the main page cache every minute? Would that result in a performance hit, or would a single minor task like that result in a negligible performance degradation? Even a documented 40 minutes of having an unprotected image on the main page of the English Wikipedia is too scary for me.

Sorry to be a pain. I was hoping that this unannounced and unadvertised test would help solve the bug. This can wait until after the weekend.

werdna added a comment.Via ConduitApr 18 2009, 1:54 PM

(In reply to comment #19)

What fixed the problem? The image hadn't been protected at 2 hours, I cleared
my browser cache and the page's cache before clicking edit on the image and it
wasn't protected - the error message that p858snake mentioned wasn't there
until after your posts. I didn't trust the "view source" tab. Did you clear the
main page cache, Andrew? If so, I wonder, could a task be set up on a server to
clear the main page cache every minute? Would that result in a performance hit,
or would a single minor task like that result in a negligible performance
degradation? Even a documented 40 minutes of having an unprotected image on the
main page of the English Wikipedia is too scary for me.

Just time, the deferred updates got through.

Sorry to be a pain. I was hoping that this unannounced and unadvertised test
would help solve the bug. This can wait until after the weekend.

No problem.

bzimport added a comment.Via ConduitApr 21 2009, 9:39 PM

shubinator1 wrote:

Would it be possible to update the link tables when the template is purged?
-Shubinator (for the record, the same Shubinator that Royalbroil mentioned)

bzimport added a comment.Via ConduitApr 22 2009, 3:42 PM

gdonato wrote:

reverted summary since bug changed focus again to original issue

bzimport added a comment.Via ConduitMay 1 2009, 3:59 PM

happy.melon.wiki wrote:

It seems that the issue is that the linktable updates that trigger cascading protection run through the job queue and are thus potentially delayed if the job queue is long. The solution, therefore, is to ensure that the templatelinks and imagelinks tables are updated quickly after a cascade-protected page is updated.

IIRC someone (Tim?) is working on an improved job queue construction; as suggested in comment#12, a 'priority stream' should be considered in that system. In the meantime (and perhaps even regardless), it would seem to be sensible to update these tables *immediately* as part of the page save, if the page is cascade-protected. Since only admins can save cascade-protected pages, this whould not be a DoS vector.

bzimport added a comment.Via ConduitJul 4 2009, 3:02 PM

shubinator1 wrote:

Is there any progress on the bug? Happymelon's suggestion seems perfect.
As I understand it, saving the page updates the link tables for only that page. For cascading protection, this means admins have to null edit (purge doesn't work) the Main Page. We could extend this so if (cascade protected) -> update link tables of that page -> propagate link table updates upwards in the chain of cascading protection. So in our example, updating Template:Did you know would update the link tables of the Main Page, which would trigger cascading protection instantaneously.

werdna added a comment.Via ConduitJul 5 2009, 7:19 PM

(In reply to comment #23)

It seems that the issue is that the linktable updates that trigger cascading
protection run through the job queue and are thus potentially delayed if the
job queue is long. The solution, therefore, is to ensure that the
templatelinks and imagelinks tables are updated quickly after a
cascade-protected page is updated.

IIRC someone (Tim?) is working on an improved job queue construction; as
suggested in comment#12, a 'priority stream' should be considered in that
system. In the meantime (and perhaps even regardless), it would seem to be
sensible to update these tables *immediately* as part of the page save, if the
page is cascade-protected. Since only admins can save cascade-protected pages,
this whould not be a DoS vector.

Requires serious rearchitecture, which is not justified by a minor problem for which a basic workaround exists.

bzimport added a comment.Via ConduitJul 16 2011, 2:25 AM

EN.WP.ST47 wrote:

Cascading protection takes time to take effect. Updating the bug summary to that effect, and since we know that, and per Andrew, a very simple workaround exists, this is going to be WONTFIX.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.