Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4CAAF9C6.70709@qcg.nl>
Date: Tue, 05 Oct 2010 12:11:18 +0200
From: Sim IJskes - QCG <sim@qcg.nl>
Organization: Quality Consultancy Group b.v.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
References: <4C9DB5BF.8090307@zeus.net.au>
 <201010041425.19581.michal.kleczek@xpro.biz>
 <AANLkTikdr5ZOWQYs6uwqvRew_w8EAeuxmEgr9KO_qdfw@mail.gmail.com>
 <201010041843.22365.michal.kleczek@xpro.biz>
In-Reply-To: <201010041843.22365.michal.kleczek@xpro.biz>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

On 10/04/2010 06:43 PM, Michal Kleczek wrote:
> Let me explain my position better:
>
> IMHO the problem to solve is: how to securely exchange information between two
> parties without trusting third parties that u use to send/receive it?

By using cryptography.

> Your example with JPEG is actually excellent to illustrate my point. The only
> way to make sure you got your images from a trusted party is to _always_ use
> TLS - no web caches/proxies or anything like that. Once you have those -
> you're out in the dark.

Even when your HTTPS session goes through a proxy, it is still 
end-to-end. (unless you are victim of a MITM attack).

> It is no different than exchanging objects using untrusted ServiceRegistrars or
> code using untrusted code servers. It is actually no different than downloading
> a web page from your bank site - the bytes you actually download come from an
> untrusted router somewhere in the net anyway.

But the mere fact that this router is untrusted does not reduce the 
level of security.

> Also - relying on trusted third parties to download code gives you false sense
> of security - users of Android or iPhone that download apps from (trusted) app
> stores should already know that.

I'm not sure this creates a false sense of security. I've never thought 
is was secure. Did you? I much rather have my third party to be open 
about its practices than not.

> The solution is not to reject using proxies or any third parties. It is to
> 1. introduce a way for you to make sure the data you've just downloaded comes
> from the right source - no matter what means you used to download it.
> 2. restrict downloaded code as much as possible

The solution that is brewing does not reject proxies or third parties. 
It is more about accepting them, and remembering the trust choices we 
have made, and means to change this trust.

> Jini is almost there - we have Java security to restrict downloaded code and
> we have a way to verify if an object came from a trusted source. The only
> problem is that to do that we have to run some yet untrusted code. Let's just
> try to solve this problem :)

I'm still not sure if we agree or differ in opinion. Are you?

Gr. Sim