I shouldn't have been so harsh, because despite the fact that these techniques are already widely deployed [1], most people don't understand them. In fact I had a conversation with an ffmpeg developer on this forum and he didn'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't even trickled down to most programmers.

Application compartmentalization is certainly difficult in practice, and should be made easier, but it is deployed and it's a lot easier than rewriting all code in a different language.

ffmpeg is a great example. It is hideously broken, with thousands of likely security bugs [2]. Now let's compare these two strategies:

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.

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't even quite capture it -- it actually scales differently because for #2 you do constant work and get security for ALL video codecs. It's O(1) vs O(n).

Why not get secure foundations by 2025 instead of 2035? What I'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.

These techniques predate modern browsers -- they are used in qmail and djbdns. [3] [4]

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.

Also, if you look at the code we'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's), Python (1990), Perl (1985), PHP (90'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.

But the good news it that we can be running C code from 1985 in 2035 and still have secure systems!

I apologize for saying your post was naive, but I can tell from your original post and response that you haven't worked with security or operating systems very much. I have some impatience because the "rewrite everything" 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.

Browsers like Firefox and Chrome didn'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'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's an economic impossibility.

[1] Deployed by code you are using every day: (Chrome, Firefox, IE, Safari, etc.)

https://en.wikipedia.org/wiki/Process_isolation

http://www.chromium.org/developers/design-documents/multi-pr...
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Fir...

[2] https://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and...

[3] http://cr.yp.to/cv/activities-20050107.pdf -- see "extreme sandboxing".

[4] http://cr.yp.to/qmail/qmailsec-20071101.pdf

[5] http://www.joelonsoftware.com/articles/fog0000000069.html