Blunder Dome Sighting

Professor von Clueless in the Blunder Dome

status 
 
privacy 
 
contact 

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

This page is powered by Blogger. Isn't yours?

Recent Items
 
Blackbelted That!
 
Blackbelt this!
 
EDOS Integrates Open-Source Software
 
Tech Challenges I Want to See
 
Eliminating Mutual Incomprehension in Interoperability Arrangements
 
The Dimensions of E-Work
 
Legitimizing P2P, Maybe?
 
The Difference an Open Source Makes
 
Grounding Your Work's Usability
 
Like It Or Not, We're In This Together -- The Software Improvement Cycle

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06

Friday, March 11, 2005

TROST: Templates for Raising Open-System Trustworthiness

On February 1, my proposal for an M.Sc in IT project dissertation was accepted by my Dissertation Advisor and approved by the Academic Coordinator of the program.  I more or less went autistic and comatose at that point, although I had prepared a project plan and the clock began running in relentless one-day-per-day fashion.  My deadline is July 28 and my plan envisions the dissertation being submitted on July 4 (and already slipping slightly in a replan I am conducting this weekend).  There have been many little stumbles getting started, and that is something for 43 Things at another time.

Today, I want more of the world to know what this is about.  That's mostly because I have other items to post about related work and materials that I find in my explorations.  It seems useful to establish the perspective that gives rise to my interest.

Why TROST?  Well, FROST was already taken and I was grasping at straws.  Once I had an acronym that worked in a (puny?) punny way, I held onto it.  I even adjusted the name of the project at one point.  I was careful to preserve the acronym.

Templates?  "Frameworks," "patterns," and "templates" all work.  It is not about laws or theories although principles, practices, guidelines, and approaches figure in. I can go either way with "model" but I think I'll save that one from further over-use just now.

Raising?  Sure, as in improving, enhancing, enriching, increasing, expanding, and so on.  I am looking at the achievement of trustworthiness as a process and a journey, not an absolute result.  I do mean continuous improvement along with resilience in the face of setbacks.

Open-System?  I had originally said Open-Source here.  It didn't take long to realize that there is nothing in my vision for TROST that is peculiarly about open-source development (not to be confused with open-source licensing).  I chose open-system trustworthiness in homage to OSI, the Open Systems Interconnection effort that had much to teach us about interoperability and integration as well as network interconnection.  I mean open-system in this general way.  My attention is on ways in which we can address the trustworthiness of components and their integrations in any open-systems setting.

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.

Enough blather, where's the code?  Uh, yes, this is an Information Technology project and that usually means that something will be built.  So, along with some templates and a fair amount of metatemplating too, there is a feasibility demonstration involving honest-to-gosh delivered software.  The sofware will be produced using open-box development of an open-source component.  This component will integrate into open-system middleware, ODMA, on the Microsoft Windows desktop.

Here's more based on the definition of TROST as a SourceForge project:

Project Aims:
  • To deliver a framework for development and maintenance of software with demonstrable trustworthiness
  • To demonstrate feasibility of the framework by applying it to delivery of open-source software for integration on desktop PCs
  • To have procedures and practices that end-users, system administrators, and integrators can apply to confirm the level of trustworthiness asserted for a program

  
Project Sketch:
Computer end-users and IT organizations find they must trust in the software that they use, having few means to directly appraise the steps taken to assure the trustworthiness of software that is offered to them.  Although trust is a factor in the adoption of any software components for use, commercial adopters also express concern about the authenticity, legality, and quality of software obtained from open-source distributions.  It is troubling when there is no distinct commercial organization that bears producer's risks and stands behind the software.
  
TROST consists of a framework and procedures that are useful for incorporating trustworthiness assurance into the development and delivery of open-system software, demonstrating such assurance, and verifying the assurances.
  
The goal is to enable adopters of a software product to confidently establish:
  • Whether the software distribution is authentic, and what that means
  • Whether the software is certified to be derived from the "official" source code, and how that can be and has been independently verified
  • Whether there are assessments of the security, reliability, and integrity of individual source code constituents, how authoritative those assessments are, and the availability of details for independent review
  • Whether the covered subject-matter of the software license has been asserted to be free of conflicting intellectual-property restrictions by its producers/contributers
  • Whether a security threat model is defined for the software that addresses reconciliation to an overall threat model for the application in which the software is to be used
  • When modifications and even revocation of assessments come to light, and any remedies that are available for discovered deficiencies in the software

I fancy having each installable component be linked with the latest certifications asserted for it, supporting trustworthiness as a dynamic.
TROSTing, did you say TROSTing?  More and more, I do say that.  It all started because TROST was not availabe as a domain name.  After looking for alternatives, I settled on TROSTing an an useful expression for the practice of raising the trustworthiness of open-system components.

I found another interesting domain name.  It's for email:  trust@worthiness.org  Not an original device.  I couldn't help myself.  It's not working yet, so hold back on the spam for now, ok?

On to Literature Search.  Now I get to suffer the fear and doubt of every postgraduate student.  It's all been done already, it's been shown as not worth doing already; and so on.  Yes, I am interested in leads to existing work, proposed work, past work, and the wisdom of the ages.  I am.  So lay it on me.

 
Comments: Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating the Blunder Dome

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 06-02-03 22:44 $
$$Revision: 2 $

Home