Mobile privacy in the US
Mobile privacy is a term used to refer to the privacy rights of users of mobile devices (such as smartphones, tablets and smart watches) that are different from and typically additional to the the rights of users of internet based services in general. Mobile services are typically offered through mobile apps.
Aside from mobile apps many organizations offer a mobile-specific version of their website, which should comply with all to the obligations related to the collection, use, and sharing of information that apply to websites.
Why are there special privacy considerations in mobile?
Mobile apps raise unique privacy concerns:
- Unlike PCs and laptops, mobile devices are portable and users often travel with them, which allows tracking of location. Mobile phones in particularly are almost always with us, more than any other physical objects we own except perhaps jewelry or glasses. Location information and travel patterns can be used to identify the user. For example, a 2013 Scientific report found 95% percent of cellphone users can be uniquely identified by using only four spatio-temporal points (that is, four points identifying their approximate whereabouts at an approximate time). Additionally, location data can be used to develop a profile of user’s interest for targeted marketing purposes.
- Mobile devices typically have many different sensors, including not only a microphone, camera, and keypad but also a heart-rate sensor, accelerometer, proximity sensor, etc. The data from mobile device sensors can be combined with data stored in the device (e.g. SMS messages and contacts) or with data from other sensors (e.g. digital pictures storing the location, time and day they were taken) which can create a detailed portrait of the owner. In addition, the data collected and stored can be instantly shared voluntarily (i.e. the camera and microphone allow for live video and audio recording and instant sharing) or involuntarily (see, Case study: Carrier IQ) with third parties.
- Mobile devices typically have small screens (or, in some cases, no screen at all) that make it challenging to inform the users about data usage in a effective way.
In addition, there are certain forms of user data that deserve special consideration in the mobile context:
- Geo-location information: Mobile devices are equipped with sensors capable of precisely identifying the location of the device and often travel with individuals. This allows the device to track precise user movements and locations. Geolocation data is very unique: researchers have found that four spatio-temporal points are enough to uniquely identify 95% of the individuals. Apps may have access to geolocation data even when they are in the background without the user being aware. Platforms have taken steps to stop third-party applications in the background from accessing location. Once an app is closed, platforms may heavily throttled or entirely stop location data access in some cases. However, there are apps that do need background location data access for helpful purposes (like locating a lost phone or and health tools) and permission settings exist that enable such access. Those permission settings can be intentionally or inadvertently abused by app developers to gain background access to location data they do not actually need without users consent or awareness.
- Contacts: Mobile devices typically store information on friends and contacts of the -user in the form a directory an apps can have access to such contact information, including email addresses, phone numbers, and physical addresses of user’s families, friends, colleagues, and acquaintances. They also include contact information about the user, as users typically store their contact information in their address book. In addition, the credentials that are used to log into accounts in many cases include users emails, as users tend to provide their email as their identifier for account access. Account management information is stored by the operating system and can be shared with app developers in some cases.
- Photographs, video and audio recordings: Mobile devices are frequently equipped with a camera and a microphone and used to store photographs, video and audio recordings.
- Identifiers: Specific persistent identifiers can be used and shared in the mobile ecosystem that enable the permanent identification of users. Even non-persistent identifiers (such as Ad-IDs) can de-facto identify an individual if they are infrequently reset.
Who are the players in the mobile space and what are their respective responsibilities?
Several mobile ecosystem players are capable of accessing data provided or created through a user’s interaction with a mobile device. There are several players in the mobile ecosystem including:
- Mobile app developers: App developers develop, market, and distribute the mobile apps. Mobile app developers typically create apps by writing some of the software integrated in the app (the app developer library) and acquiring software from third parties (mobile SDK developers) that is integrated in the app. A company that puts out an app is considered the app developer regardless of whether it wrote the app’s code itself, integrated code from mobile SDK developers and/or obtained the services of a software developer vendor who actually wrote the code for the app.
- Mobile SDK developers:Mobile software developments kits (mobile SDK) provide a convenient method for businesses and individuals to easily create an app and get it published on marketplaces.They are third party code that is integrated into apps by mobile app developers because it enables them to create apps in a fraction of the time that would take to code the entire app from scratch (which may actually require expertise and skills the app developer may not necessarily have). Many apps use a common set of mobile SDKs. As a general rule, mobile app developers are legally responsible for the compliance with privacy requirements of the SDK’s they integrate and are expected to inspect and understand the SDK’s data collection, use and sharing behavior. This is also the case when the developer integrates software from mobile ad networks and analytic providers that serve ads within apps and may collect and analyze users’ information across multiple mobile apps.
- App platforms: Enable app developers to distribute their apps through their app stores (e.g. Apple’s iOS, Google’s Android, and Microsoft’s Windows Phone) and control the data that is accessible to the app itself. In addition, all platforms pre-load certain apps developed by the platform into the device some of which are mandatory and cannot be erased.
- Mobile carriers: Provide wireless communication services. Mobile carriers typically require that certain software be embedded in the device for tech support purposes, network quality monitoring or enhancing, or as bundled services (i.e. TV access). (See, Case study: Carrier IQ)
- Mobile device manufacturer (sometimes referred to as OEMs): Design and market the mobile devices onto which apps may be downloaded. Regulators expect manufacturers engaging third parties that will have access to user data to (1) perform a due diligence and enter into a contract that spells out practices; (2) monitor performance; and (3) disclose third party data management practices in privacy notice. (See, Case study: In re BLU and Case study: Carrier IQ)
- Other third parties: There are other third parties in the mobile sphere, such as social media platforms that enable users to authenticate into app accounts using their social medial login credentials which typically requires the sharing of information between the mobile app and the social media account.
US regulators have made it clear that app developers are primarily responsible for providing protections and transparency regarding the use of data but all players bear responsibility to a certain degree.
Sources of legal requirements and best practices for mobile privacy in the US
Although some legal requirements apply, the US mobile privacy frameworks is mainly built around best practice guidelines.
In the US there is no overarching data protection law but there are many federal and state informational privacy laws.
- Regarding marketing send to mobile devices, the Telephone Consumer Protection Act of 1991 (TCPA) (47 U.S.C. Sec. 227) restricts the ability to leverage automated telemarketing in the mobile ecosystem by prohibiting the use of automatic telephone dialing systems (ATDSs) and prerecorded voice technology to market themselves absent express written consent. Express written consent cannot be made a condition of purchasing property, goods, or services (although at least one circuit has deemed consent written into a leasing agreement as valid and one court has held that an online offer to sell including a phone number with no specific reference to restrictions regarding calls is valid consent under TCPA- see Resources Reyes v. Lincoln Automobile Fin. Servs. And Edelsberg v. Vroom Inc.). In addition, telemarketing calls or telemarketing texts cannot be sent to numbers in the national do-not-call-registry (NDNCR).
- Also, sector specific regulations can impose restrictions on the processing of data in the mobile space. For example, the sharing of data by financial institutions is subject to restrictions under the Gramm-Leach-Bliley Act (GLBA).
- In addition, state laws also may impose mobile privacy requirements. For example, under California law both the California Online Privacy Protection Act (CalOPPA) and the California Consumer Privacy Act (CCPA) impose obligations or organizations that operate in the mobile space.
- To the extend the contents of communication (as opposed to record data such as telephone calls origination, length, and time) are captured, this may implicate the US Wiretap Act and additional restrictions may apply at the State level (See in resources below case-law: In re. Google Inc. cookie placement litigation and Vasil v. Kiip, Inc) .
- Finally, both at the federal level and at the state level general privacy practices may be required by governmental agencies responsible for consumer protection in general. For example, the Federal Trade Commission has initiated enforcement actions against app developers for privacy violations pursuant to its authority under Section 5 of the FTC Act, which prohibits organizations from engaging in ‘unfair and deceptive acts or practices’
The main federal mobile privacy guideline is the FTC Staff Report ‘Mobile Privacy Disclosures FTC Staff Report | February 2013 # Building Trust Through Transparency’ from 2013. In 2013, the FTC also held workshops on mobile payments identified three areas of concerned: dispute resolutions with users regarding possible fraudulent or unauthorized payments; data security of card information; and privacy (See, Paper, plastic…. Or mobile?: An FTC workshop on mobile payments). In 2018 the FTC released additional guidance on mobile security updates: Mobile Security Updates: Understanding the Issues. These reports encourage transparency and privacy by design but do not include mandatory. They however serve as a road-map for regulators investigating mobile app data management practices.
The California Attorney General (CA AG) also released mobile privacy guidelines in 2013 (Privacy on the Go: Recommendations for the Mobile Ecosystem). Additionally CA AG and a number of mobile apps market companies (Amazon, Apple, Google, Hewlett-Packard, Microsoft, and Research In Motion Limited) signed a joint statement to provide creative and forward-looking solutions that give consumers greater transparency and control without unduly burdening innovative mobile platforms and application developers (Joint Statement on Principles). As their federal counterparts, the CA AG guidelines are not mandatory rules but serve as important road-maps for compliance.
Several self-regulatory initiatives have also released mobile privacy guidelines such as Short Form Notice Code Of Conduct To Promote Transparency in Mobile APP Practices (NTIA); Best practices for mobile application developers (FPF/CDT); and Best practices and guidelines for Location-Based services (CTIA). These guidelines have not been submitted for approval to any regulatory agency and, therefore, have no legal status. However, US regulators have mentioned some of them in their reports applauding the efforts.
US Mobile privacy compliance: Privacy by Design and Transparency
US mobile privacy compliance centers around two concepts: Privacy-by-Design and transparency.
Mobile ecosystem players should adopt a Privacy-by-Design approach ensuring to ensure privacy is taken into account throughout the whole engineering process and users are provided meaningful control over their data.
In general, PbD requires developers to:
- understand exactly how the mobile app will function;
- identify what information the app needs to perform its basic functions and what information is desired but not required;
- list any sensitive information that the app may collect or use and expressly disclosing this fact to users;
- identify any third parties that will collect app data or run app analytics and understand what information the third party will collect and how it will be used; and
- test the app prior to release to assess its data collection and use.
Geo-location & PbD: As the Goldenshores case study shows, US regulators particularly scrutinize geo-location info. In addition to the initial notice provided when first accessing geo-location, CTIA guidelines recommend developers to:
- disclose how long location information will be retained or if the retention period will vary based on the circumstances;
- disclose what what location information will be shared with third parties;
- disclose when location information will be used for new or materially different purposes; and
- periodically remind users that location information will be shared with others. (See Resources below for the CTIA guidelines).
In addition, some platforms use standardized icons (typically at the top or bottom of the screen) to remind users geo-location data is being shared.
Persistent identifiers & PbD: In regard to persistent identifiers and identifiers in general, it is important to consider the privacy preserving characteristics of the identifier used. For example, in 2013 Apple began rejecting apps that referenced mobile devices’ UDIDs, causing developers and advertisers to rely on IFA instead (which enables the same function but can be reset and provide an opt-out mechanism to allow users to avoid behavioral advertising).
With the intention to preserve privacy, a feature to randomize MAC addresses was also introduced several years ago but its effectiveness has been heavily criticized. In March 2017 US Naval Academy researchers reported that they were able to “track 100 per cent of devices using randomization, regardless of manufacturer, by exploiting a previously unknown flaw in the way existing wireless chipsets handle low-level control frames” (see “Resources” below for a link to the paper).
Allowing access by/Sharing with third parties & PbD: Information collected through apps may be shared with third parties, including through code developed by third parties an inserted directly into the app (e.g. mobile SDKs). Developers are required to
- understand and monitor the data collection (if third party code is directly inserted in the app), use and sharing practices of those third parties; and
- disclose those practices to users (see ‘transparency’ below).
Developers should monitor third party behavior and seek appropriate contractual assurances. Finally, developers should consider whether a opt-out of sharing needs to be provided under CCPA (or opt-in for minors) and COPPPA. (See, Resources — Case studies — In re. BLU)
Retention policies & PbD: Although retention of data (even sensitive data) may be necessary to tailor features for better use experience, retention increases the risk that data may be leaked or misused. Therefore, app developers should only store sensitive data for the time necessary to operate the app. (See, Resources — Guidelines CA AG ‘Privacy on the Go’).
In developing their data retention policies, app developers should consider any relevant terms in their app developer contract with the platforms that directly apply to data retention.
When deleting data, developers should clear associated metadata and references to the deleted data or take steps to de-identify data so that it cannot be linked back to to an individual or device.
Access of data by employees & PbD: Access to data by employees should be limited to those with a legitimate business purpose for having such data. (See, Resources — Case Study Uber’s ‘God View’)
In order meet best mobile privacy transparency requirements organizations should not only post a mobile privacy notice but also consider providing short-form notices and just-in time notices
Mobile privacy notice: Developers should post and app platforms should require a privacy notice for each app with specific content.
- Post a mobile privacy notice (developers): In addition to the general privacy notice, under California law organizations need to create specific privacy notices for each mobile app to properly inform users of their data practices (See, Case study: Delta Airlines).
The notice should accurately describe the data collection, use and sharing practices of the app. Reflecting prevailing best practices, the CA AG guidelines (See, Privacy on the Go: Recommendations for the Mobile Ecosystem) recommends disclosure of:
- the types (for example, a username) or categories (for example, a unique device identifier) of personal information collected by the app;
- the uses and retention periods for each type or category;
- whether payment information for in-app purchases is collected by the mobile app or a third party;
- the types of third parties with which the app may share data;
- the choices that a user has regarding the collection, use, and sharing of PII, and instructions on how to exercise those choices;
- the process for a user to review and request corrections to the data maintained by the app;
- the way for users to contact the app developer; and
- the effective date of the notice and the process for notifying users of material changes to it. In addition, the notice should include any disclosures required by other applicable laws such as CCPA or GLBA.
The privacy notice should be easily accessible to users. Under California law the notice must be ‘conspicuously posted’ (See CalOPPA and CCPA), which for mobile apps means that it must be readily accessible to users. Similarly, the 2013 FTC guidelines suggest that the notices should be ‘easily accessible’ through the app store download page and emphasizes the requirement that the notice be available both before users download and install the app and in a permanent location to which the user can refer back.
In addition, COPPA requires online services directed to children under age thirteen to link to the privacy notice on the homepage of the mobile app itself.
Short-Form-Notices (SFN) (developers): SFNs are voluntary disclosures meant to highlight the key information practices disclosed in the full notice. To constitute best practices organizations must consider SFNs:
- Accessibility: Given the small size of mobile screens, it is recommended (but not required) that SFNs be displayed either in the app homepage or in the page where information is collected;
- Intelligibility: SFN should be written in plain and concise language and include icons that the user can click to get more information. (e.g. a location pin for location data; and
- Content: There is no standard set of terms but NTIA recommends including (i) the type of data collected by the app; (ii) how users can access the app ‘long-form’ privacy notice; (iii) whether any personal data is shared with third parties; and (iv) the identity of the app developer.
Developers may rely on short-form-notice disclosures provided by the platform provided that the platform disclosure precisely corresponds to the action taken by the developer (for example, if the platform discloses ‘religious affiliation’ will be collected but the developer wishes to not only collect but also share with third parties, the developer should disclose the sharing separately).
Just-In-Time Disclosures/Consent (developers and platforms): Just-In-Time disclosures (also refer to as ‘enhanced’ or ‘special’ notices) are notices displayed to the user just before the user takes an action that will cause information to be collected or shared.
Both the CA AG and the FTC recommend that affirmative express consent be collected through a just-in-time disclosure:
- the first time an app collects sensitive information (e.g. geo-location or health data) and/or
- collects information in an ‘unexpected way’
Collection, use, or sharing not required for the basic app functionality is considered ‘unexpected’. Examples include access to contacts, pictures or videos when not required for basic functionality, sharing data with ad-networks for behavioral advertising, accessing privacy-sensitive device features such as camera, microphone, or geo-location information, or accessing text messages or call-logs.
Also, when a change is made to the app’s privacy notice, a just-in-time disclosure informing of the change is best practices.
Just-in-Time disclosures should include the following content:
- explain the intended uses and third parties receiving the information and provide an easy way for users to choose whether or not to allow the collection, use or disclosure;
- make clear if the use of the app is contingent on obtaining consent; and
- include a link to the privacy notice if feasible.
To the extent an app must comply with the ‘direct notice’ requirement of COPPA, just-in-time-disclosures are a means for developer to comply with their obligations.
Third party access to app data /sharing with third parties:
Where a third party is allowed to access app data or app data is shared with a third party, the mobile privacy notice should
- disclose the fact that third parties will have access to user data and either name the parties or identify them by category (e.g. analytics provider);
- explain what information will be accessed and how the information will be used;
- if feasible, provide a link to the third party privacy notice; and
- if the third party provides opt-out options, provide instructions for opting out
(See, Privacy on the Go: Recommendations for the Mobile Ecosystem under ‘Describe your practices’).
If the collection/sharing is ‘unexpected’ or involves sensitive data (including geo-location), a short-form-notice should be used to seek affirmative consent.
The NY AG has taken the position that sharing of aggregated data should be disclosed (See Resources — Case Study In re Matis)
NOTE on ‘Friction-less sharing’:
Friction-less sharing exists where an app automatically shares data about users or user’s actions through a different mobile app or social network. It has not directly been address by regulators guidelines. Best practices for friction-less sharing include clearly informing users through just-in-time notices, making the mechanism an opt-in feature, and creating a delay between the interaction with the feature and the sharing.
- Golden Data: What are “persistent identifiers”?
- “Mobile App privacy: The hidden risks” by Christopher G. Cwalina, Richard Raysman and Steven B. Roosa
- ‘Why mobile advertising a a lot better of without UDID’ by Craig Palli for Venture Beat (June, 2013)
- ‘MAC randomization: A massive failure that leaves iPhones, Android mobes open to tracking’ Security flaws smash worthless privacy protection. By By Thomas Claburn (Mar 2017) for The Register.
- ‘A Study of MAC Address Randomization in Mobile Devices and When it Fails’ US Naval Academy by Jeremy Martin, Travis Mayberry, Collin Donahue, Lucas Foppe, Lamont Brown, Chadwick Riggins, Erik C. Rye, Dane Brown
Best practice guidelines
- Mobile Privacy Disclosures FTC Staff Report | February 2013 # Building Trust Through Transparency (FTC Staff Report, Feb. 2013)
- Paper, plastic…. Or mobile?: An FTC workshop on mobile payments (FTC Staff Report, Mar. 2013)
- Mobile Security Updates: Understanding the Issues (FTC Feb. 2018)
- Warning Letters to App Developers Using ‘Silverpush’ Code (FTC, March 2016) (Waring app developers to disclose the use of code that allows smartphones to detect audio signals from a TV program, so that advertising on the phone can be customized based on the phone owner’s viewing habits)
- Privacy on the Go: Recommendations for the Mobile Ecosystem (CA AG, Jan 2013)
- Joint Statement on Principles (adopted by CA AG & Mobile Apps Market Companies Amazon, Apple, Google, Hewlett-Packard, Microsoft, and Research In Motion Limited to provide creative and forward-looking solutions that give consumers greater transparency and control without unduly burdening innovative mobile platforms and application developers)
From industry and industry associations:
- Best practices and guidelines for Location-Based services (CTIA) (adopted by the Cellular Telecommunications Industry Association (CTIA) to promote and protect user privacy as Location-Based Services (“LBS”) are developed and deployed that focus on notice, consent, and safeguards).
- Short Form Notice Code Of Conduct To Promote Transparency in Mobile APP Practices (NTIA Jul. 2013) (In 2012, the National Telecommunications and Information Administration (NTIA) convened a multi-stakeholder process on app transparency in order to develop guidance on short form notices with the goal of increasing transparency and the Code of Conduct is the result of that process)
- Best practices for mobile application developers (FPF/CDT Dec. 2011)
Case-law and case studies
- In Re: Google Inc Cookie Placement Consumer Privacy Litig., №13–4300 (3d Cir. 2015) and Vasil v. Kiip Inc. 15-cv-09937, 2018 U.S. Dist. LEXIS 35573 (N.D. III. Mar. 3, 2018) (Regarding the difference between content of communication subject to the US Wiretap and metadata not subject to the Act)
- Reyes v. Lincoln Automotive Financial Services, №16–2104-cv, 2017 WL 2675363 (2d Cir. June 22, 2017) (Plaintiff filed suit against Lincoln, alleging violations of the Telephone Consumer Protection Act (TCPA), 47 U.S.C. 227. The Second Circuit affirmed the district court’s grant of summary judgment for Lincoln, holding that plaintiff did introduce sufficient evidence from which a jury could conclude that he revoked his consent, but that the TCPA does not permit a consumer to revoke its consent to be called when that consent forms part of a bargained‐for exchange. In this case, plaintiff’s consent was not provided gratuitously, it was included as an express provision of a contract to lease an automobile from Lincoln.)
- Edelgsverg v. Vroom, Inc., 16-cv-62734-GAYLES, 2018 U.S. Dist. LEXIS 500420 (S.D. Fla. Mar. 27 2018)
- Case study: Carrier IQ (Device manufacturers and software developers can be held accountable for surreptitious collection of personal data on mobile devices even where the data is held in the device)
(B) Case studies:
- Case study: Uber data breach
- Case study: Delta Airlines (California law requires mobile apps to disclose a separate privacy notice)
- Case study: Goldenshores and Geidl (Apps must provide just-in-time notice and affirmative consent is required before collecting geolocation information)
- Case study: In re Matis (NY law requires disclosure of sharing of aggregated data by apps)
- Case study: In re BLU (FTC expects manufacturers engaging third parties that will have access to user data to (1) perform a due diligence and enter into a contract that spells out practices; (2) monitor performance; and (3) disclose third party data management practices in privacy notice).
- Case study: Uber’s ‘God View’ (NY AG) (Access to data should be restricted to only employees with a legitimate business purpose)
Unique in the Crowd: The privacy bounds of human mobility 2013 Scientific report article by Yves-Alexandre de Montjoye, César A. Hidalgo, Michel Verleysen & Vincent D. Blondel (researchers found 95% percent of cellphone users can be uniquely identified by using only four spatio-temporal points -that is, four points identifying their approximate whereabouts at an approximate time)