369239 - Imagelib APIs do not give access to the channels being used

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect)

Description

[Boris Zbarsky [:bzbarsky]]

In particular, it is not possible to either set or get the owner of the channel for an image request.  This means that it's not really possible to have javascript: URIs execute in a reasonable way for images, if we decide we want to do so.  It also means that it's impossible to track trust labels through image loads.

Comment 1

[Stuart Parmenter]

given the title of this bug and the fact that imagelib is designed to not give access to the channel I'd say WONTFIX, but we may want to expose some of the things you ask for.  We've talked about other ways to do security stuff in numerous other bugs so we could dup this...

Comment 2

[Boris Zbarsky [:bzbarsky]]

I need the following things, more or less:

1)  The ability to specify a particular originating principal for an image load.
    Image loads with different originating principals should probably not be
    coalesced (at the moment they can be, at least once we start tracking
    originating principals better). The principal would be set on the channel
    under certain conditions (yay frozen necko APIs).
2)  The ability to set certain parameters on the channel -- see bug 369244.  At
    least if we ever want to execute <img src="javascript:....">.  I question
    whether we do, actually.

I do realize the design of imagelib is to not give access to the channel, and I considered doing bug 369244 by flagging URIs instead, but that involves throwing URI cloning all over the place and is very very error-prone.

If you expose a way to accomplish #1 and #2 above that doesn't involve handing back the channel, that's fine by me.  ;)

I'm also fine with dupping if you transfer the blocking request and the dependency.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Of course another option is to give up on all this for Mozilla 1.x, and redesign Necko to be more security-aware for Mozilla 2....

Comment 4

[Boris Zbarsky [:bzbarsky]]

Filed bug 377092 on another approach that I'll take for 1.9.

Comment 5

[Bas Schouten (:bas.schouten)]

Boris, is this still needed?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Not as long as we're willing to add arguments to loadImage as needed, as we've done recently.  This bug was filed back when imagelib API changes were ... resisted.

Comment 7

[Bas Schouten (:bas.schouten)]

OK, then I'm marking this WONTFIX :).