Last month, Georgia Congressman Hank Johnson introduced the bipartisan Application Privacy, Protection and Security (APPS) Act of 2013. The bill’s objective is “to provide for greater transparency in and user control over the treatment of data collected by mobile applications and to enhance the security of such data.” If enacted, the APPS Act would require mobile app developers to maintain privacy policies, obtain consent from consumers before collecting data, and securely maintain the data they collect. Here’s Rep. Johnson as he introduced the bill, calling for a common sense approach to meeting the challenges associated with data privacy on mobile devices:
Interestingly, the bill itself was a product of a crowdsourcing effort, of sorts. About a year ago, Rep. Johnson launched AppRights, an online forum for interested parties to build mobile privacy legislation at a grass roots level. According to Rep. Johnson, “the overwhelming majority of participants who helped build the legislation – more than 80 percent – confirmed that Congress should protect consumers’ privacy on mobile devices […] [and] wanted simple controls over privacy on devices, security to prevent data breaches, and notice and information about data collection on the device.” Rep. Johnson even has a Facebook page specific to this proposed legislation; however, at the time of this posting there appears to be only 45 “Likes”, which may be indicative of the actual response to his crowdsourcing initiative.
Putting the efficacy of crowdsourcing for federal law aside, the proposed APPS Act is largely consistent with the Federal Trade Commission’s (FTC) recent Staff Report and initiatives by States, such as the California Attorney General’s Recommendation Memo. If passed, here are the major impacts to mobile app developers and users:
1. Creates two important definitions:
- De-identified Data” is a term used in the Act and defined to mean data that can be used to identify or infer information about a particular person or their mobile device. This definition is important because the Act largely governs mobile apps that collect Personal Data, which by definition does not include De-identified Data.
- “Personal Data” (hereinafter “PD”) is used throughout the Act and the bulk of the Act’s provisions rely heavily on this term. So, wouldn’t it be nice if there were a clear and understandable definition of PD in the Act? Yes, but no such luck. Other than to say that PD does not include De-identified Data, the Act punts to the FTC to define this term by regulation.
2. Notice – Where a mobile app collects PD of a user, the app developer would first have to provide its users with a notice containing the terms by which the developer collects, uses, stores, and shares such PD of the user. While the Act would look to the FTC to prescribe the form and manner of such notices, the content of the notice would have to include:
- The categories of PD that will be collected;
- The categories of purposes for which the PD will be used;
- The categories of third parties with which the PD will be shared; and,
- A data retention policy that governs the length for which the PD will be stored and the terms and conditions applicable to storage, including a description of the rights of the user to withdraw consent and the process by which the user may exercise such rights.
3. Consent – Where a mobile app collects PD of a user, the app developer would first have to obtain the user’s consent to the notice. Interestingly, the statute uses the term “consent” as opposed to “express consent”, which may mean users could be found to impliedly consent to the app developer’s notice.
4. Post-consent Opt-out – This provision would require the mobile app developer to honor a user’s request to prohibit any further collection of PD by the developer. The Act would go an additional step and require the developer, after receiving a user’s opt-out request, to either delete that user’s PD or refrain from using or sharing that user’s PD. Interestingly, the decision to delete the PD or refrain from using/sharing the PD would be vested in the user, and not the developer.
5. Data Security – The app developer would have to implement “reasonable and appropriate measures” to protect against “unauthorized access” to any PD or De-identified Data that the app collects from the user. This provision appears to have very little bite to it, unless the FTC was to expand on it through regulation. Clearly, the APP Act wants no part of the unwelcoming waters that is cybersecurity law.
6. Enforcement – The Act would charge the FTC as the primary regulatory agency for purposes of enforcement and promulgation of regulations under section 18(a)(1)(B) of the FTC Act, which prohibits unfair or deceptive acts or practices. However, the Act provides States’ attorneys general or agencies with the right to bring a federal civil action when they believe the residents of their state are adversely affected by an app developer in violation of the Act.
7. Safe Harbor – App developers would be able to escape liability under the Act if the developer had implemented a “code of conduct for consumer data privacy.” To fit within the safe harbor provision, the code of conduct would have to be (i) developed through the NTIA’s multi-stakeholder process, and (ii) comply with the yet-to-be-promulgated FTC regulations.
That’s it in a nutshell. It should be interesting to see how this bill progresses through Committee, if at all. The good folks at Govtrack are giving it a snowball’s chance in hell of getting passed; but, hey, you never know. So, stay tuned! Better yet, “Like it” on Facebook! Rep. Johnson needs all the support he can get.