7 ms·

> Do we, really? Yes, or pretty close to it. What we don't know how to do (AFAIK) is do it at a cost that would be acceptable for most software. So yes, it mos

by bruckie 6mo ago

> Do we, really? Yes, or pretty close to it. What we don't know how to do (AFAIK) is do it at a cost that would be acceptable for most software. So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc. Totally agreed that most software is a morass of bugs. But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It only provides information about whether we know how to make buggy software—spoiler alert: we do :)

colonCapitalDee 6mo ago
Then we can't do it. Cost is a requirement
- LeifCarrotson 6mo ago
  Cost is a parameter subject to engineering tradeoffs, just like performance, feature sets, and implementation time. Security and reliability are also parameters that exist on a sliding scale, the industry has simply chosen to slide the "cost" parameter all the way to one end of the spectrum. As a result, the number of bugs and hacks observed are far enough from the desired value of zero that it's clear the true requirements for those parameters cannot be honestly said to be zero.
  - TeMPOraL 6mo ago
    > the number of bugs and hacks observed are far enough from the desired value of zero Zero is not the desired number, particularly not when discussing "hacks". This may not matter in current situation, but there's a lot of "security maximalism" in the industry conversations today, and people seem to not realize that dragging the "security" slider all the way to the right means not just the costs becoming practically infinite, but also the functionality and utility of the product falling down to 0.
    - DarkUranium 6mo ago
      I know a lot of security researchers will disagree with this notion, but I personally think that security (& privacy, I'm going to refer to both as "security" for brevity here) are an overhead. I think that's why it needs to exist *and be discussed* as a sliding scale. I do find a lot of people in this space chase some ideal without a consideration for practicality. Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate. Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time. The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late. Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception. Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats. Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.
      - dundundundun 6mo ago
        In my experience, the proper infosec professionals both know and balance this well, it's the amateurs and posers who gets it wrong.
      - 6mo ago
  - xyzzy123 6mo ago
    Is it the industry making this choice or the customer? You could make a car that's safer than others at 10x the price but what would the demand look like at that price? Would you pay 2x for your favourite software and forego some of the more complex features to get a version with half the security issues?
    - HappMacDonald 6mo ago
      Sometimes I want VSCode and sometimes I want Notepad. Well.. except that I never want either of those. So sometimes I want Kate editor and sometimes I want Akelpad.
    - 1dontnkow_ 6mo ago
      Thats very true and I think about often because even in everyday task e.g. "We need a new feature to download reports" then you get a ticket but still depending how much that is used, desired, invested in or marketed and all those things, how flexible should I make, whats all the errors, whats the data, how secure and million other small or bigger decisions. The point isn't how user stories are written, but realizing that everything is a compromise for practicality since if I wanted it to be the most secure thing ever, Id say "Lets just not offer that feature at all". But now back to cars, I like that I heard some companies promised or started to build cars again with real buttons. In our world its when I try to use more and support the tools which aren't build on Electron (and slow as hell) but actually care about performance. Open source and decent enough security is already the minimum requirement.
- ablob 6mo ago
  The question was not if it was possible within price boundary X, but if it was possible at all. There is a difference, please don't confound possibility with feasibility.
- PaulHoule 6mo ago
  Also people keep insisting on using unsafe languages like C. It depends on exactly what you are doing but there are many languages which are efficient to develop in if less efficient to execute like Java and Javascript and Python which are better in many respects and other languages which are less efficient to develop in but more efficient to run like Rust. So at the very least it is a trilemma and not a dilemma.
  - jjav 6mo ago
    > if less efficient to execute like Java and Javascript and Python One of these is not like the others... Java (JVM) is extremely fast.
    - whstl 6mo ago
      The JVM has been extremely fast for a long long time now. Even Javascript is really fast, and if you really need performance there’s also others in the same performance class like C#, Rust, Go. Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.
      - PaulHoule 6mo ago
        I think it is the perception of performance instead of the actual performance, also that C/C++ encroaches on “close to the metal” assembly for many applications. (E.g. when I think how much C moves the stack pointer around meaninglessly in my AVR-8 programs it drives me nuts but AVR-8 has a hard limit and C programs are portable to the much faster ESP32 and ARM. A while back when my son was playing Chess I wrote a chess engine in Python and then tried to make a better one in Java which could respect time control, it was not hard to make the main search routine work without allocating memory but I tried to do transposition tables with Java objects it made the engine slower, not faster. I could have implemented them with off-heap memory but around that time my son switched from Chess to guitar so I started thinks about audio processing instead. The Rust vs Java comparison is also pointed. I was excited about Rust the same way I was excited about cyclone when it came out but seeing people struggle with async is painful for me to watch and makes it look like the whole idea doesn’t really work when you get away from what you can do with stack allocation. People think they can’t live with Java’s GC pauses.
- whstl 6mo ago
  Is having problematic features that causes problems also a requirement? The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey. In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.
  - rvnx 6mo ago
    Unlimited budget and unlimited people won't solve unlimited problems with perfection. Even basic theorems of science are incorrect.
rcxdude 6mo ago
That software also often has bugs. It's usually a bit more likely that they are documented, though, and unlikely to cause a significant failure on their own.
- chii 6mo ago
  building around bugs that you know exists but dont know where is also a part of it. Reliability in the face of bugs. The mere existence of bugs isn't enough to call the software buggy, if the outcome is reliable (e.g., a triple module redundancy).
  - eru 6mo ago
    For a silly example, see how Python programs have plenty of bugs, but they still (usually) don't allow for the kind of memory exploits that C programs give you. You could say that Python is designed around preventing these memory bugs.
PaulHoule 6mo ago
There is a huge wetware problem too. Like if I can send you an email or other message that tricks you and gets you to send me $10k, what do I care if the industry is 100% effective at blocking RCE?
- reactordev 6mo ago
  The social hack executed in digital space. 100% agree.
denzil 6mo ago
> So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc. I have to disagree here. All of these you mentioned have regularly bugs. Multiple spacecraft got lost because of these. For planes there's not so distant Boeing 737 MAX fiasco (admittedly this was bad software behavior caused by sensor failure). And medical devices, the news about their bugs semi-regularly pop up. So while the software for these might do a bit better than the rest, they certainly are not anywhere close to being bug free. And same goes for specifications the software is based on. Those aren't bug-free either. And writing software based on flawed specification will inevitably result in flawed software. That's not to say we should give up on trying to write bug free software. But we currently don't know how to do so.
isidkwidkiejdk 6mo ago
> But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It only provides information about whether we know how to make buggy software—spoiler alert: we do :) Conversely, and perhaps MUCH more importantly, only saying that we know how to write relatively bug-free software without giving any evidence or proof that it is indeed the case is a gigantic red flag. In fact, given how our brains work and how illogical we actually are, it’s quite unbelievable that we actually have the capacity to write “bug-free” code. Such a thing is much more likely to really be just a myth more than anything else, and simply saying “nuh-uh” won’t change that.

by bruckie 6mo ago

colonCapitalDee 6mo ago

Then we can't do it. Cost is a requirement

LeifCarrotson 6mo ago
Cost is a parameter subject to engineering tradeoffs, just like performance, feature sets, and implementation time. Security and reliability are also parameters that exist on a sliding scale, the industry has simply chosen to slide the "cost" parameter all the way to one end of the spectrum. As a result, the number of bugs and hacks observed are far enough from the desired value of zero that it's clear the true requirements for those parameters cannot be honestly said to be zero.
- TeMPOraL 6mo ago
  > the number of bugs and hacks observed are far enough from the desired value of zero Zero is not the desired number, particularly not when discussing "hacks". This may not matter in current situation, but there's a lot of "security maximalism" in the industry conversations today, and people seem to not realize that dragging the "security" slider all the way to the right means not just the costs becoming practically infinite, but also the functionality and utility of the product falling down to 0.
  - DarkUranium 6mo ago
    I know a lot of security researchers will disagree with this notion, but I personally think that security (& privacy, I'm going to refer to both as "security" for brevity here) are an overhead. I think that's why it needs to exist *and be discussed* as a sliding scale. I do find a lot of people in this space chase some ideal without a consideration for practicality. Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate. Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time. The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late. Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception. Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats. Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.
    - dundundundun 6mo ago
      In my experience, the proper infosec professionals both know and balance this well, it's the amateurs and posers who gets it wrong.
    - 6mo ago
- xyzzy123 6mo ago
  Is it the industry making this choice or the customer? You could make a car that's safer than others at 10x the price but what would the demand look like at that price? Would you pay 2x for your favourite software and forego some of the more complex features to get a version with half the security issues?
  - HappMacDonald 6mo ago
    Sometimes I want VSCode and sometimes I want Notepad. Well.. except that I never want either of those. So sometimes I want Kate editor and sometimes I want Akelpad.
  - 1dontnkow_ 6mo ago
    Thats very true and I think about often because even in everyday task e.g. "We need a new feature to download reports" then you get a ticket but still depending how much that is used, desired, invested in or marketed and all those things, how flexible should I make, whats all the errors, whats the data, how secure and million other small or bigger decisions. The point isn't how user stories are written, but realizing that everything is a compromise for practicality since if I wanted it to be the most secure thing ever, Id say "Lets just not offer that feature at all". But now back to cars, I like that I heard some companies promised or started to build cars again with real buttons. In our world its when I try to use more and support the tools which aren't build on Electron (and slow as hell) but actually care about performance. Open source and decent enough security is already the minimum requirement.
ablob 6mo ago
The question was not if it was possible within price boundary X, but if it was possible at all. There is a difference, please don't confound possibility with feasibility.
PaulHoule 6mo ago
Also people keep insisting on using unsafe languages like C. It depends on exactly what you are doing but there are many languages which are efficient to develop in if less efficient to execute like Java and Javascript and Python which are better in many respects and other languages which are less efficient to develop in but more efficient to run like Rust. So at the very least it is a trilemma and not a dilemma.
- jjav 6mo ago
  > if less efficient to execute like Java and Javascript and Python One of these is not like the others... Java (JVM) is extremely fast.
  - whstl 6mo ago
    The JVM has been extremely fast for a long long time now. Even Javascript is really fast, and if you really need performance there’s also others in the same performance class like C#, Rust, Go. Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.
    - PaulHoule 6mo ago
      I think it is the perception of performance instead of the actual performance, also that C/C++ encroaches on “close to the metal” assembly for many applications. (E.g. when I think how much C moves the stack pointer around meaninglessly in my AVR-8 programs it drives me nuts but AVR-8 has a hard limit and C programs are portable to the much faster ESP32 and ARM. A while back when my son was playing Chess I wrote a chess engine in Python and then tried to make a better one in Java which could respect time control, it was not hard to make the main search routine work without allocating memory but I tried to do transposition tables with Java objects it made the engine slower, not faster. I could have implemented them with off-heap memory but around that time my son switched from Chess to guitar so I started thinks about audio processing instead. The Rust vs Java comparison is also pointed. I was excited about Rust the same way I was excited about cyclone when it came out but seeing people struggle with async is painful for me to watch and makes it look like the whole idea doesn’t really work when you get away from what you can do with stack allocation. People think they can’t live with Java’s GC pauses.
whstl 6mo ago
Is having problematic features that causes problems also a requirement? The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey. In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.
- rvnx 6mo ago
  Unlimited budget and unlimited people won't solve unlimited problems with perfection. Even basic theorems of science are incorrect.

rcxdude 6mo ago

That software also often has bugs. It's usually a bit more likely that they are documented, though, and unlikely to cause a significant failure on their own.

chii 6mo ago
building around bugs that you know exists but dont know where is also a part of it. Reliability in the face of bugs. The mere existence of bugs isn't enough to call the software buggy, if the outcome is reliable (e.g., a triple module redundancy).
- eru 6mo ago
  For a silly example, see how Python programs have plenty of bugs, but they still (usually) don't allow for the kind of memory exploits that C programs give you. You could say that Python is designed around preventing these memory bugs.

PaulHoule 6mo ago

There is a huge wetware problem too. Like if I can send you an email or other message that tricks you and gets you to send me $10k, what do I care if the industry is 100% effective at blocking RCE?

reactordev 6mo ago
The social hack executed in digital space. 100% agree.

denzil 6mo ago

> So yes, it mostly gets done for (components of) planes, spacecraft, medical devices, etc. I have to disagree here. All of these you mentioned have regularly bugs. Multiple spacecraft got lost because of these. For planes there's not so distant Boeing 737 MAX fiasco (admittedly this was bad software behavior caused by sensor failure). And medical devices, the news about their bugs semi-regularly pop up. So while the software for these might do a bit better than the rest, they certainly are not anywhere close to being bug free. And same goes for specifications the software is based on. Those aren't bug-free either. And writing software based on flawed specification will inevitably result in flawed software. That's not to say we should give up on trying to write bug free software. But we currently don't know how to do so.

isidkwidkiejdk 6mo ago

> But giving examples of buggy software doesn't provide any information about whether we know how to make non-buggy software. It only provides information about whether we know how to make buggy software—spoiler alert: we do :) Conversely, and perhaps MUCH more importantly, only saying that we know how to write relatively bug-free software without giving any evidence or proof that it is indeed the case is a gigantic red flag. In fact, given how our brains work and how illogical we actually are, it’s quite unbelievable that we actually have the capacity to write “bug-free” code. Such a thing is much more likely to really be just a myth more than anything else, and simply saying “nuh-uh” won’t change that.