My vision of the the domain based internet security is a simple one; string pattern matching with full subdomain access. So if an app says it wants access to paypal.com it would get access to any subdomain (or subdomain of subdomain, etc) of paypal.com. The system libraries could then throw an exception if that app tried to do a DNS lookup on any DNS name other than those domains specified in the list specified in the permissions by doing a simple loop over the list of permission allowed domains and endsWith check on the DNS lookup request. The DNS lookup result is then cached as an approved entry and traffic to that address allowed. The only really tricky part would be dealing with protocol level redirects which went outside the domain (e.g. HTTP 3xx return codes), but that isn't overly complex if it can all be handled in the system libraries. Enhancing it further could add rules for checking for overly wide permissions (e.g. a request for just .com, .net, or .co.uk). To me this would give Android users similar features to those many PC users buy firewalls and anti-virus software for, which I'm sure the Market person (who I think sits next to a unicorn and the easter bunny) could get a lot of mileage from. 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. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Tom Gibara Sent: 28 April 2009 12:40 To: [email protected] Subject: [android-discuss] Re: Technique to Avoid, #2: Directly Manipulating Settings 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 -~----------~----~----~----~------~----~------~--~---
