Last modified: 2014-11-19 10:24:01 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 T2982, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 982 - MediaWiki should support ICRA's PICS content labeling
MediaWiki should support ICRA's PICS content labeling
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://icra.org/
: patch, patch-reviewed
Depends on: 998
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 22:39 UTC by Fenenc Foxen
Modified: 2014-11-19 10:24 UTC (History)
16 users (show)

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


Attachments
Basic extension for ICRA (2.51 KB, text/plain)
2004-12-04 12:02 UTC, Zigger
Details
Basic extension for ICRA supporting current OutputPage.php (2.86 KB, text/plain)
2004-12-05 05:05 UTC, Zigger
Details
Basic extension for ICRA supporting current OutputPage.php with GPL (3.69 KB, text/plain)
2004-12-05 11:36 UTC, Zigger
Details

Description Fenenc Foxen 2004-12-02 22:39:49 UTC
The MediaWiki software should support the Internet Content Rating Association's
PICS metadata tags for labeling content.

It may also be desirable to have the ability to restrict these privelleges to a
certain class of users.
Comment 1 Zigger 2004-12-03 00:41:05 UTC
This can be already done at the wiki and probably namespace levels using Apache.
 See http://www.icra.org/faq/professional/#apache
Comment 2 Fenenc Foxen 2004-12-03 01:28:56 UTC
(In reply to comment #1)
> This can be already done at the wiki and probably namespace levels using Apache.
>  See http://www.icra.org/faq/professional/#apache

It still may be desirable to do this on a per-wikipage/per-image or similar basis.
Comment 3 Zigger 2004-12-04 12:02:04 UTC
Created attachment 147 [details]
Basic extension for ICRA

There are a number of things to be resolved with using an ICRA rating, such as
the terms and conditions, and the related consequences, as well as dealing with
linked pages (including the various .js & .css), automatically using the
ratings from images, lack of in-built support in browsers, the
hard-to-understand specification, the relationship with generic ratings (e.g.
site and/or namespace), and a blocking bug (to be set).

Any way, here is an extension which seems to work, when the blocking bug is
patched.  It should be placed in the "extensions" directory, and contains
further instructions.
Comment 4 Zigger 2004-12-05 05:05:54 UTC
Created attachment 151 [details]
Basic extension for ICRA supporting current OutputPage.php
Comment 5 Zigger 2004-12-05 11:36:27 UTC
Created attachment 152 [details]
Basic extension for ICRA supporting current OutputPage.php with GPL
Comment 6 Tim Millard 2006-03-02 17:16:31 UTC
Possibly have a position independent Wikitext tag (like the Category tag). It
would be good if a PICS tag applied to an Image (or other media) article would
propagate to the thumbnail versions of said image.

== See Also ==
[http://en.wikipedia.org/wiki/Platform_for_Internet_Content_Selection PICS]
Comment 7 Brion Vibber 2008-12-30 02:58:56 UTC
Original patch looks like it's not properly escaping output, which is a security problem.

Is there still interest in picking this up?
Comment 8 Happy-melon 2009-07-24 14:09:08 UTC
Stale.
Comment 9 Chad H. 2009-07-24 14:13:18 UTC
I tried to look (In reply to comment #7)
> Original patch looks like it's not properly escaping output, which is a
> security problem.
> 
> Is there still interest in picking this up?
> 

I tried to look into this one about 6 months ago, and it (appeared) at the time that they've moved away from the <meta> keyword and instead use a <link> to an externally generated file detailing the site's content ratings. Not as easy as doing the <meta> was. Would probably be best as an extension at this point.

Reopening, because there's no limit on how long bugs should be open, and REMIND is pretty much unused here anyway.
Comment 10 Derk-Jan Hartman 2010-05-06 00:08:15 UTC
Increasingly MediaWiki Commons is having to deal with a wide range of culturally sensitive issues. Schools around the world are blocking wikipedia and wikimedia due to what some call pornography.

We used to happily ignore any censorship issues other than US law. However the educational reach debate, as well as for instance local legislation (think the recent case about Wolfgang Werlé and Manfred Lauber and how the editorial German community dealt with that), are making it increasingly clear that as any major website, we probably need a better solution, that allows for a more targeted approach.

We could potentially use the ICRA tagging system as suggested before. http://www.fosi.org/icra/. Apparently ICRA is rather widely supported by filters around the world. (Says Tim Starling)

This system would include a head element that lists a link to an RDF generator. That RDF file would include the ICRA rating of the page itself (if we would want that) and the ratings of the images included in the page, setting a rating for those images and blocking their urls by using the hasURI regex of the ICRA system. (http://www.icra.org/vocabulary/ a list of supported labels)

This tagging could be stored in the page_props table. It could be entered either by a magicword, or trough a dedicated interface (with so many labels, that might be useful).

If needed a mediawiki filter system could be developed as well, but that is considerable more work of course. Perhaps there are organizations that would be interested in sponsoring development of such work ?
Comment 11 Robert Rohde 2010-05-06 14:32:45 UTC
It used to be that part of the ICRA use agreement said that a webmaster had to certify that no content was intentionally mislabeled.  

If users are assigning ICRA tags that would create a serious problem since vandals might mislabel content.  (Labeling sex images as good for kids, for example.)  While we could police that like any other vandalism, I don't think our vandal patrol efforts would be good enough to meet their expectations.

That said, I just visited the ICRA site and I wasn't able to find any of the discussion on mislabeling that I remember seeing 3-4 years ago.  So I suppose they might have removed those conditions on use (which would have been hard to enforce anyway).
Comment 12 Tim Starling 2010-05-06 23:58:31 UTC
(In reply to comment #11)
> It used to be that part of the ICRA use agreement said that a webmaster had to
> certify that no content was intentionally mislabeled.  

It seems that we can use the ICRA vocabulary in a linked RDF document without agreeing to any contract with ICRA, and without violating their intellectual property (unless you take a very broad view of what constitutes intellectual property). In particular, we don't have to copy the English descriptions of their tags (we just link to them), and we don't have to show any ICRA logo image.
Comment 13 p858snake 2010-05-07 07:34:50 UTC
(In reply to comment #11)
> It used to be that part of the ICRA use agreement said that a webmaster had to
> certify that no content was intentionally mislabeled.  

If that was required, It could probably be possible via a page (kinda like the protetion page) and then restrict that page based on a user-right [Then have users request on a central page for who ever has the right to tag the image.](1).

How do these schemes work? Do all the images need a rating or just ones that go over a content rating? What about freshly uploaded images that haven't been reviewed yet?(2)

(1) That would really depend on how the rating scheme works I guess since i've never looked into it.
(2) If they all need ratings, Do they have a rating for "un-reviewed" images tgat could be mass applied to the preexisting images and then auto apply to the new uploads?
Comment 14 Derk-Jan Hartman 2010-05-07 14:02:31 UTC
Every page can have it's own RDF file (that is why i talked of a RDF generator, much as we have RSS generators for specific pages). RDF files can have multiple labels for different paths (allowing for instance a rating for the page itself, and different ratings for the images).

As far as I'm able to gather, if content is not reviewed, you should not provide a label at all (there is no label for "safe" content).

But perhaps we should send an email to FOSI, cause I too have some serious questions.
1: How many content filters understand the RDF tags
2: How many of those understand multiple labels and path specific labeling.
3: How many of those cache the RDF file the first time they visit a page on your website, for the ENTIRE website.

All three are common implementation problems that I expect to arise in quick-to-market coding, that would however severely limit the use of the rating system in the context of Wikipedia.

Additionally, I wonder if there is something like a reserved namespace that we could use for our own rating labels. I'm thinking mostly of the Chinese and Muslim communities, where the current ICRA vocabulary doesn't seem to account for.
Comment 15 Derk-Jan Hartman 2010-05-09 02:04:28 UTC
Potential email that I might send to FOSI/ICRA asking for clarification regarding some of the problems I anticipate.

http://commons.wikimedia.org/wiki/User:TheDJ/fosi
Comment 16 Jussi-Ville Heiskanen 2010-05-09 16:12:57 UTC
This has been voted on at least three different times, each time resoundingly rejected by the community, at the very least on English Wikipedia. Don't know how many times it has been rejected in other communities, and I propably missed a few, while using five minutes to briefly comb through the rejected proposals category. I am completely unconvinced there is any argument that if put to the vote, it would again be angrily rebuffed. We just don't roll this way.
Comment 17 Casey Brown 2010-05-09 20:47:01 UTC
(In reply to comment #16)
> This has been voted on at least three different times, each time resoundingly
> rejected by the community, at the very least on English Wikipedia. Don't know
> how many times it has been rejected in other communities, and I propably missed
> a few, while using five minutes to briefly comb through the rejected proposals
> category. I am completely unconvinced there is any argument that if put to the
> vote, it would again be angrily rebuffed. We just don't roll this way.

It doesn't matter what any communities think, this is a bug about developing the MediaWiki *capabilities* to label content, not about enabling that on any specific wikis.
Comment 18 p858snake 2010-05-09 22:59:00 UTC
(In reply to comment #17)
> It doesn't matter what any communities think, this is a bug about developing
> the MediaWiki *capabilities* to label content, not about enabling that on any
> specific wikis.
Or at least have the functionality for it to exist in a working extension.

And theres a differnce between community reactions when its "A extension that can group/categorize images so third party filters can allow W* access" and "OMG they want to enable censorship so readers can only access certain things"
Comment 19 John Du Hart 2011-08-24 15:24:05 UTC
-needs-review per comment 7

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


Navigation
Links