[LINK] Identity theft virus infects 10,000 computers

[Craig Sanders]

On Wed, Aug 16, 2006 at 03:20:57PM +1000, Rick Welykochy wrote:
> --- Craig Sanders <cas at taz.net.au> wrote:
> > also, the fact that source code is available to be examined and
> > fixed by the user (or their agent) is (or should be) a significant
> > mitigating factor in any liability claim.
>
> Why so? It is very impractical for every single user of every single
> piece of FOSS to download the source, examine it for bugs, test it

because you can't avoid all personal responsibility for your actions by
saying "i couldn't be bothered".

"i couldn't be bothered checking if the gun was loaded before i pointed
it at your head and fired". 

"i was too busy to check the speedometer and keep below the limit"

"i didn't care to read the dosage instructions for paracetamol"
 
excuses like that don't work, do they?


> for security and then make a supposedly informed decision as to its
> security and safety. Far better to legislate the reliablility and
> enforce that the testing and validation be done ONCE, at the source,
> with the software writer. After all, the development team (which
> includes the testers) are in the best position to test the final
> product against the initial requirements, don't you think?

so what if the testers include the entire population of users?


> I don't know if you develop software, craig. I can tell you that a

i do, but mostly for my own use and for people with my level of skill.
systems admin tools rather than applications for the most part. in fact,
i hate doing applications development.

> read of the source code cannot possibly uncover all the potential
> problems that exist in software. The problem of software testing and
> validation is very complex and very unsolved. Peer reviews and code
> walkthroughs can uncover nasty programming habits and dud programmers,
> but will never uncover all the bugs, security or otherwise.

they CAN eventually discover them all. they can certainly discover a lot
more than if the source code is not available.

strict liability from the moment of publication wont help here - it will
actually make that kind of scrutiny impossible because it will be too
risky to publish the source until after all the bugs have been found.
i.e. never.

also, what of the case where the author/developer releases only source
code, not an executable (which is a fairly common practice in the FOSS
world) - are they liable for someone else compiling and running it, or
compiling and re-distributing it?


> Let's take an example: race conditions and the security holes they can
> create. These are almost always detected in the wild, under conditions
> of realistic stress and resource usage. I doubt examining source code
> would uncover these errors. Or somewhat related: the problems of
> concurrent programming and multiple access. These are not even visible
> in the source code - the errors only emerge through concurrent usage.

which implies that this can not and should not be a liability under any
legislation.  if there are no reasonable precautions that you could have
taken, then how can you be held liable for failing to take them?


> Another concrete example for you personally. Do you really think even
> with your skills and talents that you could possibly have detected the
> security holes in SSL that were discovered in the wild back in
> 2001? I was using SSL on production systems at the time and certainly
> (a) had no time to read the source code which had been available for
> perhaps a year or two and (b) doubt I would have picked up the two
> or three lines of code out of thousands that contained the compromise.



> > strict liability for free software developers would effectively kill
> > free software - it would be too great a risk (with no benefit at all)
> > to release any free software. by contrast, proprietary/commercial
> > developers can balance the risk against the financial reward (and,
> > accordingly, incur obligations *because* they accept money for their
> > product).
> 
> Have a read of Scheier. He doesn't make idle claims about software

i read Scheier's stuff regularly.



> Yes, software liability legislation will have a chilling effect on
> FOSS. It will also have a chilling effect on proprietary software. So
> what? The goal is more reliable, secure and safe software. The outcome
> depends on the ability to deliver the same. I have complete faith in
> the FOSS community to deliver same. I DO NOT have faith in some of the
> more prominent proprietary software producers to deliver same. And I
> certainly have little time or interest in FOSS or proprietary software
> (crapware?) that does not meet stringent standards in security, safety
> and merchantability.

in an ideal world, what you say could work.

in the actual world, it would be just another tool for Microsoft et al
to attack FOSS developers with - bankrupt them into submission with
trumped up case after trumped up case...they already do astro-turf
campaigns in the advertising world, it's no great leap of the
imagination for them to do the same kind of thing in the court-rooms.

at the same time, the legislation wouldn't work against huge proprietary
software developers because nobody could afford to sue them, they could
drag it out in court long enough to bankrupt anyone with less resources
than them.

so, it will have a chilling effect not only on FOSS but also on small
software developers.


> It may mean that certain creators and distributors of FOSS may have to
> take out a bit of liabilitiy insurance, brush up on their development
> and testing SKILZ and even enter the realm of responsible software
> development. Is that such a bad thing? I am of the opinion that the
> development teams of the more successful FOSS projects are already
> there, often miles ahead of their proprietary cousins. The latter are
> driven by market forces that demand far different things than quality,
> reliability and security (unfortunately).

and how do you think they got there?  by participating in projects and
developing their skills while their skills were still unpolished.

one of the major benefits of FOSS to society is that it functions as an
informal apprenticeship scheme for programmers, where you can work with
other people of varying skill levels (from newbie to guru) and learn and
teach and hone your skills all at the same time.

given the typical quality of programmers who have just completed their
uni degree but have little or no actual experience, this is essential.


free software, by the way, isn't just about being a cheaper, better
way of developing quality software. it's primarily about freedom, the
freedom of developers *AND* users to collaborate to develop, refine,
and *share* their software. the exclusive focus on just software
quality rather than freedom is the thing that distinguishes Open Source
advocates from Free Software advocates.



> > > No contract, no consideration. I am sure some of the legal eagles
> > > on Link could come up with many more examples of where safety
> > > and security are legal issues that fall far beyond the area of
> > > contract law.
> >
> > OTOH, for an example closer to software distribution, look at the
> > liability of a financial counsellor (or lawyer or other professional
> > advisor) providing generic opinions on a radio or TV show vs the
> > liability for the same counsellor providing specific detailed advice
> > to a client. there is far greater responsibility and liability for
> > the latter.
>
> I'll ignore the weak analogy of "free" as in beer vs. paid-for
> software, as I don't think it applies. Software creation and
> distribution is not a profession and until it is, no analogies like
> the above can be realistically drawn. Besides, attempting to prove a
> point by analogy is dead-end illogic.
>
> To address your analogy directly, I suppose the same would apply if I
> were to offer free consults and advice on the radio in the area of IT
> and security, vs. paid consults to clients. I suppose.

the point, since you missed it, was that software is more like an idea
(or opinion or knowledge or data) than it is like a physical product.


craig

-- 
craig sanders <cas at taz.net.au>           (part time cyborg)