User:Mstone/Rainflow

Introduction

Software which cannot function in isolation exposes users to contingent hazards because users cannot perfectly distinguish benign from malicious software.

My goal is to define a family of decentralized ceremonies for use by authors, distributors, and consumers of software who wish to deal in evidence of software benignity.

How then might we begin to answer the scenario:

Suppose that we have mechanically acquired a program that purports to be Terminal-31 and that tells us that it is intended to be run de-isolated. Should we discard it, install it, or dialogue with the user?

Framework

In order to answer the question as posed, we need two things: policy and evidence.

By policy, I mean a labeling of a universe of actions according to whether and how they should involve user interaction and what, if anything, constitutes evidence sufficient to perform them automatically.

(I think we need this sort of policy to accommodate users whose needs vary, over both time and setting.)

By evidence, I mean roughly the information that decision-makers consume in order to reach good decisions.

Ideas

Policy seems like it can start off small -- just a pair of switches:

• a risk switch with two positions -- "I've got nothing to protect" and "I've got something to protect."
• an interaction switch with two positions -- "I never want to hear from you" and "I always want to hear from you."

Evidence should arise in the following way:

Witness Activity

1. People who want to create evidence about a subject should participate in a shared Witness activity.
2. Within that activity, they should generate a position about their subject.
3. All available witnesses should collectively certify the affidavit (i.e. the position, its consensus set, and the set of remaining witnesses) with a multisignature.

(NB: It seems reasonable to talk about an overarching relation among positions, consensus-sets, witness sets, and verifiers of same. I don't have a strong position yet on whether affidavits are precisely rows of this relation or whether they might be more complicated subsets of it.)

Peer review Activity

Instead of making it a pure "security" activity (that "just gets into the way" like any security stuff and thus will be circumvented) it might be better to use a peer review approach, helping both the author and the peers to learn (about security etc.) while doing the certification.

A shared "source browser" with highlighting/bookmarks and chat might be a good start.

Exploratory Implementation

For the purposes of exploration, and with no care for proper use of cryptography, we might take positions to be "the evil bit", e.g.:

My position on Terminal-31:

hash("ABCD0123").
name("Terminal").
version("31").
good.

My consensus set:

27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone
...

My witness set:

27A9023A3642A3638EF67511B6D5DCC8E1D5034E Michael Stone
...

Questions

SSL and browsers as they are used today.

What's the interesting evidence?

• cjb points out: attestations about country of origin are helpful for anti-phishing efforts because some countries' providers are much more responsive to complaints than others'.

What's the ceremony?

What business opportunities does Rainflow offer?

• (e.g. greater brand visibility to trustworthy attesters)?

Background

People in the OLPC community have been concerned with this question (and with variants and related questions) for some time:

<trac>5657</trac>, on spoofing-resistant update algorithms for de-isolated activities

questions on activity signing and update thread

activity semantics conversation

runtime build customization thread and <trac>6432</trac>

bemasc's user-created activities and updates thread

horizontal distribution thread

homunq's ideas on bundles and updates

Most likely, others have shared analogous concerns in their environments:

citations needed