[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