Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 SRS0=gNoar5=RD=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.118 as permitted sender)
Message-ID: <4CA603A1.8060105@wonderly.org>
Date: Fri, 01 Oct 2010 10:52:01 -0500
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: river-dev@incubator.apache.org
CC: Sim IJskes - QCG <sim@qcg.nl>
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au>
 <50E73BFB09C740C399530A7042EBDC5E@irt.vein.hu> <4CA313A3.60709@qcg.nl>
 <4CA3A549.3050903@zeus.net.au> <4CA3B37A.5010008@wonderly.org>
 <4CA5AC57.9000100@qcg.nl>
In-Reply-To: <4CA5AC57.9000100@qcg.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

On 10/1/2010 4:39 AM, Sim IJskes - QCG wrote:
> On 09/29/2010 11:45 PM, Gregg Wonderly wrote:
>> For myself, the primary consideration is whether the arguments in RPC
>> calls are actually "downloaded classes" vs "downloaded data". In the
>> simple sense, "downloaded classes" are "downloaded data".
>
> I agree with you. A downloaded class is a specialization of downloaded data. Or
> maybe even not, but lets not go there.
>
> In general terms, a class has more degrees of freedom than data. Because a class
> is executed by a turing complete state machine and most of the time the machine
> executing data is less complete.

Trust is what I was trying to point at.  People download XML, Javascript on web 
pages, zip archives, executable programs and all kinds of things what at some 
point the data, becomes "the semantic meaning" and gets used by some "machinery" 
to cause action.

There is never validation done about anything more than structure (DtD, schema) 
of things like XML, or "machine magic number" for executables etc.  Only some 
simple evaluation of "will the machine accept this input" is done.

With Jini, people are constantly burdened by the whole idea of "what can we 
trust about this code", or "how can we prove no harm will come".

The answer is that only through exhaustive means can you do that for any 
instance of "the downloaded code", and what httpmd: and other similar things are 
about, is "identifying a version" that has been "evaluated" to be "what you 
expect".

Web sites publishing source code, binary distributions and other things that 
need to be trustworthy, also publish "hashes" of the "contents" to help people 
evaluate that they have "the right stuff".

So, I think we have ample ability to provide people multiple levels of trust 
assertion and trust evaluation already.

The problem is that we really feel like it needs to be "individual permissions" 
because that's the "tightest security model" that we can see and it seems very 
attractive to use it.  In the end, there are places where that is necessary, but 
more often than not, it is a large barrier which makes it very difficult to say 
"I trust the code" trivially.

For example, we don't have mechanisms which would allow a ServiceUI client, to 
"see" a service in the registrar, and only after seeing it and its source, 
signify trust, and then download code.  The original design has always been 
around the concept of "you start the VM with the trust asserted" and then it can 
only do what you've entrusted it with.

We need a lot more dynamics so that we can really see how hard it is to create 
real, working mechanisms for dynamically changing the trust relationships 
between the clients and the services.  And it needs to work remotely so that I 
can tell a service that it can use another service through administrative 
interfaces.

Gregg Wonderly

> My personal view on this matter revolves around the burden it puts on the user.
> When i download code and run its installer, i trust the code to well behave.
> When i run the installer i make one big trust decision. I can audit the files
> installed if i'm really paranoid, or a security researcher. When i run my jini
> application, it connects to some registry, downloads a jar into memory and
> executes it. This jar can be same as yesterday or it might not. I can't tell.
> Does it perform the same function?
>
> The basic components are the same, but i see distinct differences. Do you see
> this agility to take off in a corporate environment?
>
> Gr. Sim
>