6 ms·

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certific

by Joeri 9y ago

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

geocar 9y ago
In the UK, you can build a bridge without certification as long as you have someone certified review the plans and the implementation before anyone else drives on it. I suspect this is similar for most civilised countries. A (perhaps short-term) idea would be to make software vendors liable, and do not permit them to sign away that liability.
- dcow 9y ago
  I completely agree. But the vendor situation looks very different for software. Imagine being the sole person responsible for migrating Linux from ip/nftables to ebtables. You don't know how your stuff will be used downstream. So you license it with text in all caps reminding people that your software is provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And people still use it to build oil pipelines that bleed toxic goop when sent a really weird keepalive message. I hope that the first place we see an uptick is security. The list has grown rather long: consumer/citizen identity breaches, hospital ransomware, digital asset theft, remote vehicle control, etc. Most security people I know are of the mindset that systems will be hacked. It's extremely.. pragmatic. You can't really fault the people responsible when many companies simply require good damage control over actual security in order to be successful. But that's exactly the point. If the consequences were increased, not so many C[I]SOs would be okay with engineers using hot new software every few quarters. And those old boxes running Ruby 1.87 would sure as hell be patched or isolated to oblivion. Companies or projects with good security would flourish. Maybe some would be pressured to operate more like the archetype they're defending against (more red team, more organizational commitment to physical and operational security). I worked at a security company that had to get rid of a slack bot screen lock game because it hurt some people's feels. So yeah I think some of the priorities in this industry are messed up.
  - geocar 9y ago
    Those people who build oil pipelines should be able to sue whoever sold them the Linux distribution (probably Red Hat or IBM) which was vulnerable to that weird keepalive message. In that case, a judge (and perhaps a jury) could hear how Red Hat did everything they possibly could to protect from the vulnerability as evidenced by their ISO QA processes and the fact that everyone else was vulnerable to the same "bug" … or from the other side how Microsoft and Apple weren't at-risk, so Red Hat should've caught it. C[I]SOs would want to be patched, because ISO recommends they would be patched. > You can't really fault the people responsible when many companies simply require good damage control over actual security in order to be successful. Which is why I propose legislation, so "good damage control" wouldn't be enough. You better believe that oil company would want some evidence of testing and proper specifications, and to have them reviewed by a couple independent parties if the government could take them for a percent of gross revenue for the security vulnerabilities alone.
    - ta76567656 9y ago
      I disagree, unless RedHat certified that the software they're selling is of safety-critical quality. If the oil pipeline company used, let's say, nuts and bolts that didn't meet safety requirements without checking that the parts met the requirements or being assured by the vendor that they did, I would say they're the ones liable and not the vendor.
fleitz 9y ago
You can make a bridge in your backyard tho... Typically those bridges are made the same way as software, attempt to do it, test it a little bit, use it.
mulmen 9y ago
I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nuclear holocaust. This is the difference in maturity between software "engineering" and real engineering disciplines. You're free to experiment with your own resources but as soon as you make a promise to the public or your customers you should be required to meet your promises in all circumstances.
- BurritoAlPastor 9y ago
  This is a fine sentiment, but it's hardly a bright-line rule. We don't criticize Twitter's handling of abuse or fascists because they promised us a platform free of abusive fascists; Twitter didn't promise us shit except 140 character messages. All the problems were emergent. So many of the great (financial) success stories of our sector are about startups stumbling into an untapped demand, and then running with it for as long as the money lasts. Nobody sets out to build a bridge – they build a 2x4 plank, and then realize that rather a lot of people want to walk on it.
  - mulmen 9y ago
    Bullshit. Justify the recent Hawaii emergency notification in the context of an airliner. You can't because we would never tolerate that kind of unreliability in our transportation infrastructure. Twitter does what it says on the tin. That doesn't mean software engineering is a mature discipline.
    - oblio 9y ago
      In a sense, software engineering is quite mature. It's probably matured a lot faster than most other engineering branches. We know about static analysis, fuzzing, unit testing, integration testing, functional testing, Continuous Integration/Deployment/Delivery, etc., etc. It's just that maturity costs a lot of money. 95% of the software produced just doesn't need that and the client can't even afford it.
diafygi 9y ago
Hmmm, I think it's too early to tell. After all, we've witnessed move-fast-and-break-things social networks (Facebook, Twitter, Reddit) that had no desire to influence society in a big way get hijacked by state actors to achieve political goals. We're also witnessing toasters having web servers pre-installed on them with no thought into what happens if the company that pushes patches (if they do at all) goes bankrupt, thus creating vast oceans of botnets that the rest of us now have to deal with. Again, I think there's a long road ahead of hard lessons when we don't take our own power in software seriously.
cageface 9y ago
Maybe it would make more sense for people to be liable for data and not code. There's no need for my cute photo effects mobile app to undergo some kind of exhaustive code review but if I want to store credit card data or social security numbers maybe I should have to pass some kind of review.

by Joeri 9y ago

geocar 9y ago

In the UK, you can build a bridge without certification as long as you have someone certified review the plans and the implementation before anyone else drives on it. I suspect this is similar for most civilised countries. A (perhaps short-term) idea would be to make software vendors liable, and do not permit them to sign away that liability.

dcow 9y ago
I completely agree. But the vendor situation looks very different for software. Imagine being the sole person responsible for migrating Linux from ip/nftables to ebtables. You don't know how your stuff will be used downstream. So you license it with text in all caps reminding people that your software is provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And people still use it to build oil pipelines that bleed toxic goop when sent a really weird keepalive message. I hope that the first place we see an uptick is security. The list has grown rather long: consumer/citizen identity breaches, hospital ransomware, digital asset theft, remote vehicle control, etc. Most security people I know are of the mindset that systems will be hacked. It's extremely.. pragmatic. You can't really fault the people responsible when many companies simply require good damage control over actual security in order to be successful. But that's exactly the point. If the consequences were increased, not so many C[I]SOs would be okay with engineers using hot new software every few quarters. And those old boxes running Ruby 1.87 would sure as hell be patched or isolated to oblivion. Companies or projects with good security would flourish. Maybe some would be pressured to operate more like the archetype they're defending against (more red team, more organizational commitment to physical and operational security). I worked at a security company that had to get rid of a slack bot screen lock game because it hurt some people's feels. So yeah I think some of the priorities in this industry are messed up.
- geocar 9y ago
  Those people who build oil pipelines should be able to sue whoever sold them the Linux distribution (probably Red Hat or IBM) which was vulnerable to that weird keepalive message. In that case, a judge (and perhaps a jury) could hear how Red Hat did everything they possibly could to protect from the vulnerability as evidenced by their ISO QA processes and the fact that everyone else was vulnerable to the same "bug" … or from the other side how Microsoft and Apple weren't at-risk, so Red Hat should've caught it. C[I]SOs would want to be patched, because ISO recommends they would be patched. > You can't really fault the people responsible when many companies simply require good damage control over actual security in order to be successful. Which is why I propose legislation, so "good damage control" wouldn't be enough. You better believe that oil company would want some evidence of testing and proper specifications, and to have them reviewed by a couple independent parties if the government could take them for a percent of gross revenue for the security vulnerabilities alone.
  - ta76567656 9y ago
    I disagree, unless RedHat certified that the software they're selling is of safety-critical quality. If the oil pipeline company used, let's say, nuts and bolts that didn't meet safety requirements without checking that the parts met the requirements or being assured by the vendor that they did, I would say they're the ones liable and not the vendor.

fleitz 9y ago

You can make a bridge in your backyard tho... Typically those bridges are made the same way as software, attempt to do it, test it a little bit, use it.

mulmen 9y ago

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nuclear holocaust. This is the difference in maturity between software "engineering" and real engineering disciplines. You're free to experiment with your own resources but as soon as you make a promise to the public or your customers you should be required to meet your promises in all circumstances.

BurritoAlPastor 9y ago
This is a fine sentiment, but it's hardly a bright-line rule. We don't criticize Twitter's handling of abuse or fascists because they promised us a platform free of abusive fascists; Twitter didn't promise us shit except 140 character messages. All the problems were emergent. So many of the great (financial) success stories of our sector are about startups stumbling into an untapped demand, and then running with it for as long as the money lasts. Nobody sets out to build a bridge – they build a 2x4 plank, and then realize that rather a lot of people want to walk on it.
- mulmen 9y ago
  Bullshit. Justify the recent Hawaii emergency notification in the context of an airliner. You can't because we would never tolerate that kind of unreliability in our transportation infrastructure. Twitter does what it says on the tin. That doesn't mean software engineering is a mature discipline.
  - oblio 9y ago
    In a sense, software engineering is quite mature. It's probably matured a lot faster than most other engineering branches. We know about static analysis, fuzzing, unit testing, integration testing, functional testing, Continuous Integration/Deployment/Delivery, etc., etc. It's just that maturity costs a lot of money. 95% of the software produced just doesn't need that and the client can't even afford it.

diafygi 9y ago

Hmmm, I think it's too early to tell. After all, we've witnessed move-fast-and-break-things social networks (Facebook, Twitter, Reddit) that had no desire to influence society in a big way get hijacked by state actors to achieve political goals. We're also witnessing toasters having web servers pre-installed on them with no thought into what happens if the company that pushes patches (if they do at all) goes bankrupt, thus creating vast oceans of botnets that the rest of us now have to deal with. Again, I think there's a long road ahead of hard lessons when we don't take our own power in software seriously.

cageface 9y ago

Maybe it would make more sense for people to be liable for data and not code. There's no need for my cute photo effects mobile app to undergo some kind of exhaustive code review but if I want to store credit card data or social security numbers maybe I should have to pass some kind of review.