1. https://appdevelopermagazine.com/mobile-guidelines
  2. https://appdevelopermagazine.com/what-every-app-developer-needs-to-know-about-the-ntia's-code-of-conduct/
11/5/2013 7:16:54 AM
What Every App Developer Needs to Know About the NTIA's Code of Conduct
App Developer Magazine
What Every App Developer Needs to Know About the NTIAs Code of Conduct

Mobile Guidelines

What Every App Developer Needs to Know About the NTIA's Code of Conduct

Tuesday, November 5, 2013

Adam Grant Adam Grant

Voluntary and Short...Really?

I have come to a recent belief; fewer and fewer things in life seem to be voluntary, even though they say they are and even less are shorter than you think they should be. The National Telecommunications and Information Administration’s (“NTIA”) Short Form Notice Code of Conduct published on July 25, 2013 seems consistent with these beliefs, despite its name. In application, it is neither voluntary, nor short.

What is the Code and Does it Apply to You?

NTIA developed the Code during a yearlong Multi-Stake Holder Process convened by the United States Department of Commerce.  The “stakeholders” included advocates of privacy, civil liberties and consumers, app developers, app publishers and other entities involved in the mobile ecosystem.  
According to the Code, “the purpose of the short form notices is to provide consumers enhanced transparency about the data collection and sharing practices of apps that consumers use.”  The code does not apply to software that a consumer does not interact directly with or is inherent in the function of the device.  Additionally, the code does not apply to apps that are solely provided to or sold to enterprises for use within those businesses.  So, if your company provides a smart phone and loads it with apps used in that business, and those apps obtain the users personally identifiable information, the code of conduct does not apply.

Voluntary Appears to Have a Very Expansive Meaning According to the Code

While voluntary, the Code is quick to caution app developers that this short form notice is not the panacea it appears to be. The Code clearly states that app developers should be aware California’s Online Privacy Protection Act and other privacy laws may also require app developers to post a long form privacy policy.  So, app developer beware, don’t think simply because you comply with this voluntary code you will be immune from an attack on another front. 
Additionally, the Code points out that a long form consumer privacy policy is the generally accepted best practice and that app developers are encouraged to post a long form privacy policy. Yes, you might want to read that last sentence again and think about it. You read it correctly. The Code only applies to short form notices, but tells you that long form notices constitute the “generally accepted best practice.”  So, one wonders, if you voluntarily comply with the code and only use the short form notice, are you falling below the generally accepted best practice, which means all your effort is wasted? 
The last portion of the Code’s preamble is the most troublesome.  The statements appear to completely undermine the entire purpose of the Code, that of “providing consumers enhanced transparency about the date collection and sharing practices of apps” that they use. Even more perplexing is the Code’s cautionary instruction to be sure you can fulfill all operational requirements set forth in the code, “because commitment may create legal responsibilities.”  So, in the end, the “voluntary” nature of the Code appears to be illusory. The Code’s preamble tells mobile app developers in summary; if you choose to follow this “voluntary” code, do it completely, because if you do not you may be legally liable and if you do, you may still be legally liable because the code does not set forth the best practices. It seems to give all new meaning to the phrase, “damned if you do and damned if you don’t.” 

General Design Guidelines for the Short Form Notice

At the very outset, the Code suggests general guidelines to the mobile app developer as to the notice’s design features. The Code encourages the developers to provide consumers with access to the notices prior to download or purchase of the app. The Code even suggests that some app developers may want to offer the notice in multiple languages.
As seems to be the a common theme in the Code, while it states that is allows and encourages flexibility and innovation in the notice, the Code goes on to provide very specific design requirements which the developer “may” implement. For example, (1) the text and font should be distinct so as to easily stand out from the page background; (2) categories of information obtained/used may be described by an icon or symbol that conveys or attracts attention to the information; and (3) the notice should display the required information in a single screen. 
The Code does appear to provide some flexibility in the design of the notice by allowing the app developer to “test a notice with consumers before or during implementation.” The Code suggests that a developer can release an app and “test” for the consumer’s ease and understanding of the privacy notice. However, the test must be “in good faith and show significant and demonstrable improvement” in such understanding.
Practically speaking this sounds completely impractical. How do you measure a consumer’s ease and understanding of the notice? Is such a test even financially feasible for 90% of the mobile apps introduced into the market on daily basis? In the end, a developer can spend all the time, effort and finances necessary to conduct such a test, and still face liability if someone feels the test was not in good faith and did not show significant and demonstrable improvement. Such a guideline hardly engenders any level of comfort that such significant effort will be rewarded.  

What Needs to be in the Short Form Notice?

In short, the notice needs to tell the consumer two main things: (1) What data is being collected from the consumer; and (2) Whether the data collected is being shared, and if so, to whom.  The Notice must describe the types of data being collected. If there is a long form privacy policy, which as previously mentioned, the Code recommends, the notice must tell the consumer how to access the long form notice. The notice must tell the consumer it is sharing the user-specific dates with any third parties identified in the code and the notice must identify the entity providing the app. These general guidelines must be in a consistent manner that is easy for consumers to read and understand. 

Identify the Data Categories the App Collects

The categories of data which the short form notice should identify clearly demonstrates that “short” is equally as flexible a term as “voluntary.”  It seems, as more codes are unrolled on this subject, the longer the list of what is considered personally identifiable information becomes. 
Previously, such data consisted of name, address, email address and IP addresses. The Code expands this definition too far beyond what could conceivably be considered “short.” The app must state if it includes the following; (1) Biometrics (information about your body, including fingerprints, facial recognition and/or voice print; (2) browser history; (3) phone or text log (this means all calls or texts, made or received); (4) contacts (including social networking connections and text addresses); (5) financial information; (6) health, medical or therapy information; (7) location (past or current location of where a user has gone); and finally (8) user files that contact content such as calendar, photos, text or video. 
However, the notice does not need to disclose “incidental collection” of this data if the consumer submits it on their own. Also, if the app allows the consumer to buy things and does not otherwise collects financial information, the notice does not have to tell the consumer the app is collecting the financial information. 
A key issue in determining what to disclose and what not to disclose is determining whether the data is even “collected.”  The code states that the data is collected, “only if transmitted off of the device.” So, if the information is captured by the app, but only used to help with the device’s functionality or customization, then a disclosure is not required. Of course, practically speaking, the likely purpose of collecting the data is to transmit from the device to some third-party.

Where is the Data Going? 

The notice must tell the consumer if the app sends the data to a third-party that falls within certain categories; i.e., the “usual suspects.”  The code identifies the categories as the following: Ad networks, carriers (those that provide mobile connections), consumer data resellers, data analytics (yes, even Google Analytics!), government entities, operating systems and platforms, other apps or social networks. The list is clearly pretty exhaustive and meant to tell the app developer, “if you share it, disclose it!”
The Code does allow some limited exceptions to disclosure when sharing the information with a third-party. No notice is required if the app and the third-party have a contract which limits the uses of the data to provide a service to or on behalf of the app and prohibits the sharing of the data with any other third parties. 

There are a Few Exceptions

An app does not need to disclose identifiable information as long as it is “promptly de-identified” if reasonable steps are taken to make sure the data is re-associated with a person or device. In other words, you don’t have to provide the notice if you take the information that identifies a person, as long as you promptly break it apart in some manner so it can’t identify the actual person. For example, disassociate the first name from the last, separate out the street from the city in the address or separate out the medical condition from anything relating to the actual person.
Additionally, the app does not have to include a disclosure if the data is used for certain operational purposes. Examples of such operational purposes include; maintain, improve or analyze the functioning of the app; perform network communications; authenticate users, cap the frequency of advertising or to protect the security or integrity of the user or app. 

What Should You Do?

The real question for a mobile app developer is: What should you do with this information? Should you run out and redesign your app to make sure it strictly complies with this new code? Should you ignore this Code as it is only voluntary?  

The best way to likely approach this new code is to insure that your app includes a notice. You should compare the recommendations with your notice and determine if there are any deficiencies. Finally, it is probably best to make sure that you have a long form notice conspicuously placed in your app.  Remember, this is only a “voluntary” code (which subjects you to legal liability if you don’t follow it) and suggests a “short” form notice (which includes a rather exhaustive list of categories for data and third-party recipients)…..really!

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

Subscribe to App Developer Magazine

Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.


  • - Exclusive content from leaders in the industry
  • - Q&A articles from industry leaders
  • - Tips and tricks from the most successful developers weekly
  • - Monthly issues, including all 90+ back-issues since 2012
  • - Event discounts and early-bird signups
  • - Gain insight from top achievers in the app store
  • - Learn what tools to use, what SDK's to use, and more

    Subscribe here