> But replacing small isolated components is not a very interesting option.
I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input.
I strongly believe you'd get significant returns by incrementally replacing components like that with Rust.
> Every single decision on what language to use for a component in becomes a hard to reverse
This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.
JSON is just a straightforward example because it's easy to understand how it falls into Chromium's threat model. Feel free to replace it with font parsing, audio/video codecs, etc, and you'll find thousands of relevant vulns.
I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input.
I strongly believe you'd get significant returns by incrementally replacing components like that with Rust.
> Every single decision on what language to use for a component in becomes a hard to reverse
This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.