Posts mit dem Label security werden angezeigt. Alle Posts anzeigen
Posts mit dem Label security werden angezeigt. Alle Posts anzeigen

Donnerstag, 11. November 2010

ScientificPlotter - an security overview

Security has become more crucial nowadays and specially on a mobile phone. Because of that, we want justify the permissions ScientificPlotter claims.


As you can see on figure the figure below, that we tried to keep the permissions as few as possible, basically there are only two permissions we need

Storage

This permission came up with a somewhat antiquated idea. Nowadays everything is shared over common ways: email, bluetooth, sms/mms, Picasa and so forth but if you just want to save the plot to your SD Card than this permission allow us to do it. In principle this is only for saving screenshots on your SD Card in a specific folder called ‘ScientificPlotter’.

Network communication

This permission is very important and we use it very dutiful. Well I don’t have to tell you that this permission gives us full Internet access, but what for? We have built in an open-source error reporting framework called ACRA (Application Crash Report for Android). This rather powerful framework is for the case which hopefully never should occur, a bug. When an unexpected error occurred forcing the application to stop, ACRA send a notification to your notification bar, asking you for allowance to send the error report. And because the system is open-source you can convince yourself that it does nothing evil. 

A common error report 
  
The information we send consists of hardware and software information, as there are the manufacturer, the model, the firmware, the Android version, how many memory was available as the error occurred, when does it occurred and the significant stack trace which give us access to the root of the error. 

Advertisement

As you probably noticed ScientificPlotter is ad-supported by the Mobclix ad-exchange service. To ensure that the advertisement banners are provided properly, the Mobclix SDK needs additional three permissions. These three permissions and their description are extracted from the manual:

android.permission.INTERNET
Used to retrieve ads

android.permission.GET_ TASKS
Used to determine if the application is the top app, to prevent ads from loading while the app is in the background.

android.permission.READ_PHONE_STATE
Used to obtain a unique device identifier.

Endian Ogino 

Mittwoch, 13. Oktober 2010

Security & Android

Security is a crucial fact on mobile operation systems. Everybody knows that common pc-operation systems are a great market for antivirus, antimalware, firewalls, antiphishing etc. (antivirus hit count at Google search 63.500.000 @ August 2010!). But what about mobile phones?
Taking myself as an example, I have a lot of private messages, all my contacts, and personal notes on my handset. Some of them for example my contacts, are synchronized with Gmail, a fact that is on one hand great, because all my contacts are save and feel cosy on the cloud, but on the other handy these contact data do not belong to me anymore because there are on a Google server somewhere (maybe offshore in the future) and so propartie of Google. 
But my data is save on an empty handset (at least I think so) but what if I install hundreds of various apps, each from another developer with different kinds of interest and intents. Well here comes Androids security system into play, when a developer for example wants to open a http socket it has to get a internet permission from the system, by adding these to the app Manifest.xml

 <uses-permission android:name="android.permission.INTERNET"/>

Now the developer has access to the internet, but what is he sending stays behind iron curtains. And here lies the fundamental problem within Androids security model.

Recently I have found a report made by SMobile systems from June 22, 2010. Citation from the report: “To date, metadata collection has netted information from 48,694 applications in the Android market, roughly 68% of all applications that are available for download. […] Further analysis indicates that of the 68% of the Market applications that have been queried, 20,786 of those applications would be considered to be suspicious because they request two or more of the permissions that would grant access to personal information or services that could be used incorrectly.”
Furthermore the report shows the distribution of notable permissions requested against apps relative app counts

In conclusion it is worth mentioning that there are users who are mindful and think twice before the install an app with a handful of permissions, but also there is a not negligible amount of users who install first and hopefully think afterwards what they really installed


Appendix:

Also check out