[trustable-software] Trustable Software Engineering

Paul Sherwood paul.sherwood at codethink.co.uk
Tue Jul 19 08:22:27 UTC 2016


Colin
thanks for this... please see my comments inline

On 2016-07-18 10:12, Colin Robbins wrote:
> As you know Nexor & Qonex have both been long term supporters of the
> Trustworthy Software Initiative (TSI): http://www.uk-tsi.org/

Yes, I've not had a chance to look into this properly so far. A couple 
of early hurdles for me:

- it seems to be UK-centric. Although I'm proud to be British, much of 
what I'm involved with and care about has international implications.

- it quickly asks for money (e.g. purchase PAS 574). Throughout my 
career so far, my experience with official Standards for software have 
been rather disappointing, so I am reluctant to fork out cash for this 
one.

> This has some academic roots, so they are quite picky on words. I
> suspect they would distinguish Trustworthy and Trustable, with
> Trustworthy being a generalist term, and Trustable being very
> specific.

I'm picky on words too, and normally I push back on people (academic or 
not) who try to appropriate or redefine existing words.

By trustable here, I'm meaning software which meets technical criteria 
(it works, and so on...), and therefore someone may consider whether or 
not to trust it based that and on other factors. I'm avoiding 
'trustworthy' since those other factors may override the technical 
criteria. e.g. geopolitical implications such that someone in country A 
would distrust software provided by organisations from country B, no 
matter how rigorously it could be demonstrated to work.

> As an example, a firewall may be trustworthy - it has the potential 
> to
> stop network traffic.

So here I fall at the first hurdle.

'has the potential to stop network traffic' is nowhere near enough for 
me to consider a firewall as trustworthy. Whatever its official 
function, it can (and probably will) do other things that I'm not aware 
of, e.g. the Juniper issue last year. And depending on who manufactured 
it, I might distrust its claimed official functions entirely.

> However if I mis-configure with a rule that say
> "allow all traffic", that specific instance of the firewall is
> trustworthy, but not trustable.

Not for my uses of these words, and far as possible I'm trying to stick 
with the popular (non-technical) interpretations. I'll be happy to 
adjust my use of particular words here if/when consensus is established.

One of my pet hates is when technical/marketing people appropriate 
important existing words for their initiatives. Consider the LTS (Long 
Term Stable) kernel work. By default LTS is released every couple of 
weeks, and is End Of Life after 2 years. By most people's understanding 
it is neither stable (dealing a couple of hundred patches a week is a 
significant rate of change) nor long term (many important devices have a 
lifespan of 10 years or more)

I'd be very concerned if TSI (or any other organisation) manage to 
brand 'Trustable' to cover something which should not actually be 
considered 'trustable' in the normal english sense. Do you think that's 
a possibility?

> So I think the attributes you define under the "trustable software"
> heading are really trustworthy attributes. To become trustable, you
> need to bring in context and deployment attributes. This is very much
> what the GCHQ scheme for "Commercial Software Assurance" tries to
> achieve - a product is only trustworthy if it has the whole product
> environment to enable a trustable deployment.

Well, as is probably clear, trustworthy is a *very high* bar for me... 
I'm only aiming at (my non-technical interpretation of) trustable, for 
now... and I believe even that requires context (provenance) and 
deployment, so I think we agree.

Is the GCHQ scheme public, by any chance? It would be fantastic to 
consider their work here.

> One of the challenges the Trustworthy Software Initiative has to 
> face,
> is that fundamentally following a trustworthy process is more
> expensive that just hacking code.

True.

> In some markets this is acceptable (aircraft, defence), but others 
> not
> acceptable (free mobile phone apps).

Again, true. However I imagine that improvements in education, 
thinking, approaches, processes and tools in general would be welcomed 
even in the app economy (they're not really *free*, in the sense that 
they still require effort to create)

> In my view, the industries that care are already doing stuff here -
> yes there is more, much more to be done, but the direction of travel
> is encouraging.

We'll see :)

> The big gap is in industries that don't care - to the detriment of 
> the
> end user / consumer. I am convinced the solution here is economic, 
> and
> not technical. Somehow the economic models need to change such that
> the economic impact of developing poor software is outweighed by the
> time-to-market advantages.

Another thing I don't trust is economics :) [1]

My main concern about this argument is that the feedback loop is too 
slow to actually regulate anything. For significant projects, the work 
can take years to deliver, by which time the key decision-makers and 
engineers have probably left the building.

> I welcome the initiative, and am happy to participate.

Excellent. Please could you share links to specific TSI or other 
content that you think is particularly relevant for readers here?

br
Paul

[1] 
https://www.amazon.com/Things-They-Dont-About-Capitalism/dp/1608193381



More information about the trustable-software mailing list