The introduction of an exculpatory rule in contracts allows for the negation of a legal ruling (the default rule) where both parties have (through the contract) expressly consented to the contrary. A car maker is not liable for the life of an engine exceeding 60,000km unless there is an express warranty stating this. Similarly, there is not expresses exculpatory rule for software unless the vendor offers this in a warranty clause.Legislation can make many superficial exculpatory clauses either invalid or redundant. Such an exclusion would include negligence. In some cases, the exculpatory clause merely states that law as it is understood. Where an exculpatory clause is permissible, the final assignment of liability does not depend on the preliminary distribution of liability. If the default rule is that a software vendor is liable for software vulnerabilities, but the vendors profitability is greater where it does not suffer liability, then the vendor will print a label (in the case of software this could be a click wrap agreement) stating that is it not liable.
Where the profit made by the vendor is greatest if the vendor is liable, there will be no need to include a warranty or click wrap agreement with the software. The only effect of allowing exculpatory clauses for software is that a transactional cost is introduced.
There are reasons for the software vendor to assume liability. The vendor could create a couple versions of software. One of the versions could be targeted at a high security installation and the other towards a lower end user base with a lower security requirement. The high security version could be hedged with a contract covering the risk.
If the vendor creates the low feature version for $200 and the full featured secure version for $800, the user can choose the level of protection. Taking a survival model of Windows 98 and one for Windows XP, the client can calculate the expected difference from each product. If Windows 98 has an expected compromise rate (without other compensating controls) of once per 6.2 days and Windows XP has an expected rate of 52.5 days when the firewall is enabled we can calculate the cost per incident. If the user has a mean cost per incident of $320, we see that the Windows 98 option has an expected annual cost to the organisation of $19,040 ($18,840 damage plus $200) whereas Windows XP has an expected cost of $3,825 ($3,025 damage plus $800).
Hence, most companies with a need to secure systems selected the more secure option and installed Windows XP over Windows 98. The initial costs did not reflect the overall costs to the organisation. Likewise, home users (who rarely calculate the costs of compromise) where more likely to install the cheaper option.
To extend the analogy, the us assume that a software vendor can create a perfect version of software for a mean cost of $20,000 and the flawed version at the standard costs, we see that it remains in the user's interests to select the lower security option as the expected losses are lower.
The vendor could offer liability-free and full-liability versions of their product, the later sold at a reduced price. The vendor could then control their risk using a hedging instrument. A market evaluation of the risk being traded would provide better information than that which the vendor has alone. With this in mind, the user could also purchase the same derivative as the vendor. The cost to the user to purchase the software plus risk insurance would be less than purchasing the "more secure" version from the vendor as the vendor would hedge the risk it faces and add a transactional cost as well as a return (at the firms IRR).
Here we can easily see that both parties are better off where the vendor produces the optimised but less secure version of their product and where the vendor does not assume liability for bugs. What we need instead is a market mechanism to equalise risk.
Simply put, the vendor will provide a warranty (which acts as an insurance policy for the user) in cases where it can charge more for the provision of the warranty than it costs to provide the warranty. This cost could be either from a hedging instrument or through an investment in more testing. However, it must be noted that no increasing testing will make software invulnerable to all attacks and remove the ability for flaws to be discovered. As such, the cost of the hedged derivative will decrease, but will not go to zero.
The argument against this form of market is imperfect information. Many people argue that the software vendor has more knowledge than the user. As noted above, this is untrue for several reasons. As noted above, the vendor has no incentive to hide vulnerabilities as these cost the vendor through a decrease in capital. Next, the vendor would be competing on the same derivative markets as the users. The vendors knowledge would be quickly and efficiently transferred through the market mechanism.
The end result is that a derivatives based strategy does not allow for information asymmetry and would disprove entirely the assertion that software vendors operate a "market for lemons". Rather, we have a completely different game in the software industry. This does not mean that it is optimal, just that we have a different sub-optimal game to model.
From this we can see that the lack of liability does not require that the software vendor does not have the appropriate incentive to provide the optimal amount of testing and hence security (as well as to add the optimal levels of external controls) to the user. If more testing is cost effective in economically providing more secure software, that is if the additional testing is cost effective, the software vendor will conduct this testing whether it is liable for security flaws or not.
The incentive to provide security is no different than the incentive to provide other characteristics and features. A vendor will add software extensions that can reduce the overall security of a system if the user values these to a greater extent than their costs.
Safety (and security in general) is a tie-in good.
Amenities cost something. Vendors provide amenities if consumers (users) are willing to pay the cost of obtaining these.
"Cars come with batteries and tires, but not always with stereo equipment or antitheft devices and rarely with driving gloves and sunglasses"
What is demonstrated by those organisation with a defensive (and hence secure) coding regime is a lower variability in output. The mean coding time will remain similar, but the test time can be expected to be distributed differently for the organisation that codes with a defensive posture than that of the organisation who leaves too little time for testing. This increase in the standard deviation of produced results (or variability) increases the risk to the to all parties (vendor and user).
See Optimal Derivatives Design under Dynamic Risk Measures
The game theoretic approach to this is can be modelled looking at the incentives of the business and programming functions in the organisation. Programmers are optimists. As Brooks (1995) notes, "the first assumption that underlies the scheduling of systems programming is that all will go well". Testing is rarely considered by the normal programmer as this would imply failure. However, the human inability to create perfection leads to the introductions of flaws at each stage of development.
(See Dorothy Sayers, "The Mind of the Maker")
In the model presented by Brooks (1995), as a program moves to a "Programming Product" and then to "a Programming Systems Product", there are incremental additions that extend the estimates of the programming team. At each phase these can be expressed as a function of effort expressed in the lines of code, . We can express the mean effort required to code a number of lines and the variability, in achieving this outcome. This allows us to represent the coding effort as a representation of the stages of development:
In x.4, is the function of systematising the code. The expressionis the productization of the code.
The derivative would require the firm to publish their productivity figures;
1. Lines of code per programmer (and standard Deviation); , and
2. Bug-incidence figures; and
3. Estimating and project rules/methodology
4. Software design methodology
5. Secure Programmer measures (e.g. SANS Coding Methodology); and
Many see this as proprietary data and would be loathe to share, but as more in the market take-up the use of such a derivative in managing their own risk, the incentives for others to follow increase. We can also demonstrate that as and that the volatility in coding and decrease with the number of reported bug incidents as .
More metrics would be required based on the methodologies and coding practices used with different computer languages expected to exhibit different responses. (again, I am still working on the plots).
As the skill of the programming team (&) increases through group training, secure coding practices and in-line testing, the volatility in coding As the incremental returns ondiminish as and the cost of training continue to grow linearly, we can see that the optimal position for any software vendor is to have a skilled team that maximises returns. At this point, additional training becomes economically unviable and does not create further returns for the organisation.We also see that it is in the interest of the firm to minimise the variance in skill levels between programming staff (aim to have). This of course adds costs as junior staff would be less productive in that they would have to work with more senior staff in order to both cross train and to ensure that the junior staff maintain an acceptable level of production and testing.
This exercise of joining junior and senior staff would create a return function depicted by Brookes (1995, P19) for a "Time versus number of workers - task with complex interrelationships". The output of the junior/senior staff unit would be lower than the senior staff level (initially) but would lower variability and increase the skill levels of the junior staff and hence over time . Due to staff turn-over and the increasing costs of maintaining more skilled programmers, this would also have a negative feedback on the vendors production costs. This would also need to be optimised rather than maximised if the vendor is to maximise returns.
 Software vendors offer limited warranties (I covered this in my LLM Paper) that provide some protection for the user, but this is limited.
 Add Ref. See my LLM thesis - Click Wrap section
 This includes the cost of hiring the legal team, the cost of marketing people vetting the click-wrap agreement and the cost of printing the clause.
 See Hedging
 Such as Windows 98 and Windows NT by Microsoft
 Conversely, the vendor could have the stripped down version of software and one that has extra features (such as firewalls and additional logging)
 I shall be adding a Link to quantitative study results
 In each case we are presuming that the CIS (ref) standards for installing the software have been reasonably met. See quantitative results
 Based on quantitative data - ref report
 ref to be added
 Which is an extremely low estimate
 As discussed earlier
 Not only does the market pooled knowledge feed into the price of the derivative, but the vendor's knowledge of their own product does as well.
 "Economic Foundations of Law and Organisation " Wittman, Donald (2006), , Cambridge University Press.
 Pauline Barrieu and Nicole El Karoui
 Brooks, F.P. (1995) "The Mythical Man Month, Anniversary Ed." Re-Printed 2008, Addison Wesley Longman, USA (p14)
 Through the addition of a "Programming System" with the addition of Interfaces and a System Integration Phase
 Standard Deviation (where )
 Brooks p 6
 Brooks P6
 Which would be quantified through the market method
 That is, where there is an initial cost plus a linear increase in the costs of developing the programmer skills.
 This investment may still be made by the individual programmer with returns to the organisation and also for further personal gains (investment in personal capital).
 Also reducing the output of the senior staff.
 F. J Corbato' (MIT) - A long duration project needs to incorporate a turnover rate of at least 20% per annum. New hires need to be technically trained and also require time to be able to effectively integrate into the existing team.