I definitely agree that there are tons of applications out there asking for permissions that they simply don't need. In most cases, I suspect it is developer oversight, but when you have some real stupid application, like one of the billion "slideshow" applications, and it is asking for permissions to do things like read contact list, sdcard contents, SMS, phone state, location, and network -- all together, you really have to wonder if it might be up to no good. Oversight or not, applications asking for unreasonable permissions shouldn't be installed.
Now IF google were to provide an option to disable permissions, then the *oversight* applications, or applications with added features you don't need can still be installed and used (securely), without giving them all of your private information. Note: There should NOT be an option for the application to ASK which permissions it has. This opens the door to malware running tricks along the lines of "we need all the permissions we ask for, go back and enable them". It must be on a try-and-fail basis. And I really like that idea with the try-and-its-fake-too-bad. As for the "crash" problem when requested permissions are denied... well the developer should take precautions to ensure that denied permissions don't crash the program. Of course I'm referring to use of appropriate try/catch blocks around code that needs permissions. On Jun 25, 6:36 am, tobias <[email protected]> wrote: > There is a very distinct difference between an App accessing personal > data (as e.g. a legitimate address book App would do), and an App > abusing personal data. The study by SMobile talks about access, not > abuse, although this is not how the press release is covered in the > media. > > Some background reading to the article: > > [QUOTE]SMobile Systems neglected to mention industry ties that > rendered its report less credible. [...] SMobile itself sells security > software to address perceived threats that its reports “expose”.[/ > QUOTE] > Source:http://www.zdnet.com/blog/burnette/cnet-retracts-article-on-android-a... > > The White Paper from SMobile that the news-flash is based on can be > found > here:http://threatcenter.smobilesystems.com/wp-content/uploads/2010/06/And... > > Quote from the White Paper: [QUOTE] SMobile has developed a > methodology and technology to determine potentially malicious > applications based upon the permissions granted the application.“ [/ > QUOTE] > > As example it lists: you can find an application by the name "SMS Spy" > on the market which SMobile classifies as a potential thread. Any app > that asks for the same rights as "SMS Spy" would then also be flagged > as a potential thread via the logic described by SMobile. > > You decide whether such a "Malware Scanner" would add value to you or > not. > > On Jun 24, 7:00 am, Chris - Diddo Team <[email protected]> wrote: > > > > > Readinghttp://www.pcworld.com/article/199621/20_percent_of_android_apps_can_... > > I can't help but feel cheated. > > > Undoubtedly the report used permissions to determine the 'security' of > > apps: the more dangerous permissions requested = more risk. > > > Of course this makes sense, but the report is missing several key > > points: > > > 1) Android Installer presents these permissions to the user. When > > installing iPhone apps, no listing of capabilities are shown. So > > users are informed. > > > 2) Just having the permissions doesn't mean the app can access the > > data (ie the app can only get GPS data if gps is turned on by the > > user) > > > 3) Most apps allow these features to be turned off (ie location can > > be disabled) > > > 4) Many times the internet permission is used only for ads, so the > > full danger of sharing/distributing this private data is blown > > overboard. > > > What do you think? -- 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.
