I shouldn&#x27;t have been so harsh, because despite the fact that these techniques are already widely deployed [1], most people don&#x27;t understand them.  In fact I had a conversation with an ffmpeg developer on this forum and he didn&#x27;t think securing ffmpeg this way was feasible.  And I think another reply to my message mistook FFI for IPC, as you did.  So the vocabulary hasn&#x27;t even trickled down to most programmers.<p>Application compartmentalization is certainly difficult in practice, and should be made easier, but it is deployed and it&#x27;s a lot easier than rewriting all code in a different language.<p>ffmpeg is a great example.  It is hideously broken, with thousands of likely security bugs [2].  Now let&#x27;s compare these two strategies:<p><pre><code>    1) Rewrite EVERY video codec in Rust
    2) Reuse existing code, but run it in a completely
    untrusted process (no OS privileges), and only 
    communicate with IPC.
</code></pre>
The claim is that #2 is much more achievable than #1.  You could say that #1 takes orders of magnitude more work, which is true, but that doesn&#x27;t  even quite capture it -- it actually scales differently because for #2 you do constant work and get security for ALL video codecs.  It&#x27;s O(1) vs O(n).<p>Why not get secure foundations by 2025 instead of 2035?  What I&#x27;m arguing for is a hybrid, heterogeneous architecture -- instead of rewriting 100% of code in Rust, rewrite 5% in Rust and isolate the remaining 95%.  That gets you a better result which much less effort.<p>These techniques predate modern browsers -- they are used in qmail and djbdns.  [3] [4]<p>I agree with the idea that most people underestimate change in the long term, but that is orthogonal to my point -- we get get secure systems faster with a different technique, in a shorter time frame.<p>Also, if you look at the code we&#x27;re using today, it is perfectly reasonable to conclude that in 2035 we will be using a lot of the same code.  People are still using Linux (1991), GNU tools (started in the 80&#x27;s), Python (1990), Perl (1985), PHP (90&#x27;s), etc.  In 2035 is undoubted we will be using code from 2015 -- in fact it is likely we will be using code from 1985 in 2035.  Those are the economics of software.  Stable code is extraordinarily valuable and long lasting.<p>But the good news it that we can be running C code from 1985 in 2035 and still have secure systems!<p>I apologize for saying your post was naive, but I can tell from your original post and response that you haven&#x27;t worked with security or operating systems very much.  I have some impatience because the &quot;rewrite everything&quot; response reminds me of people who think they can rewrite an old codebase do better, when in reality they would end up with something worse [5].  There is a lack of subtlety and lack of understanding implied when you want to start completely from scratch.<p>Browsers like Firefox and Chrome didn&#x27;t even start from scratch.  Firefox was derived from decades-old netscape code, and Chrome reused Webkit, which was derived from Konquerer.  Google has infinite money, but didn&#x27;t rewrite Android from scratch -- it is based on Linux and hundreds of other open source projects.  Code lasts A LONG TIME -- simply suggesting that everyone rewrite it is not helpful.  It&#x27;s an economic impossibility.<p>[1] Deployed by code you are using every day: (Chrome, Firefox, IE, Safari, etc.)<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Process_isolation" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Process_isolation</a><p><a href="http:&#x2F;&#x2F;www.chromium.org&#x2F;developers&#x2F;design-documents&#x2F;multi-process-architecture" rel="nofollow">http:&#x2F;&#x2F;www.chromium.org&#x2F;developers&#x2F;design-documents&#x2F;multi-pr...</a>
<a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;Firefox&#x2F;Multiprocess_Firefox&#x2F;Motivation" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;Firefox&#x2F;Multiprocess_Fir...</a><p>[2] <a href="https:&#x2F;&#x2F;googleonlinesecurity.blogspot.com&#x2F;2014&#x2F;01&#x2F;ffmpeg-and-thousand-fixes.html" rel="nofollow">https:&#x2F;&#x2F;googleonlinesecurity.blogspot.com&#x2F;2014&#x2F;01&#x2F;ffmpeg-and...</a><p>[3] <a href="http:&#x2F;&#x2F;cr.yp.to&#x2F;cv&#x2F;activities-20050107.pdf" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;cv&#x2F;activities-20050107.pdf</a> -- see &quot;extreme sandboxing&quot;.<p>[4] <a href="http:&#x2F;&#x2F;cr.yp.to&#x2F;qmail&#x2F;qmailsec-20071101.pdf" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;qmail&#x2F;qmailsec-20071101.pdf</a><p>[5] <a href="http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;articles&#x2F;fog0000000069.html" rel="nofollow">http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;articles&#x2F;fog0000000069.html</a>