Future of MediaWiki's bad image list (MZMcBride)
Hi.
In the context of https://bugzilla.wikimedia.org/show_bug.cgi?id=14281 ("Suggestion: Rename "Bad image list" to better title"), it occurred to
me
that a bad image list is a specialized (and hackish) feature that
probably
wouldn't be accepted into MediaWiki core today.
I'm wondering if it makes sense to split this feature (a bad image list)
out
into a MediaWiki extension.
If splitting this feature out of MediaWiki core makes sense, I'm
wondering
whether it should be put in its own extension, be part of another
existing
extension (such as Phalanx), or be part of a more generalized behavior control extension.
An alternate approach suggested on the bug would be to use an
AbuseFilter
filter instead of a bad image list (thereby deprecating "MediaWiki:Bad
image
list"). This gets slightly more complicated if you want to also
replicate
the MediaWiki page's exceptions functionality (you can block inline
usage of
an image except on specified approved pages). This exceptions
functionality
may make an _exact_ replica of the bad image list in an AbuseFilter
filter
impossible. That said, the AbuseFilter extension was seemingly designed
for
exactly this type of behavior control and includes handy features such
as
disallowing the edits altogether and logging attempted edits.
Thoughts?
MZMcBride
I would like to see some simplicity to be available to be retained, and not the never-ending complexity of trying to write complex abuse filters. Keeping simple files like "Mediawiki:Bad file list" enables those admins not hacking-literate to be able to add an image and have it locally blocked. That said, I can see value in having a more sophisticated approach to both bad and good lists that we can store in a protected environment like Mediawiki: namespace AND to have both portability and the ability to develop new features.
Is it possible to write AbuseFilter so that it is able to make use of both bad and good lists stored within the MW namespace? I especially like that if we are able to utilise that in the global space. We have had global vandals come along and start spamming or vandalising by the addition of an image, or a singular image with coding. To be able to slow down that process with a global filter, would be excellent.
I would see that a simple AbuseFilter that says inhibit (in whichever flavour) 'this' edit based on finding a filename found in 'Mediawiki:Bad image list' as a base feature would be the simplest response. Default the behaviour to on (for WMF) and it replicates the present case. If wikis wish to then further develop these filters, excellent. I also see that such filter behaviour could allow wikis to battle other forms of vandalism, and one that I know that I have put into bugzilla previously. We had a vandal who was putting sexually explicit pictures on contributors' user and user talk pages. If this wiki was then able to write a filter that basically said block the addition of images to such and such local namespace, from such a such category at Commons, and/or matching such and such keywords from a filelist, rather than have to try and write an abusefilter that had all the series of swear words and references to sexual appendages, BRILLIANT!
Billinghurst
On 25/11/12 13:50, billinghurst wrote:
I would like to see some simplicity to be available to be retained, and not the never-ending complexity of trying to write complex abuse filters.
+1 I think MediaWiki should keep this simple feature, without having to write abuse filters or needing to install specific extensions.
I replied on the bug addressing their specific request.
Is it possible to write AbuseFilter so that it is able to make use of both bad and good lists stored within the MW namespace? I especially like that if we are able to utilise that in the global space. We have had global vandals come along and start spamming or vandalising by the addition of an image, or a singular image with coding. To be able to slow down that process with a global filter, would be excellent.
We could easily use a global bad image list right now. The discussions on meta of "OMG you are censoring usage of this image in all the wikis" could be endless, though. But if people fighting crosswiki vandalism really want it, I'm for it.
I would see that a simple AbuseFilter that says inhibit (in whichever flavour) 'this' edit based on finding a filename found in 'Mediawiki:Bad image list' as a base feature would be the simplest response.
Using lists on MediaWiki NS in AbuseFilter is a good idea.
Default the behaviour to on (for WMF) and it replicates the present case. If wikis wish to then further develop these filters, excellent. I also see that such filter behaviour could allow wikis to battle other forms of vandalism, and one that I know that I have put into bugzilla previously. We had a vandal who was putting sexually explicit pictures on contributors' user and user talk pages. If this wiki was then able to write a filter that basically said block the addition of images to such and such local namespace, from such a such category at Commons, and/or matching such and such keywords from a filelist, rather than have to try and write an abusefilter that had all the series of swear words and references to sexual appendages, BRILLIANT!
The hard part would be to fetch the categories from commons cleanly. But what you propose can be done. Remember however that you will need to list the whole category subtree you want to ban, not just the top one. :)
On 25.11.2012, 22:22 Platonides wrote:
+1 I think MediaWiki should keep this simple feature, without having to write abuse filters or needing to install specific extensions.
+1 to me too. Infinite modularity is bad, and the feature is pretty simple, probably less than 1 kilobyte of code without comments.
Is it possible to write AbuseFilter so that it is able to make use of both bad and good lists stored within the MW namespace? I especially like that if we are able to utilise that in the global space. We have had global vandals come along and start spamming or vandalising by the addition of an image, or a singular image with coding. To be able to slow down that process with a global filter, would be excellent.
AbuseFilter is completely unrelated to this: AF blocks _edits_ while bad images list blocks _content_.
We could easily use a global bad image list right now. The discussions on meta of "OMG you are censoring usage of this image in all the wikis" could be endless, though. But if people fighting crosswiki vandalism really want it, I'm for it.
Local whitelisting does wonders:) Basically, same thing we have with SpamBlackist: I don't think anyone seriously complains is a site gets blacklisted these days.
Max Semenik wrote:
On 25.11.2012, 22:22 Platonides wrote:
+1 I think MediaWiki should keep this simple feature, without having to write abuse filters or needing to install specific extensions.
+1 to me too. Infinite modularity is bad, and the feature is pretty simple, probably less than 1 kilobyte of code without comments.
It'd be interesting if we could get some usage stats of this feature. I don't imagine it's used very much outside of a few big wikis (and even then, wikis such as Wikimedia Commons don't use it all currently). It's a pretty obscure feature.
Is it possible to write AbuseFilter so that it is able to make use of both bad and good lists stored within the MW namespace? I especially like that if we are able to utilise that in the global space. We have had global vandals come along and start spamming or vandalising by the addition of an image, or a singular image with coding. To be able to slow down that process with a global filter, would be excellent.
AbuseFilter is completely unrelated to this: AF blocks _edits_ while bad images list blocks _content_.
AbuseFilter works on more than just edits.
And the behavior here is wrong: allowing submission of an edit that contains a disallowed image without any warning or notice is wrong behavior. As I recall, the behavior used to be that it would still include an inline link to the image if the image were listed on the bad image list. Nowadays, it seems to just ignore the image altogether (not outputting a link or anything). No information to the user about why the image they specified isn't displaying. Not even a link to the image. The image just gets silently swallowed after the edit successfully saves. This is bizarre and wrong.
MZMcBride
wikitech-l@lists.wikimedia.org