Saying browsers are "the largest attack surface" is an indication of ubiquity, not an indictment of the design or implementation of browsers (which are still worth considering separately). And we only make such remarks about browsers (or other apps that execute untrusted code like spreadsheets or PDF readers) because the state of OS security is such that any program running directly can pretty much wreak havoc even without explicit superuser privileges. Even on locked-down mobile OSes, the amount of havoc your Facebook app gets up to is incredible compared to what happens when you merely visit facebook.com on your mobile browser.

It seems like most users don’t really understand that they’re really running a lot of code for every page they visit now though. IMO it’s as prevalent as it is because browsers just run code by default. If iOS and Android apps were automatically launched without explicit installation by visiting URLs, they’d probably have just as much security out of necessity.

" because the state of OS security"

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/