Return-Path: Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org Received: (qmail 94138 invoked from network); 1 Oct 2010 11:27:46 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Oct 2010 11:27:46 -0000 Received: (qmail 13548 invoked by uid 500); 1 Oct 2010 11:27:46 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 13403 invoked by uid 500); 1 Oct 2010 11:27:43 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 13395 invoked by uid 99); 1 Oct 2010 11:27:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Oct 2010 11:27:42 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [61.9.168.140] (HELO nskntmtas02p.mx.bigpond.com) (61.9.168.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Oct 2010 11:27:34 +0000 Received: from nskntotgx02p.mx.bigpond.com ([61.9.223.241]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20101001112708.IRTP26019.nskntmtas02p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Fri, 1 Oct 2010 11:27:08 +0000 Received: from [10.1.1.2] (really [61.9.223.241]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20101001112707.JFCX4790.nskntotgx02p.mx.bigpond.com@[10.1.1.2]> for ; Fri, 1 Oct 2010 11:27:07 +0000 Message-ID: <4CA5C437.1050401@zeus.net.au> Date: Fri, 01 Oct 2010 21:21:27 +1000 From: Peter Firmstone User-Agent: Thunderbird 2.0.0.14 (X11/20080531) MIME-Version: 1.0 To: river-dev@incubator.apache.org 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 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4CA5C58C.00E0,ss=1,fgs=0 X-Virus-Checked: Checked by ClamAV on apache.org I think we have to be very careful about placing the burden of security decisions on users, history has shown the user makes bad choices. Perhaps what we could come up with are some questions to help determine trust. The user might be able to obtain some feedback from other's who have used the service. Then based on the feedback the user provides about the level of trust, we can determine if the Permission's the service has requested is consistent with the level of trust. We have to be careful of information loss and privacy first and foremost. Note that Google abandoned the Java fine grained permission model in Android. That aside, this research paper using tainted variables in Android holds some valuable lessons. http://yro.slashdot.org/story/10/09/30/1640223/Many-More-Android-Apps-Leaking-User-Data I think corporate environments are generally slow adopters of technology. Cheer, Peter. 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. > > 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 >