Preventing SSL Failures and More

As both the CTO of InterWorking Labs and an attorney, the recent report of the SSL failure in the iOS code concerns me, but not for the reasons in the tech press.

This incident once again raises the question of why software seems immune from the laws of liability that apply to other kinds of products? Software is typically licensed rather than sold and those licenses contain waivers of most forms of liability and then place any remaining liability under non-judicial, arbitration processes in locations convenient to the vendor (and often not convenient to the customer.)

Are such exclusions unconscionable in this day and age?

(I used the word “unconscionable” quite deliberately because here in California there is statutory authority that allows courts to refuse to enforce contractual provisions that are found to be unconscionable.)

But stepping back from these waivers, I would like to ask this question:

Is it contrary to good public policy for software, or a product (such as a smart phone) that is essentially a hardware shell to execute software, to be exempt from the laws of negligence and product liability?

This would not, usually, impose strict liability for flaws but, rather, would subject the maker to an obligation to use generally practiced and reasonable methods to develop and test their products.

I can see strict liability in places where risk of physical harm to persons foreseeable – such as in self-driving automobiles. Certainly when it comes to who, between an automobile vendor or the passengers, should bear the cost of injury that the ability to prevent the failure falls more squarely on the shoulders of the former, who is usually also more affluent, than on the latter. Yes, that is more insurance than liability, but when personal safety is at risk that seems sensible.

I write this with a bit of self-interest. My company, InterWorking Labs, sells tools intended to help those who are developing network code to evaluate how robust their code is in the face of varying network conditions, such as packet loss and delay, and also in the face of protocol peers that speak different dialects of the protocol. And to bring this into the current context, we do have tools that induce the kind of network conditions that Apple’s SSL/TLS code failed to properly handle. We like to think that had our tools been used the recent events could have been avoided.

I don’t want to shine the spotlight on Apple – their recent SSL/TLS failure is hardly unique; many companies have had similar flaws in their network code.

My point is, rather, that the state of testing of network products is not good.

And getting back to my original question – would the quality of our internet improve if software were obligated to meet the standards of care imposed by our laws of negligence and product liability?

Or, to put it another way:

Are the waivers of liability in ubiquitous software licenses leading us into a world of failures and harm?


 Want to know more about SSL/TLS?

 

Free Consultations                     How to Buy                     Contact an Expert