What laws would you propose to eliminate insecure software?
https://www.schneier.com/essays/archives/2003/11/liability_c...
In summary, there wouldn't be liability for open source developers because there is no business contract. But if you run a website with open source software, you of course would still be liable for anything that happens to your customers' data. So you would probably want to buy that same open source software from someone (e.g. Red Hat), who would also be liable.
One of the worst ideas I've heard lately, and I am genuinely baffled how a person as smart and experienced as Schneier could support it.
The currently widespread practice of trusting sensitive user data to open source code without an audit (either internally or via a third-party, e.g. Red Hat) is horrifying and incredibly negligent.
If your business includes software in any meaningful function, you are making money from it. Any competent lawyer would be able to successfully argue that. Charging money for a license is not the only way, otherwise everybody would just switch to charging for "consultancy service", which coincidentally provides free software license, and avoid any liability.
> You would be free to publish software, open source or not, without incurring liability as long as you don't make money from it.
You as a private person would be. That's my point - that would be the only way to do open source, any corporate support of open source projects would imply full liability, which would be impossible for a product the company gets to revenue from. It would be much harder for a business to justify supporting an open source project when liability costs are added to the equation.
> The currently widespread practice of trusting sensitive user data to open source code without an audit (either internally or via a third-party, e.g. Red Hat) is horrifying
Audits cost money. Tons of money. And they don't guarantee anything - bugs in OpenSSL have not been discovered for years despite thousands of people using the code, poring over it and billions depending on it. There's no magic in "audit" that allows code to be bug-free after it - if there was such a magical procedure people would already be using it, but there's no indication anybody has invented "audit" procedure that allows to eliminate all bugs. Existing flawed procedures are already being used - every company that produces software that I ever heard about uses them - and they are not enough. So what would happen is drastically raising the costs (to the point where having a website would no longer be affordable to an average person) while not significantly improving security.
Any reasonable audit of OpenSSL would have said, "Don't use it."
http://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer-...
https://arstechnica.com/information-technology/2015/06/airbu...
https://en.wikipedia.org/wiki/Therac-25
https://en.wikipedia.org/wiki/Accidents_and_incidents_involv...
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_...
Did I make my point clear or do I need to google for another 2 minutes to find a dozen more examples of "aerospace and critical infrastructure projects" with software problems?
In practice, OpenSSL should not be considered secure. At best it can be considered as a way to stop script kiddies.
As others have said, this idea is really bad.
Red Hat will start charging obscene amounts to support the legal side of the license, especially if it is used in eCommerce platforms. What about the wife and husband who want to sell hand-knitted socks online, or small businesses who do less than $250k/year online? Will they be able to afford an alternative to the LAMP stack and fully shield themselves from legal liability and the horde of lawyers who will gladly step into any loophole?
Like many, my servers were affected by Heartbleed. So if I ran OpenSSL and someone found out before I patched it (took me 24h to do so), I could be sued in that window if I hadn't bought the license to Red Hat - oh, and how about all the licenses to all the open source software that depends on it underneath, OpenSSL being one of about a hundred of those projects? Do we license GNU toolchain? What if there are buffer overflow exploits found in various tools?
If mom and pop want to sell hand-knitted socks on the internet I usually recommend them to use a hosted shop solution such as shopify and its ilk. They want to sell socks, not become an expert in hosting a LAMP stack. This is how liability works for brick and mortar stores as well: They're liable if a customer electrocutes himself because some dork attached the wrong wire to the wrong metal part. That's why mom and pop stores in the brick and mortar part of the world usually don't do the electrical installation or any parts that's covered under a builder code. They hire people supposed to be experts in that field to do that work and in in turn, they get to discharge the liability to them. It's about time we treat software the same. If you want to host something, either own up to it or hire someone to do it.
Make the liability proportional to the degree to which you've given them the degree to find and fix any issues that might arise. If you give someone FOSS software to solve some particular problem, even a potentially-high-liability problem, you've given them everything they need to both analyze the software for potential issues, and fix them themselves. (Auto manufacturers like FOSS because it means they can always support it themselves if the vendor won't, and they have far longer support lifetimes than many other products.) So disclaiming all liability there seems reasonable, for anything short of intentional malice (e.g. backdoors).
On the other hand, if you give someone a piece of opaque proprietary software, then you're selling them a solution to a problem, and it'd better work because they can't do anything but go to you if it doesn't. They also can't introspect it, and black-box testing only goes so far. So this should increase liability. Even more so if you supply it in an obfuscated form that's difficult to reverse-engineer or test, or if you lock it down to make it irreplaceable.
The same thing would go for changing software yourself, on a high-liability device. If you don't change it, it's not your fault; if you change it, it might be your fault.
I think something like this could apply very well to software. If someone uploads source code to github they haven't sold it to you with any purpose in mind, but commercial sales have functionality promises so they could be held to them.
(Some states allow disclaiming implied warranties, some do not).
> #!/usr/bin/env python
# (c) 2012, Michael DeHaan <michael.dehaan@gmail.com>
# This file is part of Ansible
# Ansible is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
# Ansible is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. # You should have received a copy of the GNU General Public License # along with Ansible. If not, see <http://www.gnu.org/licenses/>.
###############################
[0]https://github.com/ansible/ansible/blob/devel/bin/ansible
What i'm saying is, if sold by ansible to a consumer, these disclaimers are completely ineffective in a bunch of states.
The UCC (which is what governs these transactions) is model legislation, and provides for a few options that states can choose in various parts. One option allows disclaimer of implied warranty in all transactions. One option allows disclaimer of implied warranty in all transactions except those with consumers. One option disallows disclaimers of implied warranties.
Depending on which option a given state chose, the language you are citing would have different effectiveness.
Thanks for pointing this out. I imagine most people who publish open source software aren't aware of this risk, and will stop when they learn about it.
2. Most folks are aware of this risk when they start companies to sell open source software.
3. Most do not sell the software directly to consumers, and outside of the few states that don't allow disclaiming at all, most states are fine with disclaiming warranties in b2b transactions, just not b2c.
Most don't sell the software directly at all, and those that do are often selling support anyway :)
Want a seat at the standards table? Pony up tons of time, plenty of money for travel to cities where meetings are held, and be prepared for the big software consulting firms to crush you anyway with requirements like ISO-<somethingStartingWith9> before you can make a project on github public. Want to contribute to Python? Sure hope you have that degree, plus an engineering certificate from your local/state/national government. Your dues are paid up and you've passed the most recent set of exams, right?
Oh, and let's talk about your toolchain. You can license a certified compiler for $15,000 a seat. Per year.
I can't imagine anything more chilling, other than an outright ban on people writing software.
And good luck knowing what the actual requirements of that standard are; PDFs of ISO standards cost hundreds of dollars.
Step 2 would be the creation of an actual software engineering profession complete with the equivalent of the 'iron ring' and a pledge to go with it. Maybe the ring could be made of ferrite ;)
Step 3 is attaching a figure to compensating victims of breaches over and beyond some credit score bs.
Step 4 would be actual legal liability for service providers and shrink wrap software manufacturers which they could not get you to waive.
Step 5 would be criminal liability for producers of faulty software and especially the management layers above them.
Applied sequentially until it starts to hurt would improve software quality in a hurry and would most likely result in massive retraining of a large number of people now employed as programmers as well as their management.
So if your software is going to affect lives and you feel that you can handle the fall-out in case it does not and you are not certified then you're more than welcome to make that combination work.
(1) their phones given enough charge refuse to call 9/11 as mandated by law at the present anyway
(2) their authentication details are leaked
(3) their operating systems suffer security bugs
At most other levels the damage could easily be contained. Note that even at present they could be sued for any and all of the above, whether such a lawsuit is winnable is beyond my expertise to evaluate but it would certainly be interesting to see the arguments both sides put forth.
So plenty of opportunity to be employed for 'non certified programmers'. Note that almost every big software provider already has a certification program of sorts but at the moment these are just used as either a revenue stream or a way to get people to invest in the eco system.
Just like in other licensed fields like medicine.. no wait, I meant construction... sorry no, I meant a field with fewer consequences.. like hair dressing.. no wait, that doesn't work either.
hmm...
Just like you're free to build a hut in your backyard you are not free to construct a home and then to sell it if it is not up to code. That makes pretty good sense to me.
For simple stuff, like building a deck, you don't need an engineer. For a lot of basic-enough construction projects, you can just buy supplies and hammer them together. It's only where structural or safety issues kick in that you need to have someone sign off and approve your plans, and that makes sense.
Likewise, putting up a brochure-ware Wordpress site, just do it yourself or have some kid do it. But once you start collecting customer/financial/personally-identifying information, you should need to have a professional either do it, or review your code and sign off on it. There's a risk involved, and for too long we just shrug our shoulders and push the risk off onto the consumer, onto Visa, onto whatever.
I am looking forward to when the software world leaves this wild-west phase.
This is already possible. If you graduate with a B.Eng in Canada you can become a P.Eng with the appropriate training/certification. Many Computer/Software Engineering programs in Canada are B.Eng programs (the alternative is B.Sc though those are less common).
Software/Computer Engineers who graduate with a B.Eng are eligible to receive the iron ring, and many do decide to participate in the Ritual of the Calling of an Engineer.
I think it's much less common to find a P.Eng who is a software or hardware engineer, versus say a Civil or Mechanical Engineer, but the option exists.
I'd be very surprised if Pratt & Whitney Canada didn't have a P.Eng to sign off on their turbofan control software. But Aerospace is different, because it's a highly regulated industry and people's lives can be quickly and obviously at risk due to a mistake.
Self driving vehicles and 'the Internet of Things' are in the same league.
I think the solution would be to find a way to induct an initial group to get the process kick started. The challenge is verifying the training of that initial group as one needs some way other than the current method of working for 4 years under an existing P.Eng.
It already exists in many European countries, and yes in Portugal there is also a ring to go with it.
And although not enforced as the Engineers Association would like it to be, if you are signing projects as <whatever> architect it is advisable to be a registered member.
I would say that some sort of negligence laws would be appropriate here, with a defence being that good practice was followed.
Accidents will happen even with the best of intent; but there's a line somewhere.
You might counter: well no one will be willing to be CTO if it involves such personal risk.
I would counter: companies will find a way, through certification or lawyers, of ensuring that their products are secure enough, or they can show sufficient due diligence that they won't end up in jail.
I personally think making execs criminally liable for this kind of insecurity would really force companies to start spending money on ensuring they ship something secure and not a minimum viable product full of holes like this.
Of course they would. Compensation would go up and the good ones would be readily employed.
The hard part would be to make such liability stick.
Which means CTOs would have huge incentive to conceal such breaches and persecute anybody who would report them. Also, CTOs would require huge money to cover the risks, and probably wide insurance coverage like medical malpractice insurance. Which is five-figure number at least. I wonder which startup could afford that.
> I would counter: companies will find a way, through certification or lawyers, of ensuring that their products are secure enough
They surely can spend money on lawyers writing tricky contracts and acquiring various expensive certifications. As for whether it'd make their software any more secure - this is much more doubtful.
> I personally think making execs criminally liable for this kind of insecurity would really force companies to start spending money on ensuring they ship something secure
That implicitly assumes right now the problem in software being insecure is because not enough money is spent on it, and if software would be more expensive, it would be more secure. This assumption does not seem to be true.
If a venture has no reason to exist if cannot produce secure products a culture of building secure products will emerge. It may be that every MBA with a NDA will not be able to afford the competent programmers required, but as they are weeded out we will have fewer less than useless things.