[SystemSafety] 1. View of Computer Reliability in the Law (English and US) and 2. Argumentation

Les Chambers Les at chambers.com.au
Sat Jul 3 02:50:22 CEST 2021

My point is the accuser’s response to the question “is your claim credible" is sooo open to attack 
as to make its posing pointless in the first place. 
For example:
Q: Where is the evidence?
A:  All over the place. 
Q:  Is it secured from tampering 
A:  Well 

As an addendum to Carl von Clausewitz:
As the stakes elevate so do the levels of dishonesty.
As per PO Horizon; if a software engineer is prepared to lie about the existence of a bug report it’s 
a very small step to making its documentation disappear.

What’s required here is a ‘Silks Guide to cross-examining Software’.
A compendium of relevant questions a competent auditor might ask.
Questions to which we all know the incriminating answers.

It would resonate with the legal profession. I cite Jeffery Robinson (The Justice Game), “A good 
silk should never ask a question to which he does not know the answer.” Jeffery learnt from harsh 
experience. Defending a UK importer caught with a container load of illegal homosexual literature, 
he discovered that the police operation was code named Tiger. “Ha!” He exclaimed , “So you 
chose a name redolent with swaggering machismo.”
“No,” replied the witness, “I named it after my cat.”


> On 7/2/2021 5:53 PM, Les Chambers wrote:
> > What does she mean by ‘needed to be closely examined … adversarial examination of 
code’ ?
> > Do you mean rerun the entire V&V program Susan? That is assuming you could find the 
> > versions of all the design documents and (choke) a complete, correct and unambiguous 
> > of software requirements. Who has that kind of money?
> Les,
> I understand your concern about the practicality of independent V&V of 
> software like this, but that's not quite the point that is being made.
> My understanding of the argument is that if the notional "accuser" is a 
> piece of software, someone accused should have the opportunity to 
> "question" whether the "accuser" is making credible claims. That 
> "questioning" might be expensive, but they should nonetheless have the 
> opportunity if they have resources to pursue it.
> An adversarial examination need not re-run the entire V&V program, since 
> an adversary would not need to prove the code is fit for purpose. 
> Rather, a defendant would seek evidence that the code is NOT fit for 
> purpose.  One big defect found (failure to do what the prosecution says 
> it does), a systemic lack of quality, lack of an acceptable V&V paper 
> trail, defective configuration management, or other deficiencies in 
> development and application of the software might suffice to establish 
> reasonable doubt, especially for criminal cases.
> As to money, that is what the US Class Action system and other 
> collective litigation approaches are for.  If you have enough 
> high-stakes cases on the table and/or a deep-pockets benefactor 
> foundation, the pooled resources can indeed take on analysis of a large 
> complex piece of code with enough potential for success to make it worth 
> doing.
> I'm not saying the legal system is perfect, but if a judge were to 
> permit examining source code, over the long term it could well make a 
> practical difference.
> (BTW I'm not a lawyer and not giving legal advice.)
> -- Phil
> -- 
> Prof. Phil Koopman   koopman at cmu.edu
> (he/him)             https://users.ece.cmu.edu/~koopman/

Les Chambers
les at chambers.com.au
+61 (0)412 648 992

More information about the systemsafety mailing list