8 ms·

That's an interesting thought but I'm not sure if it can be applied to software. Part of what makes security hard seems that it only takes a single point of fai

That's an interesting thought but I'm not sure if it can be applied to software. Part of what makes security hard seems that it only takes a single point of failure in a chain of dependencies to go bad. If there is a loophole on one server OS, then it's everywhere deeply ingrained in software. Even if you split the data, wouldn't the underlying platforms all have that flaw? Ironically the greatest advantage of software - easy distribution is also the cause of its greatest weakness. What I think might be a good idea for big organizations with sensitive data is to download a portion of the web and run their own intranet and isolate the network. Maybe Google can license their search engine and deliver some of the indexed web on prem as a service. If there is nothing coming in and going out, that might be a good foundation for good defense.

WalterBright 6y ago
> I'm not sure if it can be applied to software It certainly can be. But you've got to design it in from the beginning. But the first step is pretty hard - convince programmers that writing perfect software is impossible and to stop relying on it being perfect. Fire anyone in charge of security who certifies "the system is secure". :-/
unishark 6y ago
> That's an interesting thought but I'm not sure if it can be applied to software. Part of what makes security hard seems that it only takes a single point of failure in a chain of dependencies to go bad. I think this is the point. Software is about operating at the top level predominantly, packaging together stuff other people wrote using only simplified API's which abstract away their internal complexity. So you can zoom along at light speed producing "solutions" before the other guy and make the most money the fastest and move on. Engineering is about starting from physical principles and building a product that fits the understanding of those fundamental principles at work. The engineer generally stays with a set of fundamental domain principles their entire career (e.g. sticks with bridges as opposed to transmission lines) while programmers tend to stay at the top layers while the technologies below the surface change radically. It doesn't have to be that way for all software, presumably. Critical software and hardware can be designed together, for example, from the bottom up. I wonder if software patents is at fault for allowing those at the top layer to capture almost all the value in computers, and commoditize the technology below.
- IQunder130 6y ago
  Engineers work with high level abstractions and heuristics nobody really understands all the time. There are people working on R&D, and building design tools, but then again there are also people working on algorithm theory and writing kernel drivers. I don't think there is a fundamental difference, just a difference in degree. Software enables far more layers of abstraction and far quicker development cycles than other engineering disciplines.
  - unishark 6y ago
    You mean using experimental data rather than theory? It's still connected to the underlying science, which is the key component. It's like saying the difference between a peninsula and an island is one of degree. Yes in a sense, but one is tethered to the land. Certainly engineers can veer off into solely doing software, and there are vast numbers of people that straddle fields. But if they aren't using their fundamentals learned in engineering school (to oversimplify somewhat) you didn't need to hire an engineer. As for people building design tools, you mean engineers? When I say "top level predominantly" I mean things like this. The top level is the highest level for the software at hand. Practically everyone uses software. As for research, when it comes to engineering they are generally doing either applied science (of one of the hard sciences) or applied math. Certainly if you go to research conferences in CS or the right niches of engineering, you meet lots of people who are basically just applied mathematicians.
    - IQunder130 6y ago
      I am a mechanical engineer by trade. By "heuristics nobody really understands" I do mean just that. Some of it may be grounded in experimentation, some of it might be grounded in data sets collected by god knows whom go knows when, some of it might just be "do it this way because the graybeards/application manuals say so". So on and so forth. I find that a lot of software people have a highly idealized notion of how the "traditional" engineering disciplines work. Generalizing strict safety procedures found in some niche industries like aerospace to other fields where they don't exist. The truth is that working under time or budget pressures and without fully understanding what you're doing is extremely prevalent outside of software too.

WalterBright 6y ago

> I'm not sure if it can be applied to software It certainly can be. But you've got to design it in from the beginning. But the first step is pretty hard - convince programmers that writing perfect software is impossible and to stop relying on it being perfect. Fire anyone in charge of security who certifies "the system is secure". :-/

unishark 6y ago

> That's an interesting thought but I'm not sure if it can be applied to software. Part of what makes security hard seems that it only takes a single point of failure in a chain of dependencies to go bad. I think this is the point. Software is about operating at the top level predominantly, packaging together stuff other people wrote using only simplified API's which abstract away their internal complexity. So you can zoom along at light speed producing "solutions" before the other guy and make the most money the fastest and move on. Engineering is about starting from physical principles and building a product that fits the understanding of those fundamental principles at work. The engineer generally stays with a set of fundamental domain principles their entire career (e.g. sticks with bridges as opposed to transmission lines) while programmers tend to stay at the top layers while the technologies below the surface change radically. It doesn't have to be that way for all software, presumably. Critical software and hardware can be designed together, for example, from the bottom up. I wonder if software patents is at fault for allowing those at the top layer to capture almost all the value in computers, and commoditize the technology below.

IQunder130 6y ago
Engineers work with high level abstractions and heuristics nobody really understands all the time. There are people working on R&D, and building design tools, but then again there are also people working on algorithm theory and writing kernel drivers. I don't think there is a fundamental difference, just a difference in degree. Software enables far more layers of abstraction and far quicker development cycles than other engineering disciplines.
- unishark 6y ago
  You mean using experimental data rather than theory? It's still connected to the underlying science, which is the key component. It's like saying the difference between a peninsula and an island is one of degree. Yes in a sense, but one is tethered to the land. Certainly engineers can veer off into solely doing software, and there are vast numbers of people that straddle fields. But if they aren't using their fundamentals learned in engineering school (to oversimplify somewhat) you didn't need to hire an engineer. As for people building design tools, you mean engineers? When I say "top level predominantly" I mean things like this. The top level is the highest level for the software at hand. Practically everyone uses software. As for research, when it comes to engineering they are generally doing either applied science (of one of the hard sciences) or applied math. Certainly if you go to research conferences in CS or the right niches of engineering, you meet lots of people who are basically just applied mathematicians.
  - IQunder130 6y ago
    I am a mechanical engineer by trade. By "heuristics nobody really understands" I do mean just that. Some of it may be grounded in experimentation, some of it might be grounded in data sets collected by god knows whom go knows when, some of it might just be "do it this way because the graybeards/application manuals say so". So on and so forth. I find that a lot of software people have a highly idealized notion of how the "traditional" engineering disciplines work. Generalizing strict safety procedures found in some niche industries like aerospace to other fields where they don't exist. The truth is that working under time or budget pressures and without fully understanding what you're doing is extremely prevalent outside of software too.