Render favicons in content processes
Categories
(Core :: Graphics: ImageLib, task)
Tracking
()
People
(Reporter: dholbert, Unassigned)
Details
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.)
Reporter | ||
Comment 2•3 years ago
|
||
I'm curious if tnikkel/aosmond know of any existing bugs/work in this area (or constraints/issues/etc)
Reporter | ||
Updated•3 years ago
|
Comment 3•3 years ago
|
||
There's bug 1586083.
image/imgITools.idl probably has what is needed for this, if not we can add anything.
Comment 4•3 years ago
|
||
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).
Updated•3 years ago
|
Reporter | ||
Comment 5•3 years ago
|
||
Thanks - yeah, bug 1586083 is essentially what I had in mind here. This is probably a dupe of that.
Reporter | ||
Updated•3 years ago
|
Description
•