Mossop recently (bug 1453751) heroically moved our network request code for favicons into the content process (previously, we just slapped whatever URI the content process handed us into an image tag in the parent), but the actual loading of the data that comes over the network, and the resulting rendering, still happens in the parent.

We could remove an avenue of sandbox escaping / exploiting issues in our image rendering code if we did that rendering in the child. There are some tricky issues with this:

• fidelity loss; the child would need to know at what size and density to render the image
• potentially blending issues wrt transparency / background of tabs

However, in theory, an HTML canvas would give us a reasonable way of doing this that would accomplish this and get us some nice defense-in-depth wins for issues in our image parsing / rendering / painting pipeline.

For animated GIF favicons, would we generate a new PNG per frame and set that up to the parent? Or could we consider GIFs to be safe as well?

(In reply to Cameron McCormack (:heycam) from comment #1)

For animated GIF favicons, would we generate a new PNG per frame and set that up to the parent? Or could we consider GIFs to be safe as well?

Good question - I'm not sure. Certainly short-term, perhaps it'd be easiest to pass gif images along as-is for this reason, given that I don't think we can currently choose frames to render to canvas for animated gifs? I could be wrong about that...

I'm not sure we could have the parent process accepting PNGs from the child process. If the child process was compromised it could send whatever png it wanted, so we'd be exposing the parent process to the same risk (although limited to pngs) we were hoping to mitigate with this change. So we'd need to use a uncompressed image.

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

I'm not sure we could have the parent process accepting PNGs from the child process. [...] So we'd need to use a uncompressed image.

Sounds good; I don't imagine an uncompressed favicon-sized image would be particularly heavyweight to be sending IPC.

--> s/png thing/uncompressed image/ in bug title, for clarity.