If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

API issues for pornographic image detector extensions

NEW
Unassigned

Status

Core Graveyard
Image: Painting
--
enhancement
14 years ago
8 years ago

People

(Reporter: Josh Heidenreich, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031014
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20031014

There should be some code which can 'look' at a image and determine wether its
pornographic. Then there could be an option in the prefrences to turn them off.
If you turn them off, there should be an option for a password to view them (to
stop 15 year old boys going where they shouldn't be)
The code could look at the colours in the image and decide based on two
palettes: 'skin' and 'pink flesh'. if it sees some pixels neer each other which
are 'skin' pixels and 'flesh' pixels, then it ditches the image.

Reproducible: Always

Steps to Reproduce:
1. type 'porn' into google (www.google.com)
2. press 'submit'
3. click the first link in the search results
4. wait while the page downloads
Actual Results:  
I would expect that you would see pornographic images

Expected Results:  
Not displayed the images
(Reporter)

Comment 1

14 years ago
If someone could tell me how to decifer images that have been loaded into
memory, then i could start working on this bug.
This should probably be done as an extension, not as part of the core browser. 
In fact, a content policy module that kills off such images in ShouldProcess()
would be about perfect at this.

You can get at images via nsIImageLoadingContent, from which you can get the
imgIRequest, from which you can get the imgIContainer, which will give you the
data for the current frame if you ask....
Then again, ShouldProcess() may fire too early.  The problem, of course, is that
we do incremental image rendering.  Therefore, part of the image will be shown
before it's all decoded (or even received) in many cases.  But again, this would
all be handleable in an extension (in ShouldProcess attach yourself as a
listener to the nsIImageLoadingContent, then catch the data as it comes through
and nuke the load by resetting the src or by setting display:none if you decide
it's not good).
(Reporter)

Comment 4

14 years ago
cant you look at the data before it is rendered, and then set a "dont-draw" 
flag which would then be rendered as the [x] image w/ alternate text?
We start rendering the data before we have all of it...
(Reporter)

Comment 6

14 years ago
how would i get the rgb of any paticular pixel from the imgIContainer? Would i 
have to refer to a palette? (of course you could stop checking early if you 
had a palette: if the palette doesn't have 'skin colour' or 'pink flesh 
colour', but most porn would be jpeg's and jpeg's dont have palettes)

Would the pixel data be stored in 4-byte groups: { BYTE r; BYTE g; BYTE b; 
BYTE reserved } or would it be in 3-byte groups?
I'm not sure that's clearly defined, actually... pav?  tor?  Do you know?

See also http://lxr.mozilla.org/seamonkey/source/gfx/public/nsIImage.h#77
(Reporter)

Comment 8

14 years ago
you could:
1. BitBlast the image to another surface (nsIImage.Draw) the surface being an 
area in memory, and then read the bits from there

2. use LockImagePixels and then use GetBitInfo and then UnlockImagePixels

also, should i seperate the loading/unloading of the palette from the 
constructor/destructor, and should i use a array in the heap for the palettes?
I was going to use palette-ranges for the palettes. that works by having each 
palette entry being 6 bytes: r1,r2,g1,g2,b1,b2 the colour has to be more than 
r1, less than r2, < g1, > g2, < b1, > b2. I thought that to optimize for speed.

That's totally up to you...  Recall that we are discussing code that will live
in an extension (probably on mozdev.org), not in the main Mozilla tree.  This is
why it would be better not to use nsIImage, since gfxIImageFrame is completely
scriptable... having the code all be in JS would make the extension easier to
install.
>Would the pixel data be stored in 4-byte groups: { BYTE r; BYTE g; BYTE b; 
>BYTE reserved } or would it be in 3-byte groups?

on mac 4 byte groups, elsewhere 3 byte groups. note that windows and a few
others use BGR, but that's indicated by the format attribute of the
gfxIImageFrame. palettes are not (yet?) used by mozilla, there's a bug to change
that for gifs.
> on mac 4 byte groups, elsewhere 3 byte groups.

Is that indicated by format?  That is, is it possible to write code in JS that
looks at the data reliably without guessing at the current OS?  (Apart from the
fact that the function needs to copy if it's to be used from JS and we need a
noscript version that does not, of course....)
>Is that indicated by format?

No... unfortunately not. C++ deals with that using ifdefs.

>  That is, is it possible to write code in JS that
>looks at the data reliably without guessing at the current OS?

afaik that's not possible. use javascript:navigator.platform I guess.

>  (Apart from the
> fact that the function needs to copy if it's to be used from JS and we need a
> noscript version that does not, of course....)

this would be the more important problem anyway.
> use javascript:navigator.platform I guess.

That's not reliable.

How about we fix gfxIImageFrame to actually be useful instead?  ;)

Good lord, if this isn't a WONTFIX then I don't know what is.
Ian, it's a wontfix as far as implementing the detector in Mozilla.  But we have
some API issues here that really should be resolved so that something like this
can be implemented as an extension...
>How about we fix gfxIImageFrame to actually be useful instead?  ;)

which would make this an image:gfx issue.
Assignee: security-bugs → jdunn
Component: Image Blocking → Image: GFX

Updated

14 years ago
Summary: pornographic image detector → API issues for pornographic image detector extensions

Comment 17

14 years ago
Marking NEW as per discussion with bz.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: jdunn → pavlov

Updated

11 years ago
Assignee: pavlov → nobody
QA Contact: image.gfx

Updated

8 years ago
Component: Image: Painting → Image: Painting
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.