Free mobile apps may introduce security risks that need to be addressed. While businesses need to find ways of monetizing when consumers are not ready to pay directly for using an app, monetization mechanisms that involve the use of user data should be legal, secure and an informed choice. A bigger disussion follows.
80% of the apps were free in 2011, 95% of the apps expected to be free by 2017
In last few years, mobile apps have seen a general downward pressure on pricing. A Flurry analytics report on app pricing show that while 80% of the apps were free in 2011, the number of free apps has increased to 90% as of 2013. Even the price of paid apps showed a lower revenue per app—in 2011, 15% of paid apps had a price close to $0.99, by 2013 only 6% of apps had this price point as the free apps increased. In a press release early this year, Gartner also confirmed this trend when they said that 95% of the total apps (across all OS’) would become free by 2017.
So how do app developers make money on their apps?
There are three specific trends:
- Freemium route with in-app-purchases – This is a growing trend. App developers bifurcate their feature set between free and paid. The idea is to hook users through a free offering and provide offers to the user that would like to get access to richer feature set in a paid version. In some cases, some of the app activities, some of the app enticements are available through in-app-purchases.
- In-app advertisements - Many app developers embed various kinds of advertisements with their app through the use of ad-libraries. Every impression/click earns revenue for app developer. There are many app developer libraries including one from Google.
- Sponsorships – This is only relevant for a very small group of app developers. In this case the entire cost of the app’s engineering and operations is covered by an outside sponsor. For example, Subway sponsored the ING New York City Marathon app.
However, we have seen some worrying trends!
- Over-aggressive ad-libraries – Some of the ad-libraries that app developers normally use for monetization were found to be over-aggressive in collecting user details. A couple of these ad-libraries were collecting details related to a user’s calendar, tracking their locations, last call details, etc. This is something that is beyond the normal realm of ad-libraries. We also had a one-off case of Yahoo! ad-libraries delivering potential scareware to consumers.
- Willful encroachment of user privacy – Some apps have questionable privacy policies and sell user data to marketing companies without users’ explicit permissions. And other apps such as Path, deliberately upload users’ contact lists without users’ explicit permission.
- Embedding risky URLs - Between April and June 2014, McAfee analyzed approximately 733k apps. Out of those almost 95k (12%) of the apps were found to contain at least one risky URL. While in some small cases this might have been willful insertion, this largely could be attributed to developer ignorance and lack of stricter quality controls in their app development process.
- Weak implementation by app developers - Recently Credit Karma and Fandango were fined by FTC for having exposed sensitive user data by not implementing secure communications between device and their servers. This was due to them not including SSL as part of their implementation when transferring sensitive user data over Internet.
What can be done to address this situation?
Many of the action items clearly lie in the hands of app developers. While the trajectory for app monetization would lie in alternate means as documented earlier, however lack of focus on user privacy/safety would blow up on app developer if they are not cautious (as it happened on Path, Credit Karma and Fandango). The following four suggestions could be considered by app developers:
- Be extremely cautious of ad-libraries with past incidents – An app developer should look for past privacy violation of any ad-libraries that you are considering to integrate with your app. Also, remember that ad-libraries may not improve your monetization, but a single bad ad-library may destroy your reputation or get you into legal trouble. Also, always read through privacy policies of ad-libraries to understand how they plan to use user data.
- Check for URL reputation before adding it to your app - Embedding public facing URLs without validating their security status may put user at risk. An app developer may use McAfee’s free URL verification service to validate a web link before using it into his/her app.
- Follow a privacy-aware development practice – An app developer should be aware of secure coding practices and ensure that privacy needs are met. Here is an excellent book written by McAfee privacy experts that could be used for reference: http://www.amazon.com/The-Privacy-Engineers-Manifesto-Getting/dp/1430263555.
The post Free Mobile Apps = Compromises On User Safety? appeared first on McAfee.
Compromised Snapchat accounts have sent out photo messages of a box of Garcinia Cambogia, followed by a chat message with a suspicious link containing ‘groupon.com’ in the URL.
So last week the big news was about the cross platform exploit in BASH that we covered in our article – Everything You NEED To Know About Shellshock Bug In BASH. As mentioned in the comments, a certain combination of circumstances and configuration options can leave OpenVPN vulnerable to Shellshock. This could be a pretty [...]
Read the full post at darknet.org.uk