In Part 3 we covered the three generic software installation models, that are common to these 4 smartphone OSs (iOS by Apple, Android by Google, Blackberry by RIM, and Symbian by Nokia). In this final post in the series, we’ll dig a little deeper on the app marketplaces and application vetting processes.
Most smartphone vendors provide a third-party application repository (or marketplace). Depending on the software installation model used (covered in Part 3), the marketplace requirements may range from rigorous vetting to simple inclusion for convenient searching and rating. It should be understood that inclusion in the marketplace in no way implies substantial vetting, admins and users should be informed.
In the Walled-Garden model, the repository serves as a choke point – if the application doesn’t pass, then it’s not included. This comes at a cost of course, as the vendor must ensure proper testing. In the Guardian model, there is a balance between control and distribution, there could be more control and testing and vetting in the repositories sponsored by the vendor. In the User Control model, it’s pretty much a free-for-all, where the repository is just simply about distribution.
So, what kind of tests do the applications undergo before being included in the more controlled marketplaces? Well, turns out the vendors are a little cagey about this and information is not freely available. Here is a list of some of the tests that could/should be included:
- Smoke tests: are basic tests that ensure that the apps don’t fail catastrophically (i.e. just don’t work at all). They are the first entry point of any testing, to determine quickly if testing should continue.
- Hidden-API checks: these ensure that the developer is not using API calls that are reserved for the OS vendor and their system apps.
- Functionality Checks: covers basic functionality and makes sure that the application behaves well with others applications.
- Intellectual property, liability, and terms-of-service checks: help ensure that trademarks and terms of service are respected, by searching for specific keywords or inappropriate content or behavior.
- UI checks: more important for vendors who emphasize user experience (i.e. Apple), these tests ensure that apps are towing the UI line and complying with UI guidelines.
- Bandwidth checks: to ensure that an app isn’t hogging more bandwidth than it should, these are done more heavily on streaming apps.
- Security checks: it is not yet clear if any vendors perform security checks.
So, as you can see, one size does not definitely fit all. Admins and users should educate themselves and consider the following when making their smartphone security choices: the environment in which the phone will be used, the level of knowledge of the users, the software installation model, and the application testing process. Smartphones are increasingly becoming targets of malicious software and as the popularity grows, you can be sure that crackers will focus more on them.
I hope you enjoyed this series and will share with us the specific trade-offs you’ve had to make and what decisions they led you to with your smartphone security.
Smartphone security series (4 articles):
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 1 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 2 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 3 of 4
- Smartphone security: an overview of security frameworks and controlled app marketplaces Part 4 of 4
(This series is based on an article in IEEE Security and Privacy Magazine, May 2011, by Dave Barrera and Paul Van Oorschot – http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5674007)
Leave a Comment