Excellent point Tom! It would also be nice to see information about what shared access is required when installing. Yes, more work for both the coder and end user, but much more secure.
As is stands now, I don't install hardly any apps that want internet access unless I feel I really need that app. This limits the number of apps I'm willing to download and try out. Giving me the option to deny permissions would be wonderful. Perhaps the next update (Cupcake -> Fruitcake? :P On Tue, Apr 28, 2009 at 6: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 to www.paypal.com, s3.amazonaws.com, and www.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 at http://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 -~----------~----~----~----~------~----~------~--~---
