Those not designed for security were like that. Those designed for security had few of those problems. They just weren't popular with the big ecosystems and such since the demand side didn't care about security much. Very little security bolted onto something that was opposite at core. Common solutions were memory-safety for apps with validation on API calls, limiting of API's accessible, mandatory access control, and/or VM's isolating whole systems from apps needing protection.
OS's and browsers are not only becoming similar in functionality: they're similar in why people adopted them and why they're insecure.
"Saying browsers are "the largest attack surface" is an indication of ubiquity, not an indictment of the design or implementation of browsers"
It's actually saying both since browsers were mostly not designed for strong security or apply security engineering techniques of the time. That would be POLA, privilege separation, memory-safe languages, high-quality code in any components integrated, and so on. The first I saw attempt it was Chrome's Native Client imitating some benefits of OP Web Browser [that was designed for security] but weakening them for performance. Latter was Chrome's highest priority IIRC. There's Quantum moving memory-safe code into Firefox. However, browsers are mostly insecure architecture and code that just gets patched as problems are found. And they're ubiquitous. Music to malware authors' ears. :)
I'm including examples below of security-focused, browser architectures applying various methods of security at design and/or implementation stage so you have a mental point of comparison to current ones in terms of techniques employed. They were released as prototypes with nobody putting any effort in past that. So, high-assurance sector just isolated regular browsers in protection domains (eg VM's) on separation kernels or using MAC if browsers had to be there. Otherwise, native apps in memory-safe languages with regular old client-server architecture were much easier to make reliable and secure. Especially if using middleware designed to help with that. That's still true.
Those not designed for security were like that. Those designed for security had few of those problems. They just weren't popular with the big ecosystems and such since the demand side didn't care about security much. Very little security bolted onto something that was opposite at core. Common solutions were memory-safety for apps with validation on API calls, limiting of API's accessible, mandatory access control, and/or VM's isolating whole systems from apps needing protection.
OS's and browsers are not only becoming similar in functionality: they're similar in why people adopted them and why they're insecure.
"Saying browsers are "the largest attack surface" is an indication of ubiquity, not an indictment of the design or implementation of browsers"
It's actually saying both since browsers were mostly not designed for strong security or apply security engineering techniques of the time. That would be POLA, privilege separation, memory-safe languages, high-quality code in any components integrated, and so on. The first I saw attempt it was Chrome's Native Client imitating some benefits of OP Web Browser [that was designed for security] but weakening them for performance. Latter was Chrome's highest priority IIRC. There's Quantum moving memory-safe code into Firefox. However, browsers are mostly insecure architecture and code that just gets patched as problems are found. And they're ubiquitous. Music to malware authors' ears. :)
I'm including examples below of security-focused, browser architectures applying various methods of security at design and/or implementation stage so you have a mental point of comparison to current ones in terms of techniques employed. They were released as prototypes with nobody putting any effort in past that. So, high-assurance sector just isolated regular browsers in protection domains (eg VM's) on separation kernels or using MAC if browsers had to be there. Otherwise, native apps in memory-safe languages with regular old client-server architecture were much easier to make reliable and secure. Especially if using middleware designed to help with that. That's still true.
DarpaBrowser http://www.combex.com/papers/darpa-review/security-review.pd...
OP and OP2 Browsers https://pdfs.semanticscholar.org/832a/911f97b500cd2df4680186...
Microsoft Gazelle https://www.microsoft.com/en-us/research/publication/the-mul...
Illinois Browser Operating System https://www.usenix.org/legacy/event/osdi10/tech/full_papers/...
Quark Browser http://goto.ucsd.edu/quark/