> There is nothing which prevents the > publisher [...] to transfer data from one app to the other for the purpose of > maliciously snooping on user data.
Good point! This means one should be *either* very careful with applications that require permissions to read contacts or similar, *or* be very careful with applications that communicate to the outside world. For one of the two kinds of apps one should only rely on trusted publishers or open source projects :-) Peli www.openintents.org On Apr 28, 1:40 pm, Tom Gibara <[email protected]> wrote: > Two examples among many, but they do highlight two of the most common > dilemmas for users. > I'm not convinced that the general usefulness of a 'domain constrained' > internet permission outweighs the complexity it is certain to entail (eg. > wildcarding subdomains is usually necessary to make it practical, and > implementing it would probably be very awkward, there might be performance > issues too). > > Anyhow, I have strong reservations about the security model in general. It's > much better than nothing, and has the virtue of simplicity but my biggest > issue with it is that it does nothing to protect you from collusion between > applications. > > To go with your example, one publisher might have an accounts app (which has > requires no internet permission) and another which is say a "tax guide" that > pulls webpages down from their servers. There is nothing which prevents the > publisher either using a sharedAppId, content provider, or even using the SD > Card, to transfer data from one app to the other for the purpose of > maliciously snooping on user data. > > In the latter two cases (transfer via content provider or SD card) the apps > could even come from separate publishers who are colluding. I've not seen > anyone else raise these concerns, but it's something that has troubled me > for quite a while. > > Tom. > > 2009/4/28 Al Sutton <[email protected]> > > > > > To me selectable permissions is the only user empowering way to go. > > > Take a couple of current examples; > > > 1) If an accounts package wants the internet access permission you have the > > choice of give it full internet access which it could use to send your > > account details anywhere or not using it at all. > > > 2) If a messaging program wants location facilities you have the choice of > > not using the program, switching off location providers and screwing over > > anything you did want to use location facilities, or handing over free > > reign > > to it to publish your location whenever it wants. > > > Yes it would involve more work for developers, but imho we shouldn't > > sacrifice user experience for ease of development, we should force > > developers to step up their game to deliver apps that give the users > > control > > over what their 'phone and the apps on it can do. > > > Personally I think the Internet permission is the worst offender and should > > be a lot more fine grained so that developers can specify endpoints and > > users see messages like ("This app wants the following permissions; > > Internet > > access towww.paypal.com, s3.amazonaws.com, andwww.andappstore.com"). The > > current unlimited permission should be carried over if the app really needs > > access to any server on the net (and to maintain backward compatibility), > > but we should be looking to persuade developers to tell users exactly what > > sites their data may go to. > > > Al. > > > --- > > > * Written an Android App? - List it athttp://andappstore.com/* > > > ====== > > Funky Android Limited is registered in England & Wales with the > > company number 6741909. The registered head office is Kemp House, > > 152-160 City Road, London, EC1V 2NX, UK. > > > The views expressed in this email are those of the author and not > > necessarily those of Funky Android Limited, it's associates, or it's > > subsidiaries. > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Mike Hearn > > Sent: 28 April 2009 12:03 > > To: Android Discuss > > Subject: [android-discuss] Re: Technique to Avoid, #2: Directly > > Manipulating > > Settings > > > > So if you grant someone the permission and they screw you, google will > > > say:it's your fault. Our Android is secure, it's your problem if you > > > accepted permission without reading. > > > The difference between a typical EULA and the permissions screen is > > enormous. I don't think they are comparable. > > > The problem with letting people selectively enable/disable permissions is > > that now apps have to handle every possible combination of permissions. > > Some > > of those they will actually need to do something useful, so you don't win > > by > > letting people toggle them on/off, you just force devs to add their own > > dialog box showing how to go toggle the permission on. > > > I agree that Android needs a better way to handle optional permissions, and > > I think prompting at runtime the first time they are requested would > > provide > > a good user experience. But this has come up many times and the Android > > core > > team don't like it, so, for now let's drop it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
