Rob Pike wrote in the year 2000 that systems software research was irrelevant (http://herpolhode.com/rob/utah2000.pdf), and it seems to me that not much has changed since then. How many ideas from the last few decades of operating systems research have actually been put into practice?
The real problem is more fundamental: people want their software to keep working. As Rob Pike put it in the talk linked above, "to be a viable computer system, one must honor a huge list of large, and often changing, standards: TCP/IP, HTTP, HTML, XML, CORBA, Unicode, POSIX, NFS, SMB, MIME, POP, IMAP, X, ... With so much externally imposed structure, there’s little slop left for novelty."
For example, I'm sure some software out there is using the OpenGL API in a fundamentally insecure way. Changing the API to be safe would break this software. And maybe that would be a good tradeoff, if reworking OpenGL were the only thing you needed to do to safely run untrusted code. But almost every part of the system would have to change. You'd be left with a system which breaks or degrades pretty much everything you try to run on it.
I would say that the browser most certainly has the biggest attack surface of any software in regular use. Your average browser is insanely complex. In fact, it is the only piece of software on my computer that scares me.
Multiple JITs, font rendering, parsing, layouts, compression, image handling, sound and of course about a billion edge cases because somewhere along the road we decided that faulty code is OK. Everything with tonnes of state that interact in ways that can't ever be fully tested or verified (because of an almost infinite variety). Let's also not forget that a large part of that is done at the very bleeding edge of CS research. I wouldn't trust anyone to do that in a safe way.
To me, a kernel seems simple in comparison.
The whole native app is "untrusted" at the point of install. Even an app store offers a fairly thin guarantee about what apps are actually doing. It's far easier and less risky to open a web page and start doing something than install a native app.
Sandboxing of native apps are getting easier by the minute , at least for Linux. Flatpack and snappy aren't there yet,though...
The native apps I run on my Linux laptop, for example, I trust quite a bit. There may be a way for someone to sneak in some obfuscated code that does some harm, but I think the risks are much lower than many of the alternatives.
Sure, but in many modern browsers there's also a OS sandbox around it, so there's two layers of protection.
No browser has provided that either. In fact, browsers are by definition a security anti-feature because they are always connected to the network and the customer/user data lives on the network.
Even if they manage to solve the problem of computers getting hacked when visiting websites they are very unlikely to solve the problems of tracking and private data vacuuming.
How do you know? Basically every browser has a RCE vulnerability a month and has for 20 years. From ancient JPEG vulnerabilities to modern video codecs and DOM manipulation vulnerabilities.
[0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
There are a gazillion others, but this one is nice and sweet and exposes the whole web app strategy as completely bankrupt from a security perspective.
The only difference between malware and "regular-ware" is whether the code meets certain user expectations about what it will and will not do.
But paid software in the 90s and 2000s was fine, no network connectivity, didn't even check for updates. Heck, a lot of freeware was fine.
Then the market changed and spyware as a service became very profitable. The genius of this Spyware 2.0 was that it offered some benefits while not abusing the collected data in any obvious ways, like stealing your money. Browsers are helpless against this, in fact they are enabling the whole business model through their support of web apps and increasingly complex APIs.
Just plain pretty TTYs.
The JVM more-or-less managed it. Modern hypervisors do it - you could use something like Qubes and run completely untrusted code in its own isolated VM. It's not that academics weren't working on this stuff, adoption is where it fell down.
And on top of all that, it would still be more memory intensive than an equivalent native win32 application. Developers usually only shipped java-based UIs to Enterprise Software users who had no choice but to use what their bosses told them to use.
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/
For one example take WebGL. For decades OpenGL had been a native API prioritizing performance first and security last. It wasn't until browsers decided to expose OpenGL that the necessary work was done to make a graphics API safe for untrusted code. And who did that work? The browsers had to do most of it themselves.