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.

Atom Feed

Associated Blogs

Edge City

Numbering
Peano

Orcmid's
Lair

Praxis101

Spanner Wingnut's Muddleware
Lab

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:  [email-masked]  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.

posted by orcmid at 3/11/2005
11:09:00 PM, rating

data by NewsGator Online

Comments: Post
a Comment

You are
navigating the Blunder Dome

template
created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author:
Orcmid $
$$Date: 04-10-28 23:29 $
$$Revision: 15
$