13 ms·

Software Freedom Doesn't Kill People, Security Through Obscurity Kills People

192 points by ashitlerferad 10y ago

unimpressive 10y ago
>The time has come that I must speak out against the inappropriate rhetoric used by those who (ostensibly) advocate for FLOSS usage in automotive applications. You mean used against?
- TickleSteve 10y ago
  nonsensical rant is nonsensical....
- Leynos 10y ago
  The author appears to be speaking out against people who, while advocating the use of libre/open source code in automotive solutions, decry the use of GPLv3 (as opposed to v2). The author suggests that the people opposed to the use of GPLv3 are making false arguments on the grounds of safety. The relevant difference being that GPLv3 requires not only the release of code, but the ability to use modified versions of code in situ. E.g., by replacing your car's firmware.
yuhong 10y ago
This ignore the issue of actually modifying the software.
- phire 10y ago
  Proprietary software doesn't stop people modifying software, it only slows them down. And it doesn't slow people down anywhere near enough, hence all the talk about DRM, encryption, warranty voiding and anti-convention laws. There is nothing wrong with allowing people to modify software, the issue is when people modify software to break laws (environmental law, in this case). The solution is going to be some form of compliance certification/testing. The Manufacture provides the default software and gained a certification to prove it compiles with the laws. If the user wants to modify the software, they are going to have to prove that the replacement software also complies with the laws and get a certificate. During annual vehicle inspections or licensing, they can check that certified software is installed. Or maybe the ECU's bootloader only allows certified software to be installed, unless a developer mode is enabled (which will require the owner to keep logs to ensure compliance)
  - yuhong 10y ago
    GPLv3 is stricter about this than GPLv2 though.
    - phire 10y ago
      So if a company tried to apply "Your code must meet emissions standards before you are allowed to install it" limitations via a license agreement, then it would conflict with both GPLv2 and v3. If a company only allowed you to instal after being signed by the company's own testing laboratories, it would conflict with GPLv3's TIVOization clauses. But if the government says: "All software installed on car ECUs must meet emissions standards" then there is no conflict, infact this is already 'implied' by the current laws. The GPLv3 'should' also be fine with a "All car ECUs must only accept software that is signed and approved by a 3rd party testing laboratory" law. You have the exact same barrier to installing software on the ECU as the actual manufacture of the car. The main example where the GPLv3 might conflict with a government law, is when a law mandates "the car's ECU must be locked down in a way that only the original manufacture can change the software"
  - tigershark 10y ago
    How can you certify a neural network? If it was feasible you wouldn't need a neural network in the first place, because if the problem could be solved exactly with a well known and certified algorithm then why add the "uncertain" response of a NN?
    - chris_wot 10y ago
      Wha is it with you and neural networks? What's that got to do with anything?
      - tigershark 10y ago
        In the linked article the author says that the death of the person on the tesla with autopilot could have been avoided if the autopilot software was open source. That is simply absolutely false because you cannot ever certify the entire response mapping for a NN so complex. And even if you could then there was no need for a NN because you could write an algorithm with exactly the same response mapping.
Godel_unicode 10y ago
The author asks for evidence of GPLv3 software hurting people. This includes the Linux kernel, for which there are many examples of incidents. The below was the first I found[1] and it has the benefit of involving multiple open-source projects under different licenses. The idea that software is inherently safer because it's released under an open-source license is overly simplistic in the extreme. Just the most obvious reason for this is that opportunity for independent review doesn't guarantee that review will happen. The wisdom of the crowd doesn't guarantee a third party review will be better or more thorough than a solid first party system. Open-source provides the possibility of review, and that's all. Hypothetical eyes make no bugs shallow. Edit - I'm not making a claim one way or the other about the relative safety of open vs proprietary software, I'm merely saying that the comparison is deeper and more nuanced than the way it is typically portrayed. 1 - http://www.bbc.com/news/technology-28867113 http://www.bbc.com/news/technology-28867113
- ktRolster 10y ago
  With open source software, you have the possibility of knowing how safe it is. With closed source, you don't (ok, it's a lot harder to read through binaries, but still vaguely possible).
  - tigershark 10y ago
    No way that you can understand how safe is the neural network that is driving your car. And this applies equally to open source autopilot systems and closed ones. The article is just a rant that misses this fundamental point.
    - chmars 10y ago
      I cannot, others can - I can even pay them to do if necessary.
      - tigershark 10y ago
        No one can. If anyone could certify the neural network entire response mapping then you could simply write an exact algorithm with the same responses. Good luck for doing it to automatically drive a car. Strangely every company in the world is focusing on NN for autopilot, not on hand written algorithms.
Aloha 10y ago
Both arguments are hyperbolic. Both propriety and open source software has likely killed people, and likely will do so again. No amount of eyeballs will help if no one is looking, nor will hiding all the bad code away so no one can see it. Bad engineering practice is bad engineering practice.
- bkuhn 10y ago
  I say clearly in the blog post that there is danger when you have software handle any life-critical service. The criticism I'm making in the blog post is the arguments by the auto-industry and their providers that FLOSS is inherently more dangerous than proprietary software.
- deleted 10y ago
  [deleted]
zaidf 10y ago
Password is the ultimate form of security through obscurity.
- __david__ 10y ago
  a) You apparently did not read the article. b) Passwords are not "obscurity", they are "secrets". "Obscurity" in this context is about cryptographic algorithms/systems.
dagaci 10y ago
The idea of "Security Through Obscurity Kills People" as a bad thing is a very catchy phrase and great rhetoric. However it is also one of those statements which lowers the critical thinking and allows people to talk without producing stats or facts or demarcations of when a idea should apply or not apply. For example we told repeatedly to use obscure passwords, lock our phones and tablets with 4 digit numbers, and even swiping-the-screen-gestures, bank account information is protected by numbers and password! And all this in most cases is an obscurity scheme, and that obscurity scheme is our single point of security failure before complete systems access. "Heartbleed" was present in OpenSSL for over decade, out in the open and nothing detected. ... p.s. slightly off-topic, but can you accurately count the number of ball passes? https://www.youtube.com/watch?v=47LCLoidJh4 https://www.youtube.com/watch?v=47LCLoidJh4
- greenleafjacob 10y ago
  The 4 digit PIN is rate limited. How is that a single point of failure?
  - phreeza 10y ago
    For example if someone skims the code.
- Drdrdrq 10y ago
  You misunderstood the term "obscurity" in this context. Of course there is something that identifies some user (sth. he knows / sth. he has), but "security through obscurity" denotes practices of hiding the way authentication process is planned / implemented. This hiding usually at best makes no difference to the safety of the system, but often actually lowers it. One of the reasons is because it makes it harder for independent security researchers to review it. Of course there are secrets in any access to a secure system. But they should be only those parts which are user specific (passwords, keys,...).
- em3rgent0rdr 10y ago
  Open security says everything except the key is known. But the actual key is private.
nickpsecurity 10y ago
"Meanwhile, there has been not a single example yet about use of GPLv3 software that has harmed anyone." What!? That's dishonest. Most people doing safety-critical development use robust tooling intended for it instead of FOSS. Or stuck with proprietary tools attached to their platforms. So, FOSS will hardly cause harm by definition just because so little use. Kind of like how Mac OS 9 and Amiga are secure because you see no huge botnets. ;) Far as harm, it's done plenty. Most GPL software, just like proprietary, is of crap quality. I've lost years of data to open-source solution. Many people were hacked due to FOSS solutions where "many eyeballs" didn't even try to look for problems. Extrapolate that to cars, planes, and trains. Then think if you want to use one afterwards. I won't. Give me DO-178B Level B/A software over that any day. "until you can prove that proprietary software assures safety in a way that FLOSS cannot" Wait, has this author heard of DO-178B and related standards? They do exactly what he says. All are proprietary, too, although could be FOSS'd. How about FOSS software people put their stuff through rigorous prevention and 3rd party evaluation process before expecting us to believe its high quality or safe? Cuts both ways. I do know a handfull that would make the cut. Need exceptions for OSS like that. Most won't, though.
nxzero 10y ago
Arguing over if code being publicly readable makes the code more secure is obviously BS. Case in point, take code which is closed source, make it open source, and it magically does not become more secure. Security of code depends of the effort made to make it secure; aka more eye balls, more secure.
aaron695 10y ago
I have a rule, if you mention Therac 25 then you lose. It's a cliche. If it was an example of a common problem then it wouldn't have to be mentioned every single time.
- Flimm 10y ago
  Hmm, just because it's mentioned frequently doesn't necessarily mean that it should be dismissed or deserve an automatic "you lose". It doesn't necessarily mean that other instances of the same problem aren't common or couldn't happen again, but it could mean that that particular instance is the most famous. Your so-called "rule" is a faulty mental shortcut.
- RaleyField 10y ago
  > then you lose You disengage and don't necessarily convince anyone of anything (i.e. "win"). > If it was an example of a common problem It is arguably common enough problem for reasonable definitions of common in its context. Hackable cars across the industry shows that people still haven't learned their lessons. The fact that people haven't died as often in these situations shouldn't have a bearing on arguments against closed systems if flaws are only potentially fatal.
limaoscarjuliet 10y ago
I agree open source software has more chance of being safer, but the article does not do good job of arguing it. Anecdotal evidence fallacy is not good science, e.g. "Meanwhile, there has been not a single example yet about use of GPLv3 software that has harmed anyone".
slavik81 10y ago
Do open source developers actually want to take on the liability that comes from distributing software for use in safety-critical environments? One mistake could leave someone with a lifetime of medical bills, and they'll sue anyone with money involved in it.
- aylons 10y ago
  You don't seem to realize that the software license means no warranty, but that does not preclude anyone from giving support and warranty on the product. So yes, GPL'ed software may be used on critical applications the same way as every other piece of hardware and software: via special contracts.
  - slavik81 10y ago
    I realise that. Hell, I've done that. As a licensed engineer, I would just be very concerned about contributing to an open source project that controlled critical systems in cars. That sounds like all the liability of my actual employment, but none of the pay.
    - aylons 10y ago
      Unauthorized use of your code or product for uncovered applications is a problem no matter if the source code is open or not. Companies exclude themselves from such liability as a matter of policy, demanding special contracts on these cases. If you get any IC datasheet, or even an application-specific brochure such as (1), you will see a notice saying explicitly that. (1)http://www.ti.com/lit/slyb108 http://www.ti.com/lit/slyb108
IncRnd 10y ago
You are arguing things you do not fully know. If you want open source examples, goto fail; was in open source. Can you quantify how many MiTMs happened? Stuxnet had open source for PLC infection. That could have wounded some people. Heartbleed was in open source. Guess how many times that was exploited by governments with sensitive information disclosed? The list of open source failures is long. It is not true in and of itself that the open source "more eyes" argument is correct. Do you audit the source code of everything you compile for security issues? One could convincingly argue, just based upon DROWN, FREAK, Logjam, and POODLE that code in the open doesn't get inspected and those who do inspect it miss an extensive number of security issues. I'm not sure how many people were harmed by this bug in MRI software, but the bug resulted in false positive rates of up to 70% http://www.theregister.co.uk/2016/07/03/mri_software_bugs_could_upend_years_of_research/ http://www.theregister.co.uk/2016/07/03/mri_software_bugs_co...
_ph_ 10y ago
There seem to be many different topics involved. First of all open vs. closed source, and GPL V3 vs other versions of open source licenses. In general, I would say that open source is preferable to closed source, but there are situations, where this is not always possible for the producing companies. Finally, there is the problem, that if the owner of the car is free to modify his cars software (which in abstract sounds like something he should be able to), there is the problem of people modifying the software of their car, which should not. One should not just tinker with the algorithms used to control the engine, breaking and stability control.
- halomru 10y ago
  >there is the problem of people modifying the software of their car, which should not. One should not just tinker with the algorithms used to control the engine, breaking and stability control. Why is that a problem that has to be solved? In purely mechanical cars, people already can and do tinker with the engine and breaks. But only a tiny fraction of people do, and those usually take care not to risk their lives. In the limited cases where modifications cause problems for other people, regulations are enforced through scheduled inspections and random stops of suspicious vehicles. This system has worked quite well for the last hundred years or so. If software really is different and shouldn't be modifiable, I think this needs a little more justification.
  - _ph_ 10y ago
    First of all, I trust a somewhat skilled mechanic more to get his car modifications reasonably safe, than a random software modification. Then, there is the problem, that mechanic parts are easy to inspect - many improper modifications can be seen at a glance in a traffic control - software modifications are pretty impossible to detect. Short of checksumming the whole car software, it cannot be done.
    - wtbob 10y ago
      > I trust a somewhat skilled mechanic more to get his car modifications reasonably safe, than a random software modification Those are not comparable things. The correct comparison is between a mechanic and a programmer (after all, anyone who modifies his software is a programmer, perhaps an unskilled one), or between an automotive part and a piece of code. Using the correct comparison, we see that we already permit anyone to work on his own vehicle, and that he can put anything in it he wishes. Software should be no different. > Then, there is the problem, that mechanic parts are easy to inspect Some of them are. Some look just like the correct parts, but were manufactured to incorrect tolerances. These parts wouldn't be obvious in a visual inspection. > software modifications are pretty impossible to detect. Short of checksumming the whole car software, it cannot be done. Software hashes aren't rocket science: your post & mine were both hashed at least one. Indeed, software hashes make detecting changed software easier than detecting swapped physical parts.
EGreg 10y ago
Open source is better for some things, but security isn't one of them. I say this as a developer of an open source platform. When it's just starting out, it has the same number of holes as anything else -- but everyone can see the code and find the holes. It takes years, and hundreds of man-years, to find and fix 99% of the holes. Until then, the source code is all in the open, making it an easier target for an attacker than a closed-source product. In thw latter, you just have to close the "obvious" holes. True, with very old or well-funded open-source products, this is not the case. But MOST open source software isn't like that.
- temac 10y ago
  It might slightly slow-down a motivated and competent attacker to not have the source. But it also very highly slow down discovery of some bugs by non-hardcore security researchers, most especially security bugs.
PinguTS 10y ago
The author is arguing wrong. Because especially automotive is not about security, it is a about safety. That said, security can influence safety, but the goal is completely different. A system is considered functionally safe, when any unexpected input lead to an situation where the system safely shut down. So it does not matter if we have real security or security by obscurity. Because if something unexpected happens, the systems shut down and becomes unavailable. That is what we have in general automation. The same applies for a railway. If something happens then the system shuts down, an emergency brake is issued. That works, because there is a higher level safety designed in, that the currently occupied rail is blocked and no other railway can enter. Then we have highly available systems, or mission cirtical systems as we say. That is for example an airplan or a car. The engine of a car can shut down at any time. That is not considered harmful. But the brakes are mission critical. The brakes have to work under all circumstances. As such safety-related systems are highly regulated and require mandatory third party review called certification. You need to certify with TUV or other such organisation. Part of that mandatory review is to disclose the source. That means the review argument for GPLv3 is obsolete, as there is mandatory review for safety-related systems. The license of the software does not matter. The author then argues, that the Tesla incident would not have happend with GPLv3 software. He argues, it happend because of proprietary software. Which is wrong. It would have happend as well with GPLv3 software. This incident happend because of false claims by Tesla. This systems was never designed to handled this kind of situation. MobilEye, the supplier behind this system said, this kind of situation should be handled by the 2018 version. Tesla gave here a false impression about the completeness and safety features of its Autopilot. BTW the same Tesla that uses GPLv3 software in its MMI, which they have locked down. Then the author argues with VW and thier false claims regarding emissions. As prooven, the ECU came from Bosch with proprietary software. The same ECU is used by many different OEMs and Bosch does not disclose the inner working, as this is the idea that Bosch sells. Even VW does not had the source, but used the ECU in a testing mode. So the problem here is also only partly related to the licensensing of the software. It is more like you can use software for the good cause and the bade cause. Either way it is not related to licensing. The argument that GPLv3 code is reviewed is also unproven and even sometimes wrong. In the past there are several example where review didn't take place. It was more like "yeah, I think someone has reviewed because it is open source and I could too. But why to waste time and instead build on top of it." So, GPLv3 can lead you to false assumptions. Except, you will really do the review your self. Here it comes the question: how many really have done that in their past?
AsyncAwait 10y ago
I don't see the author arguing that being open makes software inherently more secure, but that your software shouldn't rely on being 'secure' because it's closed source, rather design the software to be secure even if the source code were to be open-sourced, which may bring additional eyes, (and if not, it's no worse than if it was closed). I don't know if anyone has a good argument against that, but I didn't see one yet. It's not an argument to say that open-source makes your software bulletproof or even safer just by being open-source, rather if you designed your software with proper security as a goal, you shouldn't mind releasing your code.
arca_vorago 10y ago
I'm going to skip the main points everyone else is hitting (because I've been touting gplv3 for a while), and get straight to what I think is the most important part of the evolution of foss. I think FoSS is the way to go, but, I think the main problem is with the many eyes theory. To cut to the chase, I think the future of code lies in loc reduction and simplification of code in order to combat the problem of too much complexity. The linux kernel is now at 10million loc +! I dont care if you are Red Hat, you dont have enough eyeballs to properly audit that shit! Thats what I think the future of software should be, is simplification of code, maybe some refactoring, so that the barrier for average user to look at and understand the code is lowered. That and perhaps an AI/machine learning code reviewing system that can perform the function for those not able but that still want the benefits of foss.
- zdw 10y ago
  > The linux kernel is now at 10million loc +! I dont care if you are Red Hat, you dont have enough eyeballs to properly audit that shit! To be fair, most of that is in device drivers and other optionally compiled or non-critical pieces of code. The common code path is extremely well tested and audited.
  - archimedespi 10y ago
    Exactly. I see so many people complaining about the Linux kernel SLOC versus other kernels; it's an unfair comparison because no other modern kernel I know of has such a wide selection of in-tree drivers. For instance, when I install Windows on a computer, I will often have to install additional chipset drivers (odd USB3.0 controller, motherboard chipset stuff, fan control). When I install Linux, all of that stuff works out of the box, no drivers necessary: it's rolled right into the kernel.
bkuhn 10y ago
It seems that most commenting in this thread don't have not actually followed the complex political debate going on in the world of automotive industry adoption of FLOSS. Specifically, the automotive industry has made a series of arguments that proprietary software is ultimately safer than FLOSS, and all their goals are to lock-down FLOSS in various ways to prevent the nefarious from "hacking" the vehicle. The vehicles are all still hackable, and many have been modified by people for both reasonable and nefarious purposes. The FLOSS situation won't change anything, and there aren't even any examples yet of hacks where FLOSS made the situation worse. It's an assumption they make without full information because of their inherent pro-proprietary bias.
qwertyuiop924 10y ago
The author of this post is right, to a degree, but his arguments are really weak. Here's it simply: -With OSS, your bugs are more likely to be caught. -Therefore, it's harder to maliciously hack the vehicle. -Therefore, it's less likely the software will fail and kill someone. -Therefore, not opensourcing your code is a liability, because not doing so makes your product killing someone more likely. Or the auto companies could just admit the real reason why they don't want to OS their code: They're afraid of losing control of their product. Of people, even if they've voided the warantee, using their product in ways they didn't explicitly allow. Of losing their monopoly on support. If you're going to be evil, at least give it to us straight...
- eridius 10y ago
  Your first claim is not true. What makes bugs more likely to be caught is having lots of eyes on the source. If you have a popular OSS project there's probably a bunch of people looking at it. But making something OSS does not guarantee that anyone will look at it. Meanwhile, proprietary software will still be examined by everyone who's paid to work on it. So really, the value of OSS in catching bugs is related to how interesting/popular the software is. Boring software is rather unlikely to catch many bugs by being OSS.
  - qwertyuiop924 10y ago
    But the probabilty of people outside your org looking at your source if it's proprietary is zero. Said probability is nonzero for OSS. So yes, even in a low popularity OS project, there's a higher probability of more people setting eyes on it than proprietary software.
  - qwertyuiop924 10y ago
    In this case, I was using eyes as a shorthand, but yes, you are correct.
mwfunk 10y ago
I don't think that one unprovable assertion ("GPLv3 software has never killed anyone") is the best way to combat someone else's unprovable assertion ("our cars would be less secure if everyone could see our code"). The only way to argue against security through obscurity is to argue against security through obscurity, although admittedly that can be tough depending on the audience. Fighting against the status quo is just going to be an uphill battle sometimes, it's the nature of the beast. This sounds more like a rhetorical device, in which debater #1 has attempted to frame the debate in terms of debater #1 being correct unless debater #2 can prove that they're wrong. Debater #2 then tries to reframe the terms of the debate such that debater #2 is right until proven wrong by debater #1. In both cases it's more a form of sophistry vs. an opponent than it is a way to make a case to the public. Using a dishonest rhetorical device to counteract someone else's dishonest rhetorical device rubs me the wrong way, because it feels like both sides are trying to twist facts in their favor, and are not in good faith trying convince me that they're right and the other person is wrong. Debater #2 is responding to sophistry with more sophistry, rather than attacking debater #1's sophistry head-on.

192 points by ashitlerferad 10y ago

>The time has come that I must speak out against the inappropriate rhetoric used by those who (ostensibly) advocate for FLOSS usage in automotive applications. You mean used against?

TickleSteve 10y ago
nonsensical rant is nonsensical....
Leynos 10y ago
The author appears to be speaking out against people who, while advocating the use of libre/open source code in automotive solutions, decry the use of GPLv3 (as opposed to v2). The author suggests that the people opposed to the use of GPLv3 are making false arguments on the grounds of safety. The relevant difference being that GPLv3 requires not only the release of code, but the ability to use modified versions of code in situ. E.g., by replacing your car's firmware.

yuhong 10y ago

This ignore the issue of actually modifying the software.

phire 10y ago
Proprietary software doesn't stop people modifying software, it only slows them down. And it doesn't slow people down anywhere near enough, hence all the talk about DRM, encryption, warranty voiding and anti-convention laws. There is nothing wrong with allowing people to modify software, the issue is when people modify software to break laws (environmental law, in this case). The solution is going to be some form of compliance certification/testing. The Manufacture provides the default software and gained a certification to prove it compiles with the laws. If the user wants to modify the software, they are going to have to prove that the replacement software also complies with the laws and get a certificate. During annual vehicle inspections or licensing, they can check that certified software is installed. Or maybe the ECU's bootloader only allows certified software to be installed, unless a developer mode is enabled (which will require the owner to keep logs to ensure compliance)
- yuhong 10y ago
  GPLv3 is stricter about this than GPLv2 though.
  - phire 10y ago
    So if a company tried to apply "Your code must meet emissions standards before you are allowed to install it" limitations via a license agreement, then it would conflict with both GPLv2 and v3. If a company only allowed you to instal after being signed by the company's own testing laboratories, it would conflict with GPLv3's TIVOization clauses. But if the government says: "All software installed on car ECUs must meet emissions standards" then there is no conflict, infact this is already 'implied' by the current laws. The GPLv3 'should' also be fine with a "All car ECUs must only accept software that is signed and approved by a 3rd party testing laboratory" law. You have the exact same barrier to installing software on the ECU as the actual manufacture of the car. The main example where the GPLv3 might conflict with a government law, is when a law mandates "the car's ECU must be locked down in a way that only the original manufacture can change the software"
- tigershark 10y ago
  How can you certify a neural network? If it was feasible you wouldn't need a neural network in the first place, because if the problem could be solved exactly with a well known and certified algorithm then why add the "uncertain" response of a NN?
  - chris_wot 10y ago
    Wha is it with you and neural networks? What's that got to do with anything?
    - tigershark 10y ago
      In the linked article the author says that the death of the person on the tesla with autopilot could have been avoided if the autopilot software was open source. That is simply absolutely false because you cannot ever certify the entire response mapping for a NN so complex. And even if you could then there was no need for a NN because you could write an algorithm with exactly the same response mapping.

Godel_unicode 10y ago

The author asks for evidence of GPLv3 software hurting people. This includes the Linux kernel, for which there are many examples of incidents. The below was the first I found[1] and it has the benefit of involving multiple open-source projects under different licenses. The idea that software is inherently safer because it's released under an open-source license is overly simplistic in the extreme. Just the most obvious reason for this is that opportunity for independent review doesn't guarantee that review will happen. The wisdom of the crowd doesn't guarantee a third party review will be better or more thorough than a solid first party system. Open-source provides the possibility of review, and that's all. Hypothetical eyes make no bugs shallow. Edit - I'm not making a claim one way or the other about the relative safety of open vs proprietary software, I'm merely saying that the comparison is deeper and more nuanced than the way it is typically portrayed. 1 - http://www.bbc.com/news/technology-28867113 http://www.bbc.com/news/technology-28867113

ktRolster 10y ago
With open source software, you have the possibility of knowing how safe it is. With closed source, you don't (ok, it's a lot harder to read through binaries, but still vaguely possible).
- tigershark 10y ago
  No way that you can understand how safe is the neural network that is driving your car. And this applies equally to open source autopilot systems and closed ones. The article is just a rant that misses this fundamental point.
  - chmars 10y ago
    I cannot, others can - I can even pay them to do if necessary.
    - tigershark 10y ago
      No one can. If anyone could certify the neural network entire response mapping then you could simply write an exact algorithm with the same responses. Good luck for doing it to automatically drive a car. Strangely every company in the world is focusing on NN for autopilot, not on hand written algorithms.

Aloha 10y ago

Both arguments are hyperbolic. Both propriety and open source software has likely killed people, and likely will do so again. No amount of eyeballs will help if no one is looking, nor will hiding all the bad code away so no one can see it. Bad engineering practice is bad engineering practice.

bkuhn 10y ago
I say clearly in the blog post that there is danger when you have software handle any life-critical service. The criticism I'm making in the blog post is the arguments by the auto-industry and their providers that FLOSS is inherently more dangerous than proprietary software.
deleted 10y ago
[deleted]

zaidf 10y ago

Password is the ultimate form of security through obscurity.

__david__ 10y ago
a) You apparently did not read the article. b) Passwords are not "obscurity", they are "secrets". "Obscurity" in this context is about cryptographic algorithms/systems.

dagaci 10y ago

The idea of "Security Through Obscurity Kills People" as a bad thing is a very catchy phrase and great rhetoric. However it is also one of those statements which lowers the critical thinking and allows people to talk without producing stats or facts or demarcations of when a idea should apply or not apply. For example we told repeatedly to use obscure passwords, lock our phones and tablets with 4 digit numbers, and even swiping-the-screen-gestures, bank account information is protected by numbers and password! And all this in most cases is an obscurity scheme, and that obscurity scheme is our single point of security failure before complete systems access. "Heartbleed" was present in OpenSSL for over decade, out in the open and nothing detected. ... p.s. slightly off-topic, but can you accurately count the number of ball passes? https://www.youtube.com/watch?v=47LCLoidJh4 https://www.youtube.com/watch?v=47LCLoidJh4

greenleafjacob 10y ago
The 4 digit PIN is rate limited. How is that a single point of failure?
- phreeza 10y ago
  For example if someone skims the code.
Drdrdrq 10y ago
You misunderstood the term "obscurity" in this context. Of course there is something that identifies some user (sth. he knows / sth. he has), but "security through obscurity" denotes practices of hiding the way authentication process is planned / implemented. This hiding usually at best makes no difference to the safety of the system, but often actually lowers it. One of the reasons is because it makes it harder for independent security researchers to review it. Of course there are secrets in any access to a secure system. But they should be only those parts which are user specific (passwords, keys,...).
em3rgent0rdr 10y ago
Open security says everything except the key is known. But the actual key is private.

nickpsecurity 10y ago

"Meanwhile, there has been not a single example yet about use of GPLv3 software that has harmed anyone." What!? That's dishonest. Most people doing safety-critical development use robust tooling intended for it instead of FOSS. Or stuck with proprietary tools attached to their platforms. So, FOSS will hardly cause harm by definition just because so little use. Kind of like how Mac OS 9 and Amiga are secure because you see no huge botnets. ;) Far as harm, it's done plenty. Most GPL software, just like proprietary, is of crap quality. I've lost years of data to open-source solution. Many people were hacked due to FOSS solutions where "many eyeballs" didn't even try to look for problems. Extrapolate that to cars, planes, and trains. Then think if you want to use one afterwards. I won't. Give me DO-178B Level B/A software over that any day. "until you can prove that proprietary software assures safety in a way that FLOSS cannot" Wait, has this author heard of DO-178B and related standards? They do exactly what he says. All are proprietary, too, although could be FOSS'd. How about FOSS software people put their stuff through rigorous prevention and 3rd party evaluation process before expecting us to believe its high quality or safe? Cuts both ways. I do know a handfull that would make the cut. Need exceptions for OSS like that. Most won't, though.

nxzero 10y ago

Arguing over if code being publicly readable makes the code more secure is obviously BS. Case in point, take code which is closed source, make it open source, and it magically does not become more secure. Security of code depends of the effort made to make it secure; aka more eye balls, more secure.

aaron695 10y ago

I have a rule, if you mention Therac 25 then you lose. It's a cliche. If it was an example of a common problem then it wouldn't have to be mentioned every single time.

Flimm 10y ago
Hmm, just because it's mentioned frequently doesn't necessarily mean that it should be dismissed or deserve an automatic "you lose". It doesn't necessarily mean that other instances of the same problem aren't common or couldn't happen again, but it could mean that that particular instance is the most famous. Your so-called "rule" is a faulty mental shortcut.
RaleyField 10y ago
> then you lose You disengage and don't necessarily convince anyone of anything (i.e. "win"). > If it was an example of a common problem It is arguably common enough problem for reasonable definitions of common in its context. Hackable cars across the industry shows that people still haven't learned their lessons. The fact that people haven't died as often in these situations shouldn't have a bearing on arguments against closed systems if flaws are only potentially fatal.

limaoscarjuliet 10y ago

I agree open source software has more chance of being safer, but the article does not do good job of arguing it. Anecdotal evidence fallacy is not good science, e.g. "Meanwhile, there has been not a single example yet about use of GPLv3 software that has harmed anyone".

slavik81 10y ago

Do open source developers actually want to take on the liability that comes from distributing software for use in safety-critical environments? One mistake could leave someone with a lifetime of medical bills, and they'll sue anyone with money involved in it.

aylons 10y ago
You don't seem to realize that the software license means no warranty, but that does not preclude anyone from giving support and warranty on the product. So yes, GPL'ed software may be used on critical applications the same way as every other piece of hardware and software: via special contracts.
- slavik81 10y ago
  I realise that. Hell, I've done that. As a licensed engineer, I would just be very concerned about contributing to an open source project that controlled critical systems in cars. That sounds like all the liability of my actual employment, but none of the pay.
  - aylons 10y ago
    Unauthorized use of your code or product for uncovered applications is a problem no matter if the source code is open or not. Companies exclude themselves from such liability as a matter of policy, demanding special contracts on these cases. If you get any IC datasheet, or even an application-specific brochure such as (1), you will see a notice saying explicitly that. (1)http://www.ti.com/lit/slyb108 http://www.ti.com/lit/slyb108

IncRnd 10y ago

You are arguing things you do not fully know. If you want open source examples, goto fail; was in open source. Can you quantify how many MiTMs happened? Stuxnet had open source for PLC infection. That could have wounded some people. Heartbleed was in open source. Guess how many times that was exploited by governments with sensitive information disclosed? The list of open source failures is long. It is not true in and of itself that the open source "more eyes" argument is correct. Do you audit the source code of everything you compile for security issues? One could convincingly argue, just based upon DROWN, FREAK, Logjam, and POODLE that code in the open doesn't get inspected and those who do inspect it miss an extensive number of security issues. I'm not sure how many people were harmed by this bug in MRI software, but the bug resulted in false positive rates of up to 70% http://www.theregister.co.uk/2016/07/03/mri_software_bugs_could_upend_years_of_research/ http://www.theregister.co.uk/2016/07/03/mri_software_bugs_co...

_ph_ 10y ago

There seem to be many different topics involved. First of all open vs. closed source, and GPL V3 vs other versions of open source licenses. In general, I would say that open source is preferable to closed source, but there are situations, where this is not always possible for the producing companies. Finally, there is the problem, that if the owner of the car is free to modify his cars software (which in abstract sounds like something he should be able to), there is the problem of people modifying the software of their car, which should not. One should not just tinker with the algorithms used to control the engine, breaking and stability control.

halomru 10y ago
>there is the problem of people modifying the software of their car, which should not. One should not just tinker with the algorithms used to control the engine, breaking and stability control. Why is that a problem that has to be solved? In purely mechanical cars, people already can and do tinker with the engine and breaks. But only a tiny fraction of people do, and those usually take care not to risk their lives. In the limited cases where modifications cause problems for other people, regulations are enforced through scheduled inspections and random stops of suspicious vehicles. This system has worked quite well for the last hundred years or so. If software really is different and shouldn't be modifiable, I think this needs a little more justification.
- _ph_ 10y ago
  First of all, I trust a somewhat skilled mechanic more to get his car modifications reasonably safe, than a random software modification. Then, there is the problem, that mechanic parts are easy to inspect - many improper modifications can be seen at a glance in a traffic control - software modifications are pretty impossible to detect. Short of checksumming the whole car software, it cannot be done.
  - wtbob 10y ago
    > I trust a somewhat skilled mechanic more to get his car modifications reasonably safe, than a random software modification Those are not comparable things. The correct comparison is between a mechanic and a programmer (after all, anyone who modifies his software is a programmer, perhaps an unskilled one), or between an automotive part and a piece of code. Using the correct comparison, we see that we already permit anyone to work on his own vehicle, and that he can put anything in it he wishes. Software should be no different. > Then, there is the problem, that mechanic parts are easy to inspect Some of them are. Some look just like the correct parts, but were manufactured to incorrect tolerances. These parts wouldn't be obvious in a visual inspection. > software modifications are pretty impossible to detect. Short of checksumming the whole car software, it cannot be done. Software hashes aren't rocket science: your post & mine were both hashed at least one. Indeed, software hashes make detecting changed software easier than detecting swapped physical parts.

EGreg 10y ago

Open source is better for some things, but security isn't one of them. I say this as a developer of an open source platform. When it's just starting out, it has the same number of holes as anything else -- but everyone can see the code and find the holes. It takes years, and hundreds of man-years, to find and fix 99% of the holes. Until then, the source code is all in the open, making it an easier target for an attacker than a closed-source product. In thw latter, you just have to close the "obvious" holes. True, with very old or well-funded open-source products, this is not the case. But MOST open source software isn't like that.

temac 10y ago
It might slightly slow-down a motivated and competent attacker to not have the source. But it also very highly slow down discovery of some bugs by non-hardcore security researchers, most especially security bugs.

PinguTS 10y ago

The author is arguing wrong. Because especially automotive is not about security, it is a about safety. That said, security can influence safety, but the goal is completely different. A system is considered functionally safe, when any unexpected input lead to an situation where the system safely shut down. So it does not matter if we have real security or security by obscurity. Because if something unexpected happens, the systems shut down and becomes unavailable. That is what we have in general automation. The same applies for a railway. If something happens then the system shuts down, an emergency brake is issued. That works, because there is a higher level safety designed in, that the currently occupied rail is blocked and no other railway can enter. Then we have highly available systems, or mission cirtical systems as we say. That is for example an airplan or a car. The engine of a car can shut down at any time. That is not considered harmful. But the brakes are mission critical. The brakes have to work under all circumstances. As such safety-related systems are highly regulated and require mandatory third party review called certification. You need to certify with TUV or other such organisation. Part of that mandatory review is to disclose the source. That means the review argument for GPLv3 is obsolete, as there is mandatory review for safety-related systems. The license of the software does not matter. The author then argues, that the Tesla incident would not have happend with GPLv3 software. He argues, it happend because of proprietary software. Which is wrong. It would have happend as well with GPLv3 software. This incident happend because of false claims by Tesla. This systems was never designed to handled this kind of situation. MobilEye, the supplier behind this system said, this kind of situation should be handled by the 2018 version. Tesla gave here a false impression about the completeness and safety features of its Autopilot. BTW the same Tesla that uses GPLv3 software in its MMI, which they have locked down. Then the author argues with VW and thier false claims regarding emissions. As prooven, the ECU came from Bosch with proprietary software. The same ECU is used by many different OEMs and Bosch does not disclose the inner working, as this is the idea that Bosch sells. Even VW does not had the source, but used the ECU in a testing mode. So the problem here is also only partly related to the licensensing of the software. It is more like you can use software for the good cause and the bade cause. Either way it is not related to licensing. The argument that GPLv3 code is reviewed is also unproven and even sometimes wrong. In the past there are several example where review didn't take place. It was more like "yeah, I think someone has reviewed because it is open source and I could too. But why to waste time and instead build on top of it." So, GPLv3 can lead you to false assumptions. Except, you will really do the review your self. Here it comes the question: how many really have done that in their past?

AsyncAwait 10y ago

I don't see the author arguing that being open makes software inherently more secure, but that your software shouldn't rely on being 'secure' because it's closed source, rather design the software to be secure even if the source code were to be open-sourced, which may bring additional eyes, (and if not, it's no worse than if it was closed). I don't know if anyone has a good argument against that, but I didn't see one yet. It's not an argument to say that open-source makes your software bulletproof or even safer just by being open-source, rather if you designed your software with proper security as a goal, you shouldn't mind releasing your code.

arca_vorago 10y ago

I'm going to skip the main points everyone else is hitting (because I've been touting gplv3 for a while), and get straight to what I think is the most important part of the evolution of foss. I think FoSS is the way to go, but, I think the main problem is with the many eyes theory. To cut to the chase, I think the future of code lies in loc reduction and simplification of code in order to combat the problem of too much complexity. The linux kernel is now at 10million loc +! I dont care if you are Red Hat, you dont have enough eyeballs to properly audit that shit! Thats what I think the future of software should be, is simplification of code, maybe some refactoring, so that the barrier for average user to look at and understand the code is lowered. That and perhaps an AI/machine learning code reviewing system that can perform the function for those not able but that still want the benefits of foss.

zdw 10y ago
> The linux kernel is now at 10million loc +! I dont care if you are Red Hat, you dont have enough eyeballs to properly audit that shit! To be fair, most of that is in device drivers and other optionally compiled or non-critical pieces of code. The common code path is extremely well tested and audited.
- archimedespi 10y ago
  Exactly. I see so many people complaining about the Linux kernel SLOC versus other kernels; it's an unfair comparison because no other modern kernel I know of has such a wide selection of in-tree drivers. For instance, when I install Windows on a computer, I will often have to install additional chipset drivers (odd USB3.0 controller, motherboard chipset stuff, fan control). When I install Linux, all of that stuff works out of the box, no drivers necessary: it's rolled right into the kernel.

bkuhn 10y ago

It seems that most commenting in this thread don't have not actually followed the complex political debate going on in the world of automotive industry adoption of FLOSS. Specifically, the automotive industry has made a series of arguments that proprietary software is ultimately safer than FLOSS, and all their goals are to lock-down FLOSS in various ways to prevent the nefarious from "hacking" the vehicle. The vehicles are all still hackable, and many have been modified by people for both reasonable and nefarious purposes. The FLOSS situation won't change anything, and there aren't even any examples yet of hacks where FLOSS made the situation worse. It's an assumption they make without full information because of their inherent pro-proprietary bias.

qwertyuiop924 10y ago

The author of this post is right, to a degree, but his arguments are really weak. Here's it simply: -With OSS, your bugs are more likely to be caught. -Therefore, it's harder to maliciously hack the vehicle. -Therefore, it's less likely the software will fail and kill someone. -Therefore, not opensourcing your code is a liability, because not doing so makes your product killing someone more likely. Or the auto companies could just admit the real reason why they don't want to OS their code: They're afraid of losing control of their product. Of people, even if they've voided the warantee, using their product in ways they didn't explicitly allow. Of losing their monopoly on support. If you're going to be evil, at least give it to us straight...

eridius 10y ago
Your first claim is not true. What makes bugs more likely to be caught is having lots of eyes on the source. If you have a popular OSS project there's probably a bunch of people looking at it. But making something OSS does not guarantee that anyone will look at it. Meanwhile, proprietary software will still be examined by everyone who's paid to work on it. So really, the value of OSS in catching bugs is related to how interesting/popular the software is. Boring software is rather unlikely to catch many bugs by being OSS.
- qwertyuiop924 10y ago
  But the probabilty of people outside your org looking at your source if it's proprietary is zero. Said probability is nonzero for OSS. So yes, even in a low popularity OS project, there's a higher probability of more people setting eyes on it than proprietary software.
- qwertyuiop924 10y ago
  In this case, I was using eyes as a shorthand, but yes, you are correct.

mwfunk 10y ago

I don't think that one unprovable assertion ("GPLv3 software has never killed anyone") is the best way to combat someone else's unprovable assertion ("our cars would be less secure if everyone could see our code"). The only way to argue against security through obscurity is to argue against security through obscurity, although admittedly that can be tough depending on the audience. Fighting against the status quo is just going to be an uphill battle sometimes, it's the nature of the beast. This sounds more like a rhetorical device, in which debater #1 has attempted to frame the debate in terms of debater #1 being correct unless debater #2 can prove that they're wrong. Debater #2 then tries to reframe the terms of the debate such that debater #2 is right until proven wrong by debater #1. In both cases it's more a form of sophistry vs. an opponent than it is a way to make a case to the public. Using a dishonest rhetorical device to counteract someone else's dishonest rhetorical device rubs me the wrong way, because it feels like both sides are trying to twist facts in their favor, and are not in good faith trying convince me that they're right and the other person is wrong. Debater #2 is responding to sophistry with more sophistry, rather than attacking debater #1's sophistry head-on.