> Outlook 98 used IE 4 to compose and render HTML e-mail messages (rather than just translating to RTF) as well as a summary page of messages, tasks, and calendar events called "Outlook Today". Everybody was perfectly happy to ignore the fact that this opened up Outlook to all of the bugs and exploits present in IE 4.
This one is funny in retrospect, because nowadays we would probably say that replacing a custom parser with a standard out-of-the-box runtime is a better tradeoff for security, as long as it is a full replacement suited for the task, and you are not greatly extending the functionality/looseness of the spec[^1]. Outlook 95's RTF format was likely afflicted by all sorts of vulnerabilities that are still undiscovered today, simply because it was less audited than modern Chromium and Firefox versions that get near-weekly security updates.
These days we have several interesting solutions that support this idea:
- The deprecation of Flash and replacement with HTML5 ports and Flash emulation via WASM - This has probably done a huge blow to the number of RCE exploits on the web.
- Firefox uses PDF.js to display PDF files inside of the web sandbox. We have wasted a ton of CPU time doing this, especially when compared to Okular - a particularly energy-efficient PDF reader, but Firefox having a builtin web-sandboxed PDF reader has likely has saved many users from the numerous RCE exploits in outdated version of other reader software.
- The proliferation of Electron and CEF. This has been troubled in terms of security due to lack of consistent updates for many applications, and because it's more privileged than web browsers it opens up a new attack surface for applications that could have just been true web apps -- however, when done correctly, using a standard known runtime allows important bugfixes to be centralized. But this is another one that has wasted a ton of CPU time for what is usually a more complex solution.
- The switch from C to memory-safe interpreted and bytecode languages, and the later un-proliferation of these as folks mostly switched to Java, C#, Python, Ruby, Lua, and Javascript
So, some great solutions, along with some technical debt we're not satisfied with. The core problem with all these solutions is that they risk putting too much weight on one failure point.
---
^1: The fact that they shipped IE4 in Outlook 98 with known exploits is very bad on this front