← Back to context

Comment by atemerev

10 years ago

> There are too many changes.

I am sorry, security guys, but unless it's military-grade software, security is just another feature. And it is not a highest priority one. Of course, security would be easier if there were no new features or spec changes. And software development in general would be much easier if there weren't any of those pesky end users.

Which is a good thing, probably. Otherwise, you'd be mostly out of your jobs. Security is always changing, chaotic battlefront.

Having said that, sandboxing is a good idea. Theoretically. But it is really hard to implement right — attack surface on the edges of the boxes is quite large. Remember those Java applets? They were sandboxed neck-deep, with excellent security model. Did it help?

The thing that you're missing here is that some of us do work on military-grade software and we still need to use a browser. We need to trust that going to a website won't leak information off of our HDs. I know a guy that builds fighter aircraft displays out of a giant clean room he built in his home. He was writing code for it on the same computer he was using for day to day work because he didn't really know any better (more of an Electrical Engineer than a software dev). My point is that you don't get to use the "it's just another feature" with some of this stuff.

For Counter Strike, sure. But for things like spreadsheets or web browsers, hundreds of thousands or millions of people working in arms manufacture or intelligence are going to be using your software and it needs to not leak designs to foreign intelligence agencies or competitors.

  • They need to fund development of a military grade browser then. Perhaps that might be a better investment than the F-35 for example?

    • I bet it would burn through a billion dollars, require a team of hundreds, take 10 years, then be so buggy would get cancelled.

      I started off talking about the browser, not the F-35, but by the end the line blurred. :-)

  • > "The thing that you're missing here is that some of us do work on military-grade software and we still need to use a browser."

    Then use Qubes OS:

    https://www.qubes-os.org/

    You can set up a separate VM in Qubes OS purely for browsing. That way, even if your browser was compromised, it would be isolated from your other applications.

  • Is his house on a Military base? Otherwise, how can he have such sensitive material in his home? That is a much bigger security risk to me it seems ...

    • Maybe I wasn't clear, they were prototypes. The final factory that ended up building them at scale was next to an airbase that has the physical security that you'd expect. But they still use web browsers there.

      2 replies →

    • People don't build aircraft on military bases, they build them in civilian-run factories. Workers do take work home with them. Some stuff is "only" ITAR-controlled, some stuff is more closely regulated.

> I am sorry, security guys, but unless it's military-grade software, security is just another feature. And it is not a highest priority one.

I completely disagree: security is the foundation of any software system. Without security, the system simply cannot be trusted to do anything correctly, not even add 1 and 1 together. For far too long we've relied on our systems being accidentally correct rather than deliberately secure; we need to fix that.

If something's mathematically possible, then it will happen. We need to build systems where security flaws are impossible, because then … they won't happen.

  • > Without security, the system simply cannot be trusted to do anything correctly, not even add 1 and 1 together.

    Not really. For a simple example, imagine a calculator software which has been mathematically proven to work correctly for any number with 30 or less digits, but which overflows a fixed-size buffer if the user inputs a number with more than 30 digits. That software could absolutely be trusted to add 1 and 1 together, while still having a security issue.

The idea is to separate security out so that new features and spec changes don't impact it. The necessary features of the sandbox are defined by the hardware, which doesn't change very fast. Everything else can be done inside the sandbox, without worrying about security.

Java applets are another example of security competing with features. Any part of the runtime could cause an exploit. If the sandbox had been separate it would've been safer.