[Cryptography] Trustworthiness

iang iang at iang.org
Fri Jun 23 05:07:39 EDT 2017


On 22/06/2017 17:39, Dennis E. Hamilton wrote:

> I think we are missing a key factor in trust and trustworthiness, 
> although this thread does touch against it somewhat.
> It is useful to preserve the notion of a trusted system as being one that could in fact deviate from the behavior being relied upon but is trusted not to.  How and whether such trust is merited is not a binary thing.
>
> Note that if deviation is in fact not possible, then trust is not a factor at all.  In some discussions, I fear that this is taken to be a case of trustworthiness.  It seems to me however, that trust is not required in that case, although one might be trusting in the assertion that there is no material deviation possible.  (It is turtles all the way up.)
>
> A decade ago I spent some time looking into the trustworthiness of artifacts and it comes down to trustworthiness of the producers of those artifacts.

This.  In that, it is more sensical to _trust_ the producers, and _rely_ 
on the machine.  To my mind, trust is a complicated risk analysis that a 
human makes on another human given some information about the past, and 
a risk in the future.

To apply that to a machine makes no sense (although I grant that it 
might be possible in a gambling machine context).  The machine is either 
working as advertised or it is broken.


> And the measure of trustworthiness is behavior of the producer in the event of a breakdown, by whatever misadventure.  If my car breaks down on the road, the issue will be how that is remedied and who I find to be reliable for that.  Contingent reality applies, not some abstract perfect certainty.

Yup.  Where it gets interesting is when we move to a more complicated 
scenario.  E.g., a mixed service offering like uber.  We trust the 
driver to do the right thing, and we trust uber to behave well, but we 
rely on their software to find us a car, and get it here in the 7 
minutes the app says.

We rely on Uber to make sure that the driver's care is reliable - 
there's little to no risk there.  We trust that the traffic won't stuff 
things up - but there is some risk that the driver can't fight her way 
through.

So another requirement of 'trust' is that there has to be a risk. No 
risk, it's a belief or knowledge or certainty.  Nothing to consider.

> It matters to look at context and also the degree to which the cycle of learning and improvement in which producers engage demonstrate care for the adopters of their products or systems.  That demonstration may be evident in proper operation and it will be particularly evident in the face of a breakdown.  The whole lifecycle and update process around software, as well as how security/privacy matters are addressed figures in this picture.  The measures by which providers of services safeguard the privacy of their clients is another case.
>
> More at <http://orcmid.com/blog/2008/05/trust-but-demonstrate.asp>.

As an aside, I wrote lengthily about trust here:

https://docs.google.com/document/d/1D7Q_RgisPI-5ztbzRgQb_VWDAQLRWuZvP2tACH7lCCE/edit

But this is part of an extended Identity Cycle that aims to figure out 
what the future of personal identity is.  So it's context-specific being 
Part 2 only.  It's also rather light on crypto, but I suppose Trust has 
been abused in crypto so much that we have little choice but to keep an 
eye on it...

iang


More information about the cryptography mailing list