Talk:Personal image filter/LQT Archive 1

Name
Brandon raised a good point about the name, saying that "Controversial content management system" could be read as "Controversial content management system". To avoid the ambiguity with a CMS, what about "Controversial content hiding system"? guillom 07:21, 1 March 2011 (UTC)
 * I like "obfuscation" better than "hiding"; I'm not sure "system" is needed at all. --MZMcBride 19:14, 1 March 2011 (UTC)
 * I don't think "obfuscation" is a good term. "Controversial Content Display Behavior System" is probably best and most accurate.--Jorm (WMF) 19:15, 1 March 2011 (UTC)
 * Obfuscation cracks me up. I would actually like to get away from the term "controversial content" in general; it's a useful shorthand but also has pejorative connotations. Image hiding system? -- Phoebe 05:15, 4 March 2011 (UTC)
 * I'm thinking of going with "Personal image filter". It seems to me this is really what the feature allows: to empower the user to enable or disable filters, according to their preference, to hide images or not. guillom 09:18, 4 March 2011 (UTC)
 * It's applicable to videos as well. That may not be a good enough reason to rename the project, but it's something to bear in mind in user interfaces and such.--Eloquence 22:16, 16 March 2011 (UTC)
 * I think "Personal Media Filter" is probably best.--Jorm (WMF) 00:32, 18 March 2011 (UTC)
 * I also like "Personal Media Filter" because of its emphasis on individual users - and their choices.Bishdatta 06:24, 21 March 2011 (UTC)
 * I think "image" is more understandable than "media", even if not totally accurate, but I won't oppose renaming from "Personal image filter" to "Personal media filter". guillom 08:25, 21 March 2011 (UTC)
 * Remember the target for this feature, more than most, includes a large proportion of non-computer minded and non-technical people. Keep it extremely simple. "Content options" is all that's needed, and keeps it open-ended. "Options" are widely understood to apply just to your own access or use and this is simple, intuitive, helpful, and doesn't imply anything related to censorship or other "filters". FT2 (Talk 03:55, 22 March 2011 (UTC)
 * The name of the extension is not user-facing. The internal terminology doesn't need to be user-friendly; just accurate.  Since the technology is personal, involves filters, and is applicable to media files, "Personal Media Filter" seems right to me.  Also, "P.I.F." is a used, albeit archaic, acronym in computers: PIF files are Program Information Files, used by older versions of Microsoft Windows.--Jorm (WMF) 05:23, 22 March 2011 (UTC)
 * Hello, the name should be simple and link to the already used terms. So if the user has to click on "Display settings", why not call it "Display system" or "Image display system"? --Ziko 19:12, 30 June 2011 (UTC)
 * The name of the extension is not user-facing. The internal terminology doesn't need to be user-friendly; just accurate.  Since the technology is personal, involves filters, and is applicable to media files, "Personal Media Filter" seems right to me.  Also, "P.I.F." is a used, albeit archaic, acronym in computers: PIF files are Program Information Files, used by older versions of Microsoft Windows.--Jorm (WMF) 05:23, 22 March 2011 (UTC)
 * Hello, the name should be simple and link to the already used terms. So if the user has to click on "Display settings", why not call it "Display system" or "Image display system"? --Ziko 19:12, 30 June 2011 (UTC)

Objections
This is way more restrictive than would be acceptable in at least the part of the enWP community with which I am familiar. First, I do not think the entire project acceptable as a matter of principle. We have the obligation to create properly descriptive metadata for material; we have the obligation to aggregate the descriptors in logical and useful ways. We recognize that these descriptors can and will be used by outside parties to filter our material according to their own purposes, but the possible misuse of the descriptors should no more prevent their making than the possible misuse of any other content prevents it. We probably even have the obligation not to construct our system in such way as to frustrate this use (we do not judge the virtue of a type of use), and possibly even to give links to the various systems available for those who want to use them. (we provide information to help our users make use of the material in whatever way they want to).

But for the WMF itself to make such filters is a gross abuse and contradiction to our principles. Our business is the provision of information, not its restriction. We do not censor, except as we are compelled to. Therefore, we do not make filters for censoring. We do not implement filters others may make. We do not make categories designed specifically to facilitate censoring that we would not make otherwise.

I shall do what I can to urge the community to reject this entire proposal. My idea of the proper objectionable content policy is just two provisions: 1.we do not host material that is illegal according to the governing law where our servers are located. 2.we do not force any project to include material it does not want to include, but they must adopt a policy as close to NOT CENSORED as their principal readers and editor communities permit.

The most objectionable part
The most objectionable part is the default filter. Even were we to have this project, there is one default filter setting and one only that is consonant with the principles of NOT CENSORED -- that is "Allow everything". Otherwise we are censoring in the sense of segregating material in a private back room.

The second most objectionable part
The second most objectionable part is to compel the different Wikipedias to implement the necessary overhead for this policy. If the policy is thought necessary for some culture areas, a position I disagree with very strongly but can image the WMF adopting, that still does not give those areas the right to impose their standards on others, or to compel them to participate in a project against their own mores. In other words, if the xxWP decides to use such categories, the enWP does not have to provide equivalents of them. In such a case, what to do with Commons is a difficult question, but I would still say the Commons should not use it. The various WPs can use such images from commons as they choose, and not use others. (I believe this is already the case with respect to copyright, and even the enWP has long required permission to use certain particularly provocative images.)  DGG 23:01, 19 March 2011 (UTC)


 * Hi DGG, Thanks for your thoughts.

-- Phoebe 23:15, 19 March 2011 (UTC)
 * 1) There's no default filter; default is the status quo. (I think the spec says it could be possible to make a default if wikis wanted to, but most of this spec is about how to enable readers to filter images only for themselves, in which case the default for the whole project stays the same).
 * 2) You're objecting to people hiding images *for themselves* (not for others?) I think the system described is so readers can make their own choices about what to see. Editorial policy remains the same, of course.

I'm certainly glad to hear that no default use is intended. I'm certainly in favor of Wikipedia users being able to choose by themselves what to see, but I'm not in favor of Wikipedia of having the WMF produce anything that might be seen as a concession to censorship--next thing, we'll have proposals like the default settings. I would certainly prefer that such a function be implemented as a variety of available add-on products through which one reaches Wikipedia--and produced by someone else. Unfortunately, I'm aware this might not be the simplest solution  I find the present concentration on sexuality a little absurd--of all articles, these are the least likely to be found  by people who are not looking for them. I'd suggest we want to enable people to be more selective in a variety of ways, not limited to "controversial" content, and not putting undue focus on sexuality or violence: we might have a page that would be labelled something like Image Selection that would present optional selection buttons   to not immediately show :

a. all images--replace them by the alt text unless clicked on. This would of course be the safest setting, and quite independently of that, be the best for low speed connections. (I have set such an option for a number of sites I look at in order to get them to work quicker without the background nonsense. It can obviously be done on the browser side, but many of our users won't know how do do this)

b. all images over a certain size. Again, for lower speed connections. Ideally, we'd have images served at a default resolution depending on the connection, like commercial sites often do.

c. images showing humans

d. images showing violence towards humans

e. images dealing with sexually related subjects

f. images dealing with medically related subjects

g. images dealing with religiously-related subjects

h. images of political emblems

I can't think how to deal with unclothed humans. Some might not want any that show even the faces, or not show the faces of those of a particular gender. Some might not want pictures that show the sexually charged parts of the body--but I cannot find a culture-free definition of that. Some might not want images that show such parts even if clothed, or it might depend upon the nature of the clothing. Most available commercial filters are designed for a particular cultural sensitivity in mind--typically the images that an middle-aged very socially conservative American does not want young teen-agers to see. I don't see how we can make this determination of a world-wide basis.

It's a tricky question whether this would work without being implemented for all Wikipedias. If it were limited to Commons content, but the same interface shown to everyone, then a person using, say, the English Wikipedia and selecting option d. would still see the images of violence hosted on enWP, but not those hosted on Commons. But to use ity on each WP would require some Wikipedias to use e a particular form of metadata for their content they do not find helpful. But if it could be used on an interface specific to each WP, the way the language is localized, then it would not matter. Any particular WP could choose not to use it, or to use it, in which case, they would need to code their own images, if any, and then it would affect all images they display on their WP. (I'm assuming no particular Wikipedia directly uses images from another Wikipedia). DGG 15:48, 20 March 2011 (UTC)

Why create a new category system for this?
Hello, I am confused about this part:


 * ''Because of the way categories work (or don't work, as the case may be), this system will only work:
 * if it has to deal with a limited number of categories -- somewhere between 5-10 -- which are placed into a global content filter category

Can you please explain in detail why this is needed? I understand that the proposed implementation involves cache invalidation. What is the imagined bottleneck if users are able to tag any set of categories to filter (along with their subcategories)? What is the 'category-checking' function that would be made more efficient by having only 10 new categories? Notsuohs 17:57, 21 March 2011 (UTC)
 * It is not a question of "new" or "old" categories; it is a question of the number of categories:
 * For every category that is filterable, the cache invalidation load grows.
 * Since this feature is designed to work for anonymous users, there is a hard limit of around 15 categories that we could possibly filter (we run up against the cookie limit).
 * There are also significant usability concerns. The feature is designed to be used by people who don't know what categories even are, let alone how to use them.  With a small category set, we can allow filtering from the perspective of the images; with a large set, we will be required to do filtering from the perspective of the category.  Since categories are an esoteric part of MediaWiki (from an inexperienced user's point of view), we have to go with the "image" perspective.
 * Hope that answers your question.--Jorm (WMF) 19:33, 21 March 2011 (UTC)
 * Why a hard limit? Surely MW can store all categories in one cookie. For example a 15 character string of "1"s and "0"s. (This isn't to deny caching issues or suggest it's desirable, just curious why it's a hard limit) FT2 (Talk 03:50, 22 March 2011 (UTC)
 * How does the cookie limit require only providing 10 options in the first place? You could let people choose the first N categories they want to filter, then say "if you want to use this feature more fully, please log in to an account".  That's a bog-standard way of inviting heavy users to create accounts on complex sites.  This "create a classification scheme" seems like the obvious weak point in what otherwise seems a workable scheme.  I can't see any way to implement it that isn't at once flawed and controversial in its own right.  Please fix this.  Notsuohs 03:02, 1 July 2011 (UTC)

New category system fail
Please use the existing category system. Any categories which are not already needed to describe [images, articles] do not belong on the projects. Filter by category, not by image. Thank you.
 * For instance: when loading an image for the first time, get both the image and its list of categories, run a string match in the client against the list of reader's 'disliked categories', and decide whether or not to show. the wikimedia cache system could start caching all category data along with image/thumbnail data. Why would that be hard?  Notsuohs

Interface comments
As the technical side seems to have been carefully considered, a few UI comments only:


 * 1)  As "allowed" is green, so make "denied" a light red. More visually intuitive.
 * 2)  The message "changed" could be ambiguous. It might be better to explicitly state "(was allowed | was denied)"
 * 3)  (also ) "Hide content" would be better as "Content options". The term "Hide content" may convey an expectation or impression that more hiding options exist than is the case (text? specific images?) or that censorship is now endorsed, and comes across a bit badly too. Retitling as "Content options" does not suggest censorship nor does it imply a wider level of control that we really offer. "Options" is a very widely understood term.
 * 4)  (also ) Not very useful. The initial text one hovers over says that this image can be hidden (or content options exist). It doesn't help to list the categories this image is in, as a hover item. If they proceed it will be displayed anyway. A better use for hover would be a short explanation - "Click here to show or hide this image and others like it."
 * 5)  (also ) This style is very unnecessarily confusing. The real issue is that some filters are listed separately, as "additional filters" (additional? User confusion!). It needs to be simple to the point of cluelessness as its target is people who may have no computer knowledge at all. In all other screens, the list of categories is not broken up. It would be better if not broken up here, either. A better layout would be a list of categories (as before) plus a textual note "This image can be blocked by denying any of these categories: "

Last, one aspect not considered. Images that are not in a content filter category, but should be. Perhaps all images should have a small icon in the form of a hanging or side tab that, when hovered, states something like this:
 * "Content filter / WIKI_NAME can be set to hide certain kinds of content. To view applicable categories and report that this image belongs in one of them or is wrongly categorized, click here [Dialog appears where user can enter a reason and click 'report' or 'cancel']. To set your content filter options click here ."

Also the popups for content that is already filtered should make it easy for a user to report mis-categorization. FT2 03:02, 22 March 2011 (UTC)
 * If there is a message string like that in the system, it has failed imo. It should say things like "WIKI_NAME can hide categories of images you do not wish to see.  To hide this image and others like it, click here".  And on clicking, you would have the option to add categories to the image as well if it hasn't been categorized yet.
 * I see no compelling technical reason to do this with a limited artificial category-set; this should be addressed. Notsuohs 03:07, 1 July 2011 (UTC)