Top 10 challenges in Mobile Privacy
Every week we hear about a new privacy scandal with a mobile company involved. Google, Apple, Pandora, Carrier IQ, Path and Hipster are only a few examples. So who is next? And why anybody should be next? Why is it so difficult for companies to achieve privacy-by-design on mobile? This blog outlines some of the reasons.
Apps are now tracking.
Unlike in the old desktop word where a web browser is a “single point of data leakage,” in mobile, apps are meant to be “connected” by design and are commonly supported by advertising. As a result, almost all apps collect and transfer user data in a numerous ways.
Best practice: App developers should seek independent third-party verification of their apps if they want to increase consumer trust and lower regulatory risks.
Advertisers provide in-app SDKs that Publishers cannot control.
Best practice: App developers should consider working only with the SDKs of certified third-parties whose data collection and usage practices have been independently verified.
The mobile ecosystem is much more diverse.
It is not just regular apps who collect user data. There are also ad networks, ad aggregators, mobile carriers, platform vendors, ad network in-app SDKs, and data aggregators – all technically able to access a device in a multitude of uncommon and technically diverse ways.
Best practice: Ad Networks and app developers should collect and honor consumer privacy preferences in a way that is uniform and consistent across multiple ecosystem players.
There are several different platforms.
Apple iOS, Google Android, Blackberry and Windows 7 – all have a sizable market share, yet different architecture, privacy and permissions systems. That makes establishing uniform privacy guidelines very difficult.
Best practice: The companies who work with different mobile platforms should adequately describe the privacy-related peculiarities of these platforms in their privacy policies, which they should display in a consistent format.
There are no reliable cross-platform identifiers.
Mobile opt-out cookies can no longer be relied upon for an opt-out mechanism when browsers like Safari disable them by default, and after Apple announced the deprecation of UDID identifier the industry has considered using all sorts of other identifiers: MAC Address, IMEI equipment identifier, IMSI subscriber identifier, device fingerprints (BlueCava’s, 41st Parameter’s, AdTruth’s), and custom identifiers (AppsFire’s OpenUDID, OpenFeint OFUID single-sign on, and Mobclix’s ODIN.)
Best practice: Developers and Ad Networks should consider adopting a uniform and private-by-design identifier that would allow consumers to express an opt-out or opt-in preference based on their jurisdiction. (US vs EU)
Tracking now is happening in both app and web.
When a consumer opts-out from tracking by a particular company, he or she usually expects to opt-out from it across both app and web. However, this is often impossible because the browser cannot read system identifiers such as UDID or MAC Address, and applications cannot read browser cookies that are not from their domain.
Best practice: Companies should rely on a user identification mechanism that would be accessible from both the regular mobile apps and browser web sites.
Mobile web Publishers are often involved into the ad chain.
Best practice: Mobile web publishers should thoroughly examine the third-parties they work with to vet that the privacy practices of those third parties are consistent with the practices the publisher describes in their policies.
Applications transmit user information in ad calls.
Mobile Ad Networks normally require Publisher apps to transmit unique identifiers, such as UDID or Android ID, in an ad call. Even if UDID is the only thing that an Ad Network receives from the apps, it can still build an “anonymous” profile containing the information about what apps a person uses, how often, at what time, for how long and from what IP addresses. In practice, app developers pass much more data. Transferring zip code, age, gender is common practice now.
Best practice: Publishers should list the types of data that they transfer to the Ad Networks and Data companies in their privacy policies.
Mobile phones know users’ location.
Regardless of whether users enable or disable precise location services, the carrier will still know users’ approximate location and wireless access points’ IP addresses. An unscrupulous app can ask users for access to their location over and over again until they succumb, which is when compliant apps may inadvertently get access to it too and assume that users are ok with them using it.
Best practice: Applications should disclose whether they use location services, and provide information on how to disable precise location services indicting whether it can be done at the app level or must be done at the device level.
The size of mobile screens makes complicates disclosure.
Best practice: Companies should create a mobile optimized versions of their privacy policies so it would be easy for users to read and get the information they are looking for.
The proliferation of mobile devices quadrupled the privacy challenges previously attributable to desktops. Every week companies from Google to Path, from Carrier IQ to Pandora find themselves in the middle of a new privacy debate. So who is next? When Path was recently caught uploading users’ address books to its servers, its CEO Dave Morin noted in his blog that it was the “best industry practice.” As controversial as that comment was, he was right – it is the “best industry practice,” along with many other practices established without privacy in mind. It is time for the app developers, ad networks and platform vendors to wake up. Unless the companies take consumer privacy seriously and address it with proper disclosures and control mechanisms, the frequency of these scandals will only increase over time.