>It's not a coincidence that the best researchers in the
>industry spend much of their time discovering and weaponizing >browser vulnerabilities
It's not a coincidence, but complexity isn't the only possible explanation. Attackers like to go after easy targets, and nobody's saying that browsers aren't easy targets. I'd say it's because browsers are built around a fundamentally flawed security model that provides inadequate isolation between various users, resources, and activities. That could be true even if browsers were ten times simpler. Others might point to prioritizing other goals (e.g. rendering performance) over security, or even say that browser implementers are just less skilled than kernel implementers.
> You say browsers are insecure because they're required to be complex.
No. I said they had conflicting requirements, but I wasn't talking about complexity. I was talking about things like plugin extensibility and interoperability with protocols and formats that are themselves insecure. Those requirements don't have to drive the insane LOC figures for browsers, but it's hard to be secure when you're exchanging bodily fluids with every plugin writer in the world.
Instead of beating this dead horse any more, perhaps the more interesting discussion is whether browsers can be secure. Or is the fundamental concept of a "browser" - a single program to mediate all kinds of protocols, intermingled with presentation and even execution of arbitrary code all in the same address space - just a security anti-pattern at its most basic level? If you have a component that tries to pretend it's an OS, but is essentially not capable of being a TCB, maybe it's not the component but the whole architecture that's broken.
It's not a coincidence, but complexity isn't the only possible explanation. Attackers like to go after easy targets, and nobody's saying that browsers aren't easy targets. I'd say it's because browsers are built around a fundamentally flawed security model that provides inadequate isolation between various users, resources, and activities. That could be true even if browsers were ten times simpler. Others might point to prioritizing other goals (e.g. rendering performance) over security, or even say that browser implementers are just less skilled than kernel implementers.
> You say browsers are insecure because they're required to be complex.
No. I said they had conflicting requirements, but I wasn't talking about complexity. I was talking about things like plugin extensibility and interoperability with protocols and formats that are themselves insecure. Those requirements don't have to drive the insane LOC figures for browsers, but it's hard to be secure when you're exchanging bodily fluids with every plugin writer in the world.
Instead of beating this dead horse any more, perhaps the more interesting discussion is whether browsers can be secure. Or is the fundamental concept of a "browser" - a single program to mediate all kinds of protocols, intermingled with presentation and even execution of arbitrary code all in the same address space - just a security anti-pattern at its most basic level? If you have a component that tries to pretend it's an OS, but is essentially not capable of being a TCB, maybe it's not the component but the whole architecture that's broken.