<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Cyber Product Liability</title>
	<atom:link href="http://defensetech.org/2008/12/15/cyber-product-liability/feed/" rel="self" type="application/rss+xml" />
	<link>http://defensetech.org/2008/12/15/cyber-product-liability/</link>
	<description>The Future of the Military, Law Enforcement and National Security</description>
	<lastBuildDate>Sat, 26 May 2012 02:10:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: ohwilleke</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94988</link>
		<dc:creator>ohwilleke</dc:creator>
		<pubDate>Wed, 17 Dec 2008 22:13:48 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94988</guid>
		<description>Liability to the purchaser for defective software and hardware is almost universally limited by contract to the purchase price.  And, in cases of solely economic or intangible injury, those waivers are almost always upheld.
Third parties could have a claim, but very often, in instances when military software and hardware harm third parties, the users are entitled to governmental immunity, and this immunity often extends to the harm caused by products used by the military.  There are specific exceptions where unintentional injuries caused by government action may be a basis for a lawsuit, set forth in the Federal Tort Claims Act (for federal government employees including soldiers), despite governmental immunity, but those are quite narrow (car accidents, slip and fall, etc.).  It is very hard to make out a novel claim under the FTCA.
The moral or &quot;should&quot; argument is closely intertwined with the &quot;duty to warn&quot; issue.  If it is widely known and expected that software has siginficant security flaws, then it is unreasonable to expect it to be cyber attack proof and the appropriate solution may be to keep sensitive materials off line, or at least disconnected from wide area networks, so that foreseeable harm can be prevented.
From a law and economics perspective, the theory says that responsibility should be placed on the person who can prevent the harm at the lowest cost.  If chosing a Mac or Linux system over one made by Microsoft at a modest cost, for example, perhaps the best solution is for the people who have sensitive systems to avoid using Microsoft products.  The utter inabilty of Microsoft and a number of other vendors to make secure software, despite vast resources and potential marketing benefits associated with doing so, strongly implies that it is very costly or even impossible to make their products both publicly useful and secure.
</description>
		<content:encoded><![CDATA[<p>Liability to the purchaser for defective software and hardware is almost universally limited by contract to the purchase price.  And, in cases of solely economic or intangible injury, those waivers are almost always upheld.<br />
Third parties could have a claim, but very often, in instances when military software and hardware harm third parties, the users are entitled to governmental immunity, and this immunity often extends to the harm caused by products used by the military.  There are specific exceptions where unintentional injuries caused by government action may be a basis for a lawsuit, set forth in the Federal Tort Claims Act (for federal government employees including soldiers), despite governmental immunity, but those are quite narrow (car accidents, slip and fall, etc.).  It is very hard to make out a novel claim under the FTCA.<br />
The moral or “should” argument is closely intertwined with the “duty to warn” issue.  If it is widely known and expected that software has siginficant security flaws, then it is unreasonable to expect it to be cyber attack proof and the appropriate solution may be to keep sensitive materials off line, or at least disconnected from wide area networks, so that foreseeable harm can be prevented.<br />
From a law and economics perspective, the theory says that responsibility should be placed on the person who can prevent the harm at the lowest cost.  If chosing a Mac or Linux system over one made by Microsoft at a modest cost, for example, perhaps the best solution is for the people who have sensitive systems to avoid using Microsoft products.  The utter inabilty of Microsoft and a number of other vendors to make secure software, despite vast resources and potential marketing benefits associated with doing so, strongly implies that it is very costly or even impossible to make their products both publicly useful and secure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94987</link>
		<dc:creator>Brian</dc:creator>
		<pubDate>Tue, 16 Dec 2008 23:47:02 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94987</guid>
		<description>Obviously it depends upon the vulnerability in question. Like any products liability case, it will turn upon 1) what  the company knew, 2) what the product could reasonably be expected to do, and 3) the nature of the failure.
There is a big difference  between a hacker busting through a well designed system and a company knowingly putting out an OS that had massive security flaws.
</description>
		<content:encoded><![CDATA[<p>Obviously it depends upon the vulnerability in question. Like any products liability case, it will turn upon 1) what  the company knew, 2) what the product could reasonably be expected to do, and 3) the nature of the failure.<br />
There is a big difference  between a hacker busting through a well designed system and a company knowingly putting out an OS that had massive security flaws.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Harvey</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94986</link>
		<dc:creator>Jim Harvey</dc:creator>
		<pubDate>Tue, 16 Dec 2008 19:03:30 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94986</guid>
		<description>The case would not be parallel to some one building you a fence but leaving a hole in it that the bad guy got through. That would imply some one knows how to make a perfect fence that can&#039;t be breached.
It is more like some one built you a fence, which is a great fence. But some bad guy made himself a pole vault and took advantage of the fence&#039;s natural vulnerabilities.
It would be outrageous to hold a company liable for the cleverness of a separate party.
</description>
		<content:encoded><![CDATA[<p>The case would not be parallel to some one building you a fence but leaving a hole in it that the bad guy got through. That would imply some one knows how to make a perfect fence that can’t be breached.<br />
It is more like some one built you a fence, which is a great fence. But some bad guy made himself a pole vault and took advantage of the fence’s natural vulnerabilities.<br />
It would be outrageous to hold a company liable for the cleverness of a separate party.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: SpyGuy</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94985</link>
		<dc:creator>SpyGuy</dc:creator>
		<pubDate>Tue, 16 Dec 2008 14:48:32 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94985</guid>
		<description>Mac
Dream on Alice (Mac) - the software industry has not fixed the problem in two decades so why would anyone think they will without the threat of litigation.
Not only that , but they have demonstrated their mindset by not disclosing know vulnerabilities to officials time and time again.  Not only that but in some cases they take years to fix the bugs.
Wonderland with fewer or no software vulnerabilities is right around the corner!
</description>
		<content:encoded><![CDATA[<p>Mac<br />
Dream on Alice (Mac) — the software industry has not fixed the problem in two decades so why would anyone think they will without the threat of litigation.<br />
Not only that , but they have demonstrated their mindset by not disclosing know vulnerabilities to officials time and time again.  Not only that but in some cases they take years to fix the bugs.<br />
Wonderland with fewer or no software vulnerabilities is right around the corner!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mac</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94984</link>
		<dc:creator>Mac</dc:creator>
		<pubDate>Tue, 16 Dec 2008 12:06:48 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94984</guid>
		<description>Yeah, more lawsuits are ALWAYS the answer. Have you considered that maybe a vulnerability (oh, sorry, a &quot;cyber&quot; vulnerability) may be (cyber)fixed faster if that (cyber)company isn&#039;t also tied up in court?
Is this supposed to be some kind of fear tactic?
</description>
		<content:encoded><![CDATA[<p>Yeah, more lawsuits are ALWAYS the answer. Have you considered that maybe a vulnerability (oh, sorry, a “cyber” vulnerability) may be (cyber)fixed faster if that (cyber)company isn’t also tied up in court?<br />
Is this supposed to be some kind of fear tactic?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94983</link>
		<dc:creator>A</dc:creator>
		<pubDate>Tue, 16 Dec 2008 03:47:50 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94983</guid>
		<description>Although everyone loves throwing the words &quot;cyber&quot; around, I think this is essentially just a basic security issue. If you throw enough time and resources at something it can be made relatively secure, but in doing so you might make it so hard to use that it isn&#039;t even worth using. Eventually it&#039;ll be nice and secure, but unusable; or the development will take so long we&#039;re a full generation behind.
The AF has had problems &quot;securing&quot; our nuclear weapons, what level of security do you expect from the private sector? When you consider a basic service outage as a cyber attack, then you have to remember that any yahoo can walk over to a manhole cover somewhere and simply cut the wires.
</description>
		<content:encoded><![CDATA[<p>Although everyone loves throwing the words “cyber” around, I think this is essentially just a basic security issue. If you throw enough time and resources at something it can be made relatively secure, but in doing so you might make it so hard to use that it isn’t even worth using. Eventually it’ll be nice and secure, but unusable; or the development will take so long we’re a full generation behind.<br />
The AF has had problems “securing” our nuclear weapons, what level of security do you expect from the private sector? When you consider a basic service outage as a cyber attack, then you have to remember that any yahoo can walk over to a manhole cover somewhere and simply cut the wires.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: C. Juergens</title>
		<link>http://defensetech.org/2008/12/15/cyber-product-liability/#comment-94982</link>
		<dc:creator>C. Juergens</dc:creator>
		<pubDate>Mon, 15 Dec 2008 19:06:22 +0000</pubDate>
		<guid isPermaLink="false">http://deftech.usmilblog.com/?p=4239#comment-94982</guid>
		<description>MIT Technology Review discussed this issue last year, although with a different slant:
http://www.technologyreview.com/computing/12887
</description>
		<content:encoded><![CDATA[<p>MIT Technology Review discussed this issue last year, although with a different slant:<br />
<a href="http://www.technologyreview.com/computing/12887" rel="nofollow">http://www.technologyreview.com/computing/12887</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

