When we talk about "users" what do we mean? Who is the target? It sounds like trusting the service proxy that got downloaded is a Hard Problem to solve, is there any mileage is shifting things so we can instead solve a different problem?
Developers use stuff they download from Apache because of the reputation, or they'll use an Amazon or Google services because they know and trust the names. Securing Internet-wide ServiceRegistrars to only be *joined* by other trusted sources, and allowing easy download and use of those proxies is probably an easier security problem to deal with. As long as we trust that those SRs only have nice things on them, and that we can trust the download channel (SSL or similar). Then a lot of the "should I trust this proxy" issues just go away because the answer is implicitly 'yes'. When was the last time you analysed the contents of your newly downloaded log4j.jar, just to make sure it didn't contain anything nasty? In that example, you trusted the download site (apache.org), and you trusted the download mechanism (HTTP - now that was risky!), and then you trusted the stuff you downloaded. If you download log4j.jar from somewhere else, then trust becomes an issue and there is nothing to protect you from it. Other than the rapid sequence of "downloaded bad proxy --> computer explodes" compared to "downloaded dodgy JAR --> computer explodes", what are the differences between this example and downloading some service proxy? The same can be said from the average Joe Bloggs browsing for fun-looking services. He he downloads and runs something from somewhere he trusts (like a certain app store) then he'll be okay he can trust the code he downloads without having to restrict or protect himself against. If he gets a service from some other dodgy site, then, well, I hope he has a backup! You're never going to stop someone/anyone from downloading anything from anywhere and running it. If you make something idiot-proof, the universe will just come up with a better idiot. So my questions are: 1) Does this approach lack something compared to the "Can my client trust this proxy which I just downloaded?" approach? 2) Is enforcing security in the join mechanism easier? 3) Who else thinks it's time for lunch? Cheers, Tom On Fri, Oct 1, 2010 at 12:21 PM, Peter Firmstone <[email protected]> wrote: > 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 >> >> >
