river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Fri, 01 Oct 2010 11:21:27 GMT
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 

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.


I think corporate environments are generally slow adopters of technology.



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

View raw message