Last modified: 2011-06-13 17:42:57 UTC
I just noticed that if I copy/paste the following to the address bar of my browser the ArticleFeedback form is loaded and I can submit the feedback even for pages where the extension is not enabled: javascript:mw.loader.load( 'ext.articleFeedback' );void 0; Shouldn't the extension check if it is enabled before accepting the submitted data?
The detection is done in ext.articleFeedback.startup. You can do lots of things with JavaScript hacking, this is not a situation where it really matters to prevent people from enabling ArticleFeedback on pages themselves, so there's no need to lock it down harder. If you were to use javascript:mw.loader.load( 'ext.articleFeedback.startup' );void 0; It would load a lightweight detection and bootstrapping script, that may or may not proceed to load ext.articleFeedback.
What if people starts to target the user (talk) page of some editor and use the ArticleFeedback tool for vandalizing it? I think it could be problematic, since there are plans[1] to let readers to provide also free-text comments about the page. [1] https://secure.wikimedia.org/wikipedia/mediawiki/w/index.php?title=Article_feedback#Current_Plan_.28May_2011.29
(In reply to comment #2) > What if people starts to target the user (talk) page of some editor and use the > ArticleFeedback tool for vandalizing it? > How would you use ratings to vandalize anything? > I think it could be problematic, since there are plans[1] to let readers to > provide also free-text comments about the page. > Even if AFT allows you to submit text in addition to numerical ratings, the widget is still hidden for normal users on pages where it's not supposed to be active. The vandalism would only be visible to people that used the same trick to make the AFT widget visible on pages where it's not supposed to show up. I guess a fitting real-life analogy would be vandalizing a billboard using invisible ink.
Well... People could "rate a user" massively ([[Cyber-bullying]]?) as not being "Trustworthy" so that its name is displayed in (automatically generated) special pages such as https://secure.wikimedia.org/wikipedia/en/wiki/Special:ArticleFeedback https://secure.wikimedia.org/wikibooks/pt/w/index.php?title=Especial%3ARatedPages&ratingtier=1&namespace=0&ratingtag=reliability&uselang=en and others which could be created in the future... I think such pages could make these unwanted ratings to become visible, and considering that the ratings in the userpage are not visible to "normal" users, after a large amount of bad ratings is achieved, it would be difficult to revert.
You're suggesting we implement a check similar to the one in the .startup module on the server-side when saving the rating ? Sounds valid, albeit an edge case, does sound sane. Reopening.
(In reply to comment #4) > Well... People could "rate a user" massively ([[Cyber-bullying]]?) as not being > "Trustworthy" so that its name is displayed in (automatically generated) > special pages such as > https://secure.wikimedia.org/wikipedia/en/wiki/Special:ArticleFeedback > https://secure.wikimedia.org/wikibooks/pt/w/index.php?title=Especial%3ARatedPages&ratingtier=1&namespace=0&ratingtag=reliability&uselang=en > and others which could be created in the future... > > I think such pages could make these unwanted ratings to become visible, and > considering that the ratings in the userpage are not visible to "normal" users, > after a large amount of bad ratings is achieved, it would be difficult to > revert. That's correct, afaik rating in any namespace (including but not limited to the User namespace) is currently possible when manually loading the module.
I'll see if I can get around this in the weekend. Assigning to myself.
(In reply to comment #5) > You're suggesting we implement a check similar to the one in the .startup > module on the server-side when saving the rating ? Yep! (But I focused on the problem and forgot to mention this explicitly) Maybe the whole ext.articleFeedback.startup.js module could be implemented server side. This way, no JS code from the extension would be sent to the readers on pages where the extension is not enabled, such as https://secure.wikimedia.org/wikipedia/en/wiki/Trzebucza?debug=1 > Sounds valid, albeit an edge case, does sound sane. > > Reopening. (In reply to comment #7) > I'll see if I can get around this in the weekend. Assigning to myself. Thanks!
(In reply to comment #8) > (In reply to comment #5) > > You're suggesting we implement a check similar to the one in the .startup > > module on the server-side when saving the rating ? > > Yep! (But I focused on the problem and forgot to mention this explicitly) > Maybe the whole ext.articleFeedback.startup.js module could be implemented > server side. This way, no JS code from the extension would be sent to the > readers on pages where the extension is not enabled, such as > https://secure.wikimedia.org/wikipedia/en/wiki/Trzebucza?debug=1 > No, we can't do that, because server-side output is Squid-cached, and we want to be able to change the settings for randomly showing the widget (we call this the 'lottery') quickly.
Fixed in r89982.
