I suspect (?) favicons are still rendered in the parent process, even with fission enabled.

We should consider rendering them in a content process (ideally in the content process for the origin in question), and then shipping our own re-rasterization of the favicon across to the parent process for rendering in the toolbar/etc.

This would provide better isolation and would reduce an attack vectors where attackers can get the parent process to render their own (perhaps specially-crafted-to-trigger-badness) image.

If we can force an origin-specific content process to render the favicon image and then reencode it ourselves for the parent process to render (or just decode/rasterize it into shared memory or something to that effect), then presumably we'd be less susceptible to attacks on the parent process.

(I suspect this would involve some non-trivial work across multiple components; I'm starting this bug out as a Core::ImageLib bug, but I suspect some frontend work would be required as well.)

I'm curious if tnikkel/aosmond know of any existing bugs/work in this area (or constraints/issues/etc)

There's bug 1586083.

image/imgITools.idl probably has what is needed for this, if not we can add anything.

Images are always decoded into shared memory with WebRender; they are shared with the compositor process, which might be either the parent or the GPU process. See SharedSurfacesParent/Child plumbing. We might be able to decode it with a special flag (share to parent?) when we have a GPU process to ensure we redecode and share with the right process in case both processes want it (very rare for a favicon I imagine).

Thanks - yeah, bug 1586083 is essentially what I had in mind here. This is probably a dupe of that.