zigger wrote:

This can be already done at the wiki and probably namespace levels using Apache.
See http://www.icra.org/faq/professional/#apache

fennec wrote:

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

zigger wrote:

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.

attachment ICRAPICS.php ignored as obsolete

zigger wrote:

Basic extension for ICRA supporting current OutputPage.php

attachment ICRAPICS.php ignored as obsolete

zigger wrote:

Basic extension for ICRA supporting current OutputPage.php with GPL

Attached:

millardster wrote:

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]

Original patch looks like it's not properly escaping output, which is a security problem.

Is there still interest in picking this up?

happy.melon.wiki wrote:

Stale.

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.

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 ?

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

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

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

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.

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

cimon_avaro wrote:

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.

bugs wrote:

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

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

john wrote:

-needs-review per comment 7

So, the ICRA hasn't existed in nearly a decade and the PICS is also no longer a thing, though its successor POWDER appears still to be an active W3C set of standards... of approximately the same usefulness as generically describing the images in RDF (since it is not obvious to me that any vendors have implemented to the use cases described by that standard), which is what StructuredDataOnCommons is going to do for files.

I'd guess today that most parental control or content filtering is done by lists provided by services on the web. There is also the Firefox parental control policy for prefer:safe that Mozilla is trying to send through the IETF (see announcement).

Is this request still useful in the specific implementation requested? Is the task still useful as a placeholder for supporting this kind of service? (I know there has been chatter on en.wp if nowhere else about a gadget that a user could install to avoid undesirable content.)

There's a lot of stuff in https://lists.wikimedia.org/pipermail/foundation-l/2010-May/thread.html from what looks to have been a significant discussion on the topic. General tone seemed to be "nope, we're not interested in categorizing content directly for the purposes of censorship/content filtering".

I kind of think we should just decline this task at this time.