Orcmid's Lair status 
privacy 
 
about 
contact 

2008-05-25

Trust but Demonstrate

[update 2008-05-25T15:36Z: Added a faith-based illustration and clarified that the stated insight from Solomon and Flores is not a quotation.]

Exploring Trust

I have an interest in trustworthiness of open-system software.  Open-system software is the kind of software that can be combined/connected with other components to form a functioning, integrated probably-distributed whole.  Open-system software can be open-source software.  Open-source software is not necessarily open-system software.

My interest in this motivated the TROST project: Templates for Raising Open-System Trustworthiness.  I didn't work this around to successful completion of a completed M.Sc Project Dissertation.  I am still working on the topic and I am constantly learning more about the subject.

When I described the project in March, 2005, I said this:

"Trustworthiness?  Well, that should be easy.  We all know trustworthiness when we see it, right?  Maybe not.  Starting out, I am looking at trustworthiness in terms of human arrangements for mitigation of the risks of everyday and not-so-everyday life.  There is, most of all, the risk of dealing with each other, especially at a distance.  I foresee a mapping into trustworthiness projected onto artifacts.  I am not willing, at this point, to take my eye off of the ultimately human and social nature of trust and trustworthiness."

My sense of the social nature of trustworthiness was expressed in these morsels (from 2004-12-20):

"Although there are technical arrangements that can be employed as instruments for demonstration of trustworthiness, everything I've encountered affirms (and perhaps accentuates) the centrality of mutual human trust in trustworthiness.  Establishment / preservation / restoration / improvement of software trustworthiness is the conversation I want to contribute to.  It always comes back to trusting in someone. ...

"Everything depends on trust.  It's one of the best gifts you can give someone.  [Quoting Julie Leung]

"Trust is a gift that we make to someone.  You can't demand someone's trust.  You can only treasure and protect it, once granted you.  It is a fragile thing, easily damaged and difficult to repair."

What Makes Artifacts Trustworthy?

My dissertation involved demonstration, with a small, open-source software project, of ways that a producer could demonstrate and an user/adopter could confirm the trustworthiness of delivered software.   This framing left me with a problem: it seems to remove all social arrangements from the picture.  So I had to resolve that in some way.

My first realization was that we often use "trustworthy" as "not requiring trust."  Yet in computer security and secure computing circles, trust is defined as always applying in situations where trust can be breached and we are trusting that it won't be.  The US National Security Agency (NSA) defines trusted components as ones that can break security.  Consider how this interpretation fits these expressions: "In God We Trust;" "In God We Trust, Others Pay Cash."  (There are other uses that don't fit so well, such as "Trust in God" and the assurance "Trust me."  These seem to have a different sense of trust.) 

If there is no possibility of breach, no trust is involved and, indeed, trust would be unnecessary.  Even so, I hear popular use of trustworthy and trustworthiness with regard to features that make trust unnecessary with regard to computer systems, communication protocols, and protection mechanisms.  The Trustworthy Computing Initiative smacks of this, as do efforts to enforce property rights by Digital Rights Management.  Also, these activities seem to involve mutual distrust.  Whatever is at play here, it does not seem to involve trust. 

I couldn't see how to break apart this situation and identify meaningful open-system trustworthiness in the way I'd intended.

Rather late in my researches, I encountered the 2001 book, Building Trust in Business, Politics, Relationships and Life, by Robert C. Solomon and Fernando Flores.  (My copy was purchased on June 24, 2005.)  I found a number of fertile topics in the book.  And I found a connection between artifacts (products, software, computers, etc.) and trustworthiness.  Here is what I extracted (and all misinterpretations are mine):

The trustworthiness that we place in our use of computer systems and software is tied to our recognizing, in our experience with the product, the care of the producer for those (namely, us) who adopt and use the product.

There it is.  We don't trust the product so much as we trust the producer to have been careful of us.  In particular, the greatest test of trust is when there are breakdowns with respect to the product.  How the producer then demonstrates care and provides remedy is critical in restoring and even strengthening our trust. 

After that, the TROST project was focused on ways that producers of open-system components can demonstrate care and create arrangements that build trustworthiness and act to restore it in the face of any breakdown.  The symbol of trust was formulated at that point.

What Makes Us Trustworthy?

There's a critical corollary to how trustworthiness shows up:

If the producer distrusts the adopters and users of its products, there is no room for the care that engenders trustworthiness.

We have ample evidence of the excesses we can justify when we claim the other party is untrustworthy.  Some of the most perfectly-maintained dysfunctional relationships are those in which each party considers themselves the victim of the other.  Look around.  It arises in international relations, within business firms, and in families.  Couple that with the common fear of being taken advantage of (as producer or as adopter or user), and you might wonder how we manage to cooperate in groups at all.

Here is what I see, extracted from my studies and analysis (largely based on Solomon and Flores, but all misinterpretations are mine):

  1. To be trustworthy, one must first be willing to trust.  This is a position of vulnerability and discomfort.  It will take serious commitment to be willing to trust anyhow.
      
  2. To be trustworthy, one must be careful to build a relationship of trust with the adopters and users of your products. 
      
  3. The product and its support is designed to reflect and demonstrate that care.  It is evidence of trustworthiness.
      
  4. Trustworthiness is tested not when everything works but when there is a breakdown in the product, the support, or the service.  The care provided here is where trustworthiness and a relationship of trust live or die.

Trust but Demonstrate

Ronald Reagan is known for his "trust but verify" statement.  That is certainly understandable, especially when there is a history of distrust.  But it is distrust-based and it bring with it the constant escalation of how the other must prove trustworthiness along with the tendency to do what we fear of the other as a defense pre-emptive self-defense.

I suggest "Trust but Demonstrate," even if it doesn't seem to make sense on the face of it.  It's about being willing to trust enough to demonstrate the care that being trustworthy requires.  It is the earnest offered into the building of trust.

 
Comments: Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 08-10-07 13:22 $
$$Revision: 1 $