IAPP Westin Research Center

Comparison of Mobile Application Guidelines

How to use this guide

The IAPP has worked through a number of the leading privacy guides and standards created for mobile app developers and the parties who host those apps and pulled out the salient points for all of the stakeholders in the mobile app community who are looking to do everything from collect data from children to provide adequate notice and choice previous to data collection. Tell us who you are, and what you're trying to do, and then select a guide/standard (unfamiliar with the different standards? Click here). If there's guidance available, we'll give it to you.

Once you select one choice from all three pull downs, the relevant information will pop up. Hit the "Reset" button to reset the dropdowns.

Guidelines on Data Collection for App Developers from the CA AG Mobile Privacy Guide

  • Avoid or minimize the collection of PII for uses not related to the app’s basic functionality.
  • Avoid or limit the collection of sensitive information.
  • Use an app-specific or other non-persistent identifier, rather than a globally unique identifier.
  • Personally identifiable data are any data linked to a person or persistently linked to a mobile device: data that can identify a person via personal information or a device via a unique identifier.
  • Included are user-entered data, as well as automatically collected data.
  • Sensitive information is personally identifiable data about which users are likely to be concerned, such as precise geo-location; financial and medical information; passwords; stored information such as contacts, photos, and videos and children’s information.

Guidelines on Data Collection for App Developers from the Article 29 Opinion on Apps

  • Only collect those data that are strictly necessary to perform the desired functionality.
  • Personal data may only be processed for fair and lawful purposes, which must be defined before the data processing takes place (“Processing” is defined by the Data Protection Directive as “any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction.” Chapter II describes such lawful purposes).

Guidelines on Data Collection for App Developers from the FPF-CDT Best Practices

  • Stay within the boundaries of your disclosures; do not use or collect data if you have not explained the practice to the user.
  • Understand and respect the context in which you are collecting and using information. If you cannot clearly articulate to users a reason why you are collecting certain data, do not collect it.
  • Do not access or collect user data unless your app requires it. Advertising may well be a legitimate purpose—so long as the collection and transfer of targeting data is transparent, and users are given options about usage of their information for that. However, platform and app stores may have their own rules about the collection and use of user information for certain purposes, including advertising.
  • If your app uses third party analytics or is supported by ads, you are likely collecting or disclosing user information. When using third-party code or software development kits (SDKs)—such as those from advertising networks or analytics—make sure you understand what the code is doing and the practices of those third parties and describe it clearly to your users.
  • If you condition the use of your app on the collection and use personal information, educate your users about the trade-off.
  • Strive to ensure that the user’s personal information you collect, store and transfer is as accurate, complete and up-to-date as is needed for the specific use by the app.

No guidelines available.

Guidelines on Data Collection for App Developers from the GSMA Mobile Privacy Principles

  • Information collected by an application should be reasonable, not excessive.
  • An application must access, collect and use only the minimum information required:
    • To provision, operate or maintain the application
    • To meet identified business purposes that you have told the user about or to meet legal obligations

Guidelines on Data Collection for App Developers from the NTIA Short Form Notice

  • The short form notice shall state which of the following data categories the app collects ("Section II.A" elements):
    • Biometrics (information about a user's body, including fingerprints, facial recognition, signatures and/or voice print)
    • Browser History (a list of websites visited)
    • Phone or Text Log (a list of the calls or texts made or received)
    • Contacts (including list of contacts, social networking connections or their phone numbers, postal, email and text addresses)
    • Financial Information (includes credit, bank and consumer-specific financial information such as transaction data)
    • Health, Medical or Therapy Information (including health claims and other information used to measure health or wellness)
    • Location (precise past or current location of where a user has gone)
    • User Files (files stored on the device that contain your content, such as calendar, photos, text or video)
  • Data is only deemed to be collected if transmitted off of the device.

Guidelines on Data Collection for App Developers from the FTC Mobile Privacy Disclosures

  • Practice data minimization; only collect the data you need for a requested service or transaction.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Limit the amount of data you collect from consumers and third parties alike to accomplish a specific business purpose.

Guidelines on Data Collection for App Developers from the OPC Good Privacy Practices (Canada)

  • Collect and keep only what your app needs to function or carry out legitimate purposes.
  • Do not collect data because you think it may be useful in the future.
  • Where personal information could be used for extra features in an app beyond its core function, if you cannot explain how a piece of information is related to the functioning of your app, then you probably should not be collecting it.
  • Never collect sound or activate the device camera without the specific permission of the user.
  • Design your apps in a way that does not require you to collect any device-unique identifier if it is not essential to the functioning of the app.
  • Avoid collecting information about a user's movements and activities through the use of location and movement sensors unless it relates directly to the app and you have the user's informed consent.
  • Avoid collecting personal information about third parties from a user’s device unless you have consent.

Guidelines on Data Collection for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Only collect personal information that your app needs to function. If you cannot explain how a piece of personal information is related to the functions or activities of your app, then you probably should not be collecting it.
  • Don’t collect personal information just because you believe it may be useful in the future.
  • Don’t collect sensitive information about a user at all, unless the user has expressly consented.
  • Avoid collecting information about a user's movements and activities through the use of integrated location and movement sensors unless it relates directly to the app and you have the user's informed consent.
  • Don’t collect sound or activate the device camera without the specific permission of the user.
  • Don’t collect and store personal information about third parties from a user’s device unless you can obtain the consent of those parties.
  • Don’t collect any persistent identifiers if it is not essential to the functioning of the app.

Guidelines on Data Collection for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Only collect and process the minimum data necessary for the tasks that you want your app to perform.
  • Collecting data just in case you might need it later is bad practice, even if the user has consented to provide that information.
  • If you want to collect usage or bug report data, this may well be possible, but typically must be done in either (or both) of two ways:
    • With informed consent from the user; or
    • Using anonymized data (i.e. data in which there is negligible risk of re-identifying a user from the data).
  • Anonymization data does not remove your responsibility for data minimization. Always collect the minimum amount data necessary before anonymization.
  • Only request access to the sensors, services, or other data that are necessary.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Data Collection for Platform Developers from the FTC Mobile Privacy Disclosures

  • Practice data minimization; only collect the data you need for a requested service or transaction.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Limit the amount of data you collect from consumers and third parties alike to accomplish a specific business purpose.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Data Collection for Ad Networks from the CA AG Mobile Privacy Guide

  • Move away from the use of unchangeable device-specific identifiers and transition to using app-specific and/or temporary device identifiers.

Guidelines on Data Collection for Ad Networks from the Article 29 Opinion on Apps

  • Third parties obtaining access to user data through apps must respect the principles of purpose limitation and data minimization.
  • Only collect and process data that are consistent with the context for which the user provides the data.
  • Unique, often unchangeable, device identifiers should not be used for the purpose of interest based behavioral advertising and/or analytics.

No guidelines available.

Guidelines on Data Collection for Ad Networks from the NAI Mobile Code

  • This Code only governs data collection by member companies related to the following activities:
    • Cross-App Advertising: delivering advertising based in whole or part on Cross-App Data, which is data collected through applications owned or operated by different parties on a particular device for the purpose of delivering advertising based on the preferences or interests inferred from this data. Cross-App Data does not include De-Identified Data, which is data that is not linked or reasonably linkable to an individual or to a particular computer or device.
    • Ad Delivery and Reporting: the collection of information about a device for the purpose of delivering ads or providing advertising related services, including but not limited to: providing a specific advertisement based on a particular time of day; statistical reporting in connection with the activity in an application; analytics and analysis; optimization of location of ad placement; ad performance; reach and frequency metrics (e.g., frequency capping); security and fraud prevention; billing; and logging the number and type of ads served on a particular day to a particular application or device.
  • This Code also considers and defines the collection of the following categories of data:
    • Precise Location Data, which is information that describes the precise real-time geographic location of a device derived through any technology that is capable of determining with reasonable specificity the actual physical location of a person or device, such as GPS level latitude-longitude coordinates or Wi-Fi triangulation. Precise Location Data does not include De-Identified Data.
    • Sensitive Data, which includes Social Security Numbers or other government-issued identifiers; insurance plan numbers; financial account numbers; precise information about past, present, or potential future health or medical conditions or treatments, including genetic, genomic, and family medical history; and Sexual orientation.
    • Personal Directory Data, which is calendar, address book, phone/text log or photo/video file data (including any associated EXIF data) created by a user that is stored on or accessed through a device

No guidelines available.

No guidelines available.

Guidelines on Data Collection for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Limit the amount of data you collect from consumers and third parties alike to accomplish a specific business purpose.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Limit the amount of data you collect from consumers and third parties alike to accomplish a specific business purpose.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Limit the amount of data you collect from consumers and third parties alike to accomplish a specific business purpose.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Data Retention for App Developers from the CA AG Mobile Privacy Guide

  • Do not retain data that can be used to identify a user or device beyond the time period necessary to complete the function for which the data were collected or beyond what was disclosed to the user
  • Adopt procedures for deleting personally identifiable user data that you no longer need.
  • Limit the retention of PII to the period necessary to support the intended function or to meet legal requirements.

Guidelines on Data Retention for App Developers from the Article 29 Opinion on Apps

  • Define a reasonable retention period for data collected with the app and pre-define a period of inactivity after which the account will be treated as expired. Upon expiring, personal data related to the user should be irreversibly anonymized or deleted.
  • After a user has uninstalled an app, an app developer has no legal ground to continue processing personal data related to that user, and must delete all of that user's data unless 1) it has acquired separate consent to a defined extra retention period or 2) there exists a legal obligation to retain some data for specific purposes. (Note: apps, as information society services, cannot invoke the European data retention obligation (Directive 2006/24/EC) to continue to process data about users after they have deleted the app)

Guidelines on Data Retention for App Developers from the FPF-CDT Best Practices

  • Delete data that does not need to be retained for a clear business purpose; do not keep data indefinitely.
  • Consider the retention periods of your vendors as well when assessing any third-party service to which you will be sending user data.
  • Limit the amount of time sensitive data is linked with a user's identifier. Only store sensitive data with a unique identifier for the time frame required to operate your app and deliver a service to your users.
  • Develop a data retention policy that deletes user data after a set period of time, regardless if the data is stored on the device, your servers or in a cloud platform. Remember to clear associated metadata or cross-references to deleted data.
  • De-identification may be sufficient, if there is no reasonable likelihood that the data can be re-identified.
  • Delete user data promptly following the deletion of an account.

No guidelines available.

Guidelines on Data Retention for App Developers from the GSMA Mobile Privacy Principles

  • Set retention and deletion periods: Personal information that is to be retained must be subject to retention and deletion periods that are justified according to clearly identified business needs or legal obligations.
  • Once personal information is no longer required to meet a specific legitimate business purpose or legal requirements/obligations, it should be destroyed or anonymised.
  • Truly anonymous data may be retained indefinitely. To anonymise data, remove any information that could be used to identify a specific individual, ensuring it is not possible to re-identify the individual, and ensure that the data cannot be related to a single, unidentified individual by unique identifiers.

No guidelines available.

Guidelines on Data Retention for App Developers from the FTC Mobile Privacy Disclosures

  • Do not keep data you do not need.
  • Implement reasonable data disposal periods specifically tied to the stated business purpose of the data collection.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

Guidelines on Data Retention for App Developers from the OPC Good Privacy Practices (Canada)

  • You are required by Canadian privacy laws to delete data that you no longer need for the original purpose for which it was collected.
  • Automatically delete users' data when they delete the app.

Guidelines on Data Retention for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Delete or de-identify personal information that you no longer need for a lawful purpose.
  • If your app sends your customers’ personal information overseas, make sure that the personal information is handled in a way that complies with overseas transfer obligations imposed by The Privacy Act.

Guidelines on Data Retention for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Do not store personal data for longer than is necessary for the task at hand.
  • Define retention periods for the personal data you will hold.
  • Allow your users to permanently delete their personal data and any account they may have set up with you. Only make an exception if you are legally obliged to keep the data.
  • If your app stores data for later use, consider encrypting it.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Data Retention for Ad Networks from the NAI Mobile Code

  • Members engaged in Cross-App Advertising and/or Ad Delivery and Reporting shall retain Non-PII and PII collected for these activities only as long as necessary to fulfill a legitimate business need, or as required by law.
    • PII is any information used or intended to be used to identify a particular individual, including name, address, telephone number, email address, financial account number, and government-issued identifier.
    • Non-PII is data that is not PII as defined in the NAI Mobile Application Code, but that is linked or reasonably linkable to a particular computer or device. Non-PII includes, but is not limited to, unique identifiers associated with users’ computer(s) or device(s) and IP addresses, where such identifiers or IP addresses are not linked to PII. Non-PII does not include De-Identified Data).

No guidelines available.

No guidelines available.

Guidelines on Data Retention for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Notice & Transparency for App Developers from the CA AG Mobile Privacy Guide

  • Your privacy policies should be:
    • Conspicuously accessible to users and potential users
    • Clear and understandable using plain language (for example, in a layered notice or “nutrition label” style)
    • In a format that is readable on a mobile device
    • Linked from the app platform page to make it available to users before the app is downloaded or data is collected
    • Linked within the app (e.g., on controls/settings page)
  • Your privacy policy should describe:
    • Types of categories of PII collected by the app
    • Uses and retention periods for each type of or category of personally identifiable data
    • Whether your app or a third party collects payment information for in-app purchases
    • The categories of third parties with whom the app may share personally identifiable data (provide a link to third party privacy policy statements where available)
    • The choices a user has regarding the collection, use and sharing of user information, with instructions on how to exercise those choices
    • A means for users to contact the app developer with questions
    • The effective date of the privacy policy and the process for notifying users of material changes to it
    • The process for a user to review and request corrections to his or her personally identifiable information maintained by the app
  • Privacy icons will be most effective if they are widely used and consumer comprehension is supported by an awareness campaign.
  • Keep your privacy policy communications up-to-date in reflecting your actual data handling practices.
  • Consider hosting the privacy policy in the browser to facilitate updates in case your practices change.
  • Use enhanced measures to draw users’ attention to data practices that may be unexpected or that involve sensitive information.
  • Address all potentially unexpected practices and uses for sensitive data.
  • Explain the consequences of not allowing the collection of the data.

Guidelines on Notice & Transparency for App Developers from the Article 29 Opinion on Apps

  • Every app should have a readable, understandable and easily accessible privacy policy. Apps that do not, or are not intended for the processing of personal data, should clearly state this within the privacy policy.
  • If acting as a data controller, you must inform potential users, at a minimum:
    • Your identity and contact information (every app should have a single point of contact with responsibility for all data processing that takes place via the app)
    • The precise categories of personal data you will collect and process
    • The purposes for such data collection (which should be well-defined and comprehensible for a user with no legal or technical knowledge; elastic purposes such as 'product innovation' are inadequate)
    • Whether data will be disclosed to third parties, in clear and plain language, and if so, for what purposes
    • How user may exercise their rights, in terms of withdrawal of consent and deletion of data
  • If acting as a data controller, it is strongly advised that you also provide information to users on:
    • Proportionality considerations for the types of data collected or accessed on the device
    • Retention periods of the data
    • Security measures applied
  • Clearly differentiate mandatory and optional information.
  • Layered notices (as defined by WP29 in Opinion 10/2004 on More Harmonised Information Provisions) may be beneficial for conveying essential information on a small screen, which includes a link to more extensive explanations. This approach may be combined with the use of meaningful (i.e. clear, self-explaining and unambiguous) icons, images, video and audio, and may make use of contextual real time notifications.
  • Include information in your privacy policy dedicated to European users, explaining the app's compliance with European data protection law and transnational data transfer processes.
  • Ensure that information about the data processing is available to users before app installation and also from within the app, after installation. It is recommended such information is also easily locatable within the app store and on your regular website.
  • Work with OS and device manufacturers and app stores to provide comprehensive notice to app users.
  • Apps must clearly and visibly inform their users about the existence of the access and correction mechanisms available to them in accordance with Article 12 and 14 of the Data Protection Directive. The design and implementation of simple but secure online access tools, where users can get instant access to all the data being processed about them and the necessary explanations thereof is suggested.
  • If a user exercises the right to access, you must provide the user with information about the data that are being processed and on the source of those data. If making automated decisions on that data, users must also be informed about the logic behind those decisions.
  • Upon expiry of any predefined inactivity period but before personal data is deleted or de-identified, alert the user and give the user a chance to retrieve personal data. Ensure that users are informed of such a timescale. The appropriateness of the reminder period depends on the purpose of the app and where the data is stored.

Guidelines on Notice & Transparency for App Developers from the FPF-CDT Best Practices

  • Allow users access to the data you keep about them or their device, when possible.
  • Provide a description of all data practices in your privacy policy; the description should be a comprehensive overview of your data collection and use practices. Do not be ambiguous or try and reserve all rights to the data.
  • Be clear and specific in your privacy policy disclosures by including the type of data the app collects, uses and shares and the purpose for such collection.
  • Clearly identify the types of companies with which you share user data in your privacy policy.
  • Keep your privacy policy up-to-date as your data usage practices change. Inform users when they change.
  • Inform users if their data can be linked back to a particular record or device, even if the user data is not tied to a real name.
  • Provide a hyperlink to your privacy policy from your app store listing or in the sign-up page that appears before users have full access to the app to give users easy access to your privacy policy prior to download.
  • Place your full privacy policy in a prominent location within the app under a "privacy policy" menu or settings header.
  • Prior to updating your app or adopting a new data use practice, confirm that your current policy accurately describes your new practices; if it does not, update the privacy policy to do so.
  • Provide clear and conspicuous notice if your update policy includes new, unexpected transfers of information to third parties.
  • When a new privacy policy is posted, tell users upfront what has changed so they do not have to parse through both the old and new policies to see what is different. Provide a brief statement about the changes with a hyperlink to the old policy for users who want more information.
  • Post updated privacy policies prior to implementing new data use practices to give users notice of the change and time to understand the changes.
  • Your privacy policy should clearly explain that you are sharing behavioral and device identifier information with third parties, identify those parties and provide a link to information about how to opt-out of such tracking or targeting.
  • If you condition the use of your app on the collection and use of personal information, educate your users about the trade-off.
  • If you use location data in an unexpected way or transmit that information to third parties, get permission from the user, regardless if the platform requires express permission for an app to access location information. The CTIA Best Practices and Guidelines are a useful resource for app developers with mobile applications that use location-based services.
  • Users should be informed about the collection and transfer of targeting data for advertising.
  • Consider providing a short-form notice, which is a notice with a limited number of characters that highlights key data practices disclosed in the full privacy policy. The short-form notice should provide a link to full privacy policy.
  • Use additional notice to highlight data use practices that involve the transfer of users' data, such as third-party analytics or third-party advertising.
  • Provide notice about geo-tagging if your app takes photos and/or videos.
  • If your app engages in "frictionless" sharing, which enables users to automatically share information with other platforms with minimal steps or effort, make sure users know that automatic sharing is enabled by providing clear notice and follow platform auto-sharing delay rules.

No guidelines available.

Guidelines on Notice & Transparency for App Developers from the GSMA Mobile Privacy Principles

  • Do not surreptitiously access or collect personal information:
    • Before a user downloads or activates an application, he or she must be presented with information about: what personal information an application will access, collect and use, what personal information will be stored (on the device and remotely), what personal information will be shared, with whom it will be shared, and for what purpose, how long personal information will be kept and any terms and conditions of use affecting a user’s privacy.
    • Prompt the user and make this information easy to discover and understand. Keep it simple and make it easy to exercise choice.
    • Ensure usability and avoid excessive user prompts that will burden the user. Consider the user experience.
  • Identify yourself to users:
    • Before a user downloads or activates an application, he or she must be made aware of the identity of any entities that will collect or use personal information in the scope of the application, including a company or individual name and a country of origin.
    • Users must have easy access (via a link or menu item) to brief contact details of the organization.
  • Provide users with enough information so they can reasonably be expected to know how to access and correct any personal information you might hold about them. Provide a short and genuinely informative privacy statement (for example, on the app landing page) explaining in clear simple terms how people can get a copy of their personal information or correct and update information supplied by them or held by you.
  • Minimize information you collect and limit its use: Information collected by an application should be reasonable, not excessive, and used within the scope of the user’s expectations (when they made a decision to download or activate an application) and other legitimate business purposes as notified to users. Do not use that data for additional non-obvious purposes unless the user has agreed to this.
  • Educate users about the privacy implications and settings of your app or service and how they can manage their privacy. This information should be clearly signposted using simple, non-technical language. Users should also be provided with details of how to protect their privacy in general, by directing them to online resources and sites.
  • No silent/secret updates: Users must be told about a material change to the way an application will collect or use their personal information, before such a change is implemented, so that they can make an informed choice about whether to continue to use the application. This does not prevent remote "over the air" type updates that are necessary to maintain the primary functionality and integrity of an application or service.

Guidelines on Notice & Transparency for App Developers from the NTIA Short Form Notice

  • Short form notices must describe:
    • The types of data collected, listed in Section II.A, which includes biometrics, browser history, contacts, financial information, health, medical or therapy information, location information and user files, regardless if consumers know that it is being collected
    • A means of accessing a long form privacy policy, if any exists
    • The sharing of user-specific data, if any, with third parties listed in Section II.B, which includes ad networks, carriers, consumer data resellers, data analytics providers, government entities, operating systems and platforms, other apps and social networks
    • The identity of the entity providing the app
  • The short form notice need not disclose incidental collection of the data elements in II.A if the data element is actively submitted by a user through an open field and the user is not encouraged to submit that specific data element.
  • In addition to implementing short form notices, participating app developers and publishers shall provide consumers ready access to each participating app’s data usage policy, terms of use or long form privacy policy, as applicable, and if any exists. Participating app developers and publishers should include an explanation of the app's data retention policy, if any exists.

Guidelines on Notice & Transparency for App Developers from the FTC Mobile Privacy Disclosures

  • Have a privacy policy that is easily available through the platform's app store.
  • Disclose key information clearly and conspicuously.
  • Explain what information your app collects from users or their devices and what you do with their data.
  • Provide just-in-time disclosures and obtain affirmative express consent when collecting sensitive information (if platforms have not already given disclosures and obtained consent).
  • Provide prominent notice about the collection of geolocation data, the frequency or extent of the collection, transfer and use of such data.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

Guidelines on Notice & Transparency for App Developers from the OPC Good Privacy Practices (Canada)

  • You are required by Canadian privacy laws to inform app users, in a clear and understandable way, what you are doing with their personal information.
  • Your privacy policy should describe the data collection, usage and flows, along with the privacy and security policies under which the data is being both received and accessed.
  • Layer the information by putting important details up front in your privacy policy but embed links to the details of your privacy rules so that those who want more detail can find it.
    • Make sure that the top layer draws users’ attention particularly to any collection, use or disclosure of information that they would not otherwise reasonably expect.
    • Rather than just using text, you can make a more impactful privacy policy by using graphics, color and sound.
  • Wherever the app is being made available for download, potential users should be told in a clear and accessible way what personal information your app will be collecting and why, where it will be stored (on the device or elsewhere), who it will be shared with and why, how long you will keep it, and any other issues that will affect user privacy.
  • Privacy practices should be highlighted during the purchase process but also upon first use of the app.
  • Once users have downloaded your app, your privacy policy should identify any third parties with whom you share behavioral or device-unique identifiers and link to information about how to modify or delete the data.
  • If you make updates to your app’s privacy policy, inform users in advance and give them reasonable time to provide feedback before you implement changes.
    • Tell users exactly what rules you are changing so they don’t have to compare the new and old policies to understand what’s happening.
    • If you are changing the app privacy policy to include new uses, especially transfers of information to third parties, make the changes easy to find and understand through the update process.
    • Never make silent app updates that will diminish the user’s privacy.
  • Provide specific, targeted notifications to users when they need to make a decision about whether to consent to the collection of their personal information.
  • Tell users in advance what will happen with their information with the eventual use or deployment of the app and also in real time, while it’s actually happening.
    • For example, if your app is about to actively access the user’s location data, you could activate a symbol to raise user awareness of what is happening.
    • For example, if your app takes photos or video, make sure to clearly state whether your app will tag the images with location data and allow the user to opt out of this feature at the time of taking the photo or video.
  • Depending on the purpose of your app, you may wish to give users control over repeated prompting to avoid notice fatigue, but the user should be able to set a period of time after which the consent should be renewed.

Guidelines on Notice & Transparency for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Develop a privacy policy that clearly and simply informs users what your app does with their personal information, why it does it, and what their choices are.
  • If you are sharing behavioral information or device identifiers with third parties, your privacy policy should identify those third parties and link to information about how users can contact those parties.
  • If you want the collection of personal information by your app to be covered by the same privacy policy as your other activities, make sure that the privacy policy adequately covers your app and its functions.
  • Make your app’s privacy policy easy for users and potential users to find.
  • Timing of user notice is critical.
    • Highlight privacy practices during the download/purchase process and also upon first use.
    • Tell users what will happen with their information in real time – this is sometimes known as providing 'in-context notices'.
  • Select the appropriate strategy to convey privacy rules in a way that meaningful on the small screen. Consider the following:
    • Use short form notices, with important points upfront and links to more detailed information.
    • Provide a privacy dashboard that displays a user's privacy settings and provides a convenient means of changing them.
    • Use visual and audio cues such as graphics, colors, and sound to draw user attention to what is happening with their personal information, the reasons for it, and choices available to the user.
  • Your privacy policy and notices need to be accessible to people with disability, such as people who are blind colorblind, and deaf or hard of hearing. If you use tools that are not accessible to people with disability, make sure you offer an alternative way for these users to get the information.
  • If you make updates to your app’s privacy policy, inform users in advance and give them reasonable time to provide feedback before you implement changes.
    • Tell users exactly what rules you are changing so they don’t have to compare the new and old policies to understand what’s happening.
    • Never make silent app updates that will diminish the user's privacy.
    • If you are changing the app privacy policy to include new uses, especially transfers of information to third parties, make the changes easy to find and understand through the update process.

Guidelines on Notice & Transparency for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Users of your app must be properly informed about what will happen to their personal data if they install and use the app.
  • Highlight any actions that would be unexpected or considered onerous by the user. Conversely, do not hide important information or otherwise mislead the user.
  • Provide relevant information in ways that better suits the small screen and touch-based interface of a typical mobile device. Consider the following:
    • Use clear, simple language that is audience appropriate. Explain why you want a user's data, in addition to explaining which data you want.
    • Make relevant privacy information available before the user downloads the app, via an app store or a link to your privacy policy.
    • Where you provide privacy information after an app is downloaded and installed, make sure that this is done before the app processes the relevant personal data.
    • Use a 'layered' approach where important points are summarized, with more detail easily available if the user wants to see it.
    • Use good graphical design, including use of colors and symbols to help your users understand the privacy information better.
    • If your app processes personal data that is of a more sensitive nature or in an unexpected way, consider the use of additional "just-in-time" notifications or other alerts to inform the user what is happening.
  • If your app is supported by advertising, make this clear to your users and give information relating to any analytics you might have included within the app.
  • If your app passes data onto another organization, this will require adequate information to be provided too. This includes advertising networks; in fact, these networks may impose a contractual obligation for you to inform users or gain consent.
  • If your app sends a user's personal data elsewhere for processing, be clear and transparent about where this is and who will be in control of the transferred data.
  • Inform users (and give them a choice) about any changes to the purpose or scope of your data collection. You will normally need to seek users' consent regarding any new data processing, unless you have another clear legal basis for the processing.
  • When requesting access to the sensors, services, or other data that are necessary, if the operating system does not give you the granularity you require then you can provide additional information to users about exactly why a specific permission is needed.
  • Consider publishing any PIA's you've performed to increase transparency and further establish trust.

Guidelines on Notice & Transparency for Platform Developers from the CA AG Mobile Privacy Guide

  • Make it easy for users to find out how to contact you about apps, such as through a link on the app platform page.
  • Give consumers an opportunity to learn about an app’s privacy practices before downloading the app by making the app developer's general privacy policy conspicuously accessible to users and potential users on the app platform.
  • Graphics or icons can help users to easily recognize privacy practices and settings.
  • Encourage consumers to review the app privacy policy before downloading an app.

Guidelines on Notice & Transparency for Platform Developers from the Article 29 Opinion on Apps

  • Ensure that every app provides the essential information on personal data processing. Check the hyperlinks to included pages with privacy information and remove apps with broken links or otherwise inaccessible information about the data processing.
  • Ensure that appropriate information about which data are collected about them and why (including whether the data may be reused for other parties, for which purposes) is available and easily accessible for each app in the app store.
  • Collaborate with app developers to proactively inform users about breaches.
  • Encourage users, with warnings about the security related consequences of not doing so, to update their apps to the latest available versions, and reminders to avoid the reuse of passwords across different services.
  • Allow users to see what data are being processed by which apps. The use of hidden functionalities should not be allowed.
  • Provide users with information about what type security checks and data protection compliance checks are being performed on apps before admitting an app to the app store. It is suggested app stores make use of automatic analysis tools as well as creating information exchange channels between security experts and software professionals and effective procedures and policies to deal with reported issues.
  • Inform the user prior to installation of an app of the type of information requested by app developers.
  • If acting as a data controller, you must inform potential users, at a minimum:
    • Your identity and contact information (every app should have a single point of contact with responsibility for all data processing that takes place via the app)
    • The precise categories of personal data you will collect and process
    • The purposes for such data collection (which should be well-defined and comprehensible for a user with no legal or technical knowledge; elastic purposes such as 'product innovation' are inadequate)
    • Whether data will be disclosed to third parties, in clear and plain language, and if so, for what purposes
    • How user may exercise their rights, in terms of withdrawal of consent and deletion of data
  • If acting as a data controller, it is strongly advised that you also provide information to users on:
    • Proportionality considerations for the types of data collected or accessed on the device
    • Retention periods of the data
    • Security measures applied

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Notice & Transparency for Platform Developers from the FTC Mobile Privacy Disclosures

  • Consider providing consumers with clear disclosures about the extent to which platforms review apps prior to making them available for download in the app stores.
  • Platforms should consider providing just-in-time disclosures for the collection of other content that many consumers would find sensitive in many contexts, such as photos, contacts, calendar entries or the recording of audio or video content.
  • Platforms should ensure these just-in-time disclosures are clear and understandable.
  • Use icons to alert users when apps are collecting certain types of information, such as location.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Notice & Transparency for Ad Networks & Other Third Parties from the CA AG Mobile Privacy Guide

  • Prepare a privacy policy that describes your collection, use, disclosure and retention of personally identifiable user data.
  • Avoid delivering ads outside the context of the app.
  • When delivering out-of-app ads, provide clear attribution to the host application responsible.
  • Provide clear information on the impact of your practices on app software development kits (SDKs).
  • Provide your privacy policy to the app developers who will enable the delivery of targeted ads through your network. Provide a link to your privacy policy for app developers to make available to users before they download and/or activate the app.

Guidelines on Notice & Transparency for Ad Networks & Other Third Parties from the Article 29 Opinion on Apps

  • Provide users with upfront information about the length of time they might expect regular security updates.
  • If acting as a data controller, you must inform potential users, at a minimum:
    • Your identity and contact information (every app should have a single point of contact with responsibility for all data processing that takes place via the app)
    • The precise categories of personal data you will collect and process
    • The purposes for such data collection (which should be well-defined and comprehensible for a user with no legal or technical knowledge; elastic purposes such as 'product innovation' are inadequate)
    • Whether data will be disclosed to third parties, in clear and plain language, and if so, for what purposes
    • How user may exercise their rights, in terms of withdrawal of consent and deletion of data
  • If acting as a data controller, it is strongly advised that you also provide information to users on:
    • Proportionality considerations for the types of data collected or accessed on the device
    • Retention periods of the data
    • Security measures applied

No guidelines available.

Guidelines on Notice & Transparency for Ad Networks & Other Third Parties from the NAI Mobile Code

  • Members should educate users about Cross-App Advertising and the choices available to them with respect to Cross-App Advertising.
  • Enhanced Notice: Members shall provide, or support the provision of, notice of Cross-App Data, Precise Location Data and Personal Directory Data collection and use practices and the choices available to users in or around advertisements that are informed by such data. If notice cannot be provided in or around such advertisements, an arrangement should be made with the application provider serving the advertisement to provide notice within the application:
    • As part of the process of downloading an application to a device, at the time the application is launched for the first time, or when the data is accessed, and
    • In the application’s settings and/or privacy policy
  • Website Notice: Members should provide clear, meaningful and prominent notice on the Member's website that describes its data collection, transfer and use practices for Cross-App Advertising and/or Ad Delivery. The notice should include the following:
    • Cross-App and Ad Delivery and Reporting activities undertaken by the company
    • The types of data collected, including any PII, Precise Location Data, or Personal Location Data, or Personal Directory Data, collected or used for Cross-App Advertising or Ad Delivery and Reporting purposes
    • How the data collected will be used, including transfer, if any, to a third party
    • A general description of the technologies used to maintain state by the company for Cross-App Advertising and Ad Delivery and Reporting
    • That the company is a member of the NAI and adheres to the NAI mobile Application Code
    • The approximate length of time that data used for Cross-App advertising or Ad delivery and Reporting will be retained by the member company
    • An Opt-Out Mechanism
  • App Store Notice: Members shall require the applications, where they collect data for Cross-App Advertising, to clearly and conspicuously post notice, or a link to notice, in any store or on any website where the application may be acquired that contains:
    • A statement of the fact that data may be collected for Cross-App Advertising
    • A description of types of data, including any PII, Precise Location Data, or Personal Directory Data, that are collected for Cross-App Advertising purposes
    • An explanation of how, and for what purpose, the data collected will be used or transferred to third parties
    • A conspicuous link to or description of how to access an Opt-Out Mechanism
  • Members shall provide users with reasonable access to PII, and other information that is associated with PII, retained by the member for Cross-App Advertising purposes.
  • Members that use standard interest segments for Cross-App Advertising that are based on health-related information or interests shall disclose such segments on their websites.
  • As part of members’ overall efforts to promote transparency in the marketplace, members should make reasonable efforts to enforce contractual notice requirements and to otherwise ensure that all apps where they collect data for Cross-App Advertising purposes furnish or require notices comparable to those described above.

No guidelines available.

No guidelines available.

Guidelines on Notice & Transparency for Ad Networks & Other Third Parties from the FTC Mobile Privacy Disclosures

  • Coordinate and communicate with app developers so that the developers can provide truthful disclosures to consumers.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.

Guidelines on Notice & Transparency for Operating Systems from the CA AG Mobile Privacy Guide

  • Provide users with upfront information about the length of time they might expect regular security updates.
  • Ensure that each access to a category of data is reflected in the information of the user before the app's installation (the categories presented must be clear and comprehensible).
  • Ensure the availability of appropriate mechanisms to inform and educate the end user about what the apps can do and what data they are able to access.
  • Actively help develop and facilitate icons alerting users to different data usage by apps.
  • If acting as a data controller, you must inform potential users, at a minimum:
    • Your identity and contact information (every app should have a single point of contact with responsibility for all data processing that takes place via the app)
    • The precise categories of personal data you will collect and process
    • The purposes for such data collection (which should be well-defined and comprehensible for a user with no legal or technical knowledge; elastic purposes such as 'product innovation' are inadequate)
    • Whether data will be disclosed to third parties, in clear and plain language, and if so, for what purposes
    • How user may exercise their rights, in terms of withdrawal of consent and deletion of data
  • If acting as a data controller, it is strongly advised that you also provide information to users on:
    • Proportionality considerations for the types of data collected or accessed on the device
    • Retention periods of the data
    • Security measures applied

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Notice & Transparency for Operating Systems from the FTC Mobile Privacy Disclosures

  • Consider providing consumers with clear disclosures about the extent to which platforms review apps prior to making them available for download in the app stores.
  • Platforms should consider providing just-in-time disclosures for the collection of other content that many consumers would find sensitive in many contexts, such as photos, contacts, calendar entries or the recording of audio or video content.
  • Platforms should ensure these just-in-time disclosures are clear and understandable.
  • Use icons to alert users when apps are collecting certain types of information, such as location.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Notice & Transparency for Mobile Service Providers from the CA AG Mobile Privacy Guide

  • Encourage consumers to review an app's privacy policy before downloading it.
  • Encourage consumers to look for privacy choices and controls in apps after downloading.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Notice & Transparency for Mobile Service Providers from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Reduce the amount of time data is retained.
  • Maintain comprehensive data management procedures throughout the life cycle of your products and services, including sound retention and disposal practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Choice & Consent for App Developers from the CA AG Mobile Privacy Guide

  • Give users control over the collection of any sensitive data or personally identifiable data used for purposes other than the app’s basic functions.
  • Avoid take-it-or-leave-it choices, but when an app developer makes use of the app contingent on collection of the data, that choice should be made clear.

Guidelines on Choice & Consent for App Developers from the Article 29 Opinion on Apps

  • Consent is required to place any information on and read any information from the device (e-Privacy Directive) and consent is necessary to have a legal ground for the processing of different types of personal data (Data Protection Directive). The two types of consent can be merged in practice, provided user is made unambiguously aware of what he is consenting to.
  • Be aware that consent does not legitimize excessive or disproportionate data processing.
  • Acquire freely given, specific and informed consent before the app starts to retrieve or place information on the device. (see W29 Opinion 15/2011 on the definition of consent) Consent is only valid if the user is informed about the key elements of the data processing before the processing of personal data begins (including processing that could take place during installation, for example, for debugging or tracking purposes).
    • "Freely given" means the user must have the choice to accept or refuse the processing of his or her personal data (there must be an option to cancel available).
    • "Informed" means a user must have the necessary information to form an accurate judgment before any personal data is processed.
    • "Specific" means the expression of will must relate to the processing of a particular data item or a limited category of data. Clicking install is not valid consent for processing of personal data; consent cannot be a generally formulated authorization. Asking users to accept a lengthy set of terms and conditions and/or privacy does not constitute specific consent
    • "Granular consent" means that individuals can finely (specifically) control which personal data processing functions offered by the app they want to activate.
  • Gain granular consent for data related to location, contacts, unique device identifiers, identity of the data subject, identity of the phone, credit card and payment data, telephony and SMS, browsing history, e-mail, social network credentials and biometrics.
  • Do not make sudden changes in the key conditions of the processing of personal data without acquiring prior unambiguous consent for this new purpose.
  • Users should always be provided with the possibility to withdraw their consent in a manner which is simple and not burdensome.
  • Consent as a legal ground for processing data is limited to the processing of non-sensitive personal data of a specific user, and can only be invoked to the extent a certain data processing is strictly necessary to perform the desired service or where necessary to pursue the controller’s or a third party’s legitimate interests, except where such interests are overridden by the data subject’s fundamental rights and freedoms.
  • Users must also "specifically" consent to tracking by advertisers. Default settings provided by OSs and Apps must avoid such tracking.
  • Separate consent must be obtained during the uninstall process if an app developer wishes to keep certain data whereby the consumer agrees to a defined extra retention period.

Guidelines on Choice & Consent for App Developers from the FPF-CDT Best Practices

  • Users should be given options about usage of their information for advertising. Where feasible under the circumstances, this may mean allowing users to opt-out of some uses of their data.
  • Provide choices to users at the moment and manner in which the notice would be most relevant to the user, within the OS design framework. This usually means immediately before the collection, use, transmission or accessing of data.
  • Provide users with additional notice or consent mechanisms when your app accesses sensitive information, or when it accesses data/features that may not be obvious to the user.
  • Obtain clear, opt-in user permission before accessing location data.
  • If you are keeping records on your users, set up a mechanism so that users can see what information you are collecting and storing about them. If you are transmitting data to third parties, such as ad networks, you should select partners that also offer reasonable access to user files.
  • You may not need to offer choice when the collection and use of the data is reasonably obvious to users (e.g., some "commonly accepted" data usages such as product fulfillment, first-party analytics, security, and accounting and back-office operations).
  • If mobile operating systems begin to deploy “Do Not Track”-type settings, you should consider how to implement those controls and how your third-party partners respect such controls in order to align with your users’ reasonable expectations.
  • Any identifiers used should not be linked directly to the user’s identity and would either give user the ability to clear the identifier or easily opt-out.
  • If you make material changes to your data policies and practices that will apply to previously collected data, obtain new permissions or opt-in consent before using that data in new ways.

No guidelines available.

Guidelines on Choice & Consent for App Developers from the GSMA Mobile Privacy Principles

  • Users shall be given opportunities to exercise meaningful choice and control over their personal information. Enable the user to reject the installation or activation if they do not wish their personal information to be used as explained to them.
  • Provide users with information about the privacy and security settings and capabilities of applications and services and how to activate and manage these to help them protect and control their own privacy.
    • Where technically possible, provide users with opportunities to determine how they will be prompted and how often they will be prompted to make decisions over access to, and use of, their personal information.
    • Users may be given the choice to "remember" their log-on credentials, billing address, email addresses, or location. It is possible to provide blanket one-time prompting for each data type or granular more context-specific prompts.
  • Where necessary, acquire active consent:
    1. Collection or use of personal information not necessary to the application’s primary purpose:
      • Where access, collection and use of personal information is not necessary to an application’s primary purpose and would be unexpected by the user, then users should be given a choice about whether to allow these secondary and non-obvious uses of their information
      • Where it is necessary to get active consent, users should be made aware of: how long a consent is valid, how they can manage any consent given by them and the consequences of withholding or withdrawing their consent
      • Users must be able to withdraw consent by simple and efficient means, without any undue delay or undue cost
    2. Sharing personal information with third parties: If third parties will collect or have access to user information for their own purposes, the user must be made aware at the earliest opportunity that their data will be shared, indicating:
      • With whom it will be shared and for what purposes, and
      • Providing links to those third parties’ and their privacy notices.
      • Users must be allowed to choose whether to allow this collection, access and use by third parties.
    3. Storing personal information after immediate use of the application: If user data will be retained after the immediate use of an application, users must be given information about:
      • The periods for which information may be retained and why
      • How the user can exercise specific rights over their information
    4. Other situations may also require active consent: Social networks and social media, Mobile advertising, Location, Children and adolescents
  • Consent to material changes in the way an application will collect or use personal information can be obtained (before the change is implemented) in two ways:
    • For changes that are essential to an application’s continued operation: Notice that a change will occur and a chance to disable the application.
    • For changes that the user may choose to adopt: A prompt with choices about whether to allow the change or continue with the previous functionality.

No guidelines available.

Guidelines on Choice & Consent for App Developers from the GSMA Mobile Privacy Principles

  • Collect sensitive data only with affirmative consent.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • For practices requiring choice, offer the choice at a time and in a context in which the consumer is making a decision about his or her data. Obtain affirmative express consent before (1) using consumer data in a materially different manner than claimed when the data was collected; or (2) collecting sensitive data for certain purposes.
  • Affirmative express consent is appropriate when you use sensitive data for any marketing, whether first- or third-party. A consumer choice mechanism should be provided at the time of data collection.
  • You do not need to provide choice before collecting and using consumer data for practices that are consistent with the context of the transaction or your relationship with the consumer, or are required or specifically authorized by law. Practices such as fulfilment, fraud prevention, internal operations, legal compliance and public purpose, and most first-party marketing (including cross-channel marketing) would not typically require consumer choice.
  • Where you have a first-party relationship with a consumer on your own website and engage in third-party tracking of the consumer across other websites you should provide meaningful choice to the consumer.
  • Your affiliates are third parties and a consumer choice mechanism is necessary unless the affiliate relationship is clear to consumers (for example, through common branding).

Guidelines on Choice & Consent for App Developers from the OPC Good Privacy Practices (Canada)

  • You must strive to obtain meaningful consent despite the small screen challenge.
  • Ensure that users have a way to modify their information, opt out of any tracking and delete their profile entirely if they wish.
  • Provide a means for users to opt out of behavioral tracking.
  • Give users the ability to delete all of the data collected about them.
  • Obtain informed consent to collect information about a user’s movements and activities through the use of location and movement sensors.
  • Obtain specific permission of the user to collect sound or activate the device camera.

Guidelines on Choice & Consent for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Strive to obtain meaningful consent despite the small screen challenge. Timing of user consent is critical.
  • Obtain consent at the point of download.
  • Provide a way for users to modify their information, opt out of any tracking and delete their profile entirely if they wish.
  • Ideally, users should be able to opt out of sharing their personal information with third parties.
  • Allow users to opt in to the collection or use of their personal information, or if that is not practicable, clearly explain they cannot opt out so they can make an informed decision about whether to install your app.
  • Wherever possible, seek express consent from users to any changes that could impact on their privacy.
  • Users should have the ability to request the deletion of all of the personal information about them that your app has collected.
  • Allow users to change their minds about giving you access to their personal information. If this means that they have to uninstall the app, explain this clearly and simply.

Guidelines on Choice & Consent for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Give users a granular choice where possible. This allows the user to make meaningful decisions rather than giving the user a single 'all or nothing' choice.
  • Allow your users to easily review and change their decisions once the app is installed and in use.
  • Provide users with a single and obvious place to go to configure the various settings within the app and give them privacy-friendly defaults.
  • It should be as quick to disable a setting as it was to enable it.
  • Allow your users to permanently delete their personal data and any account they may have set up with you. Only make an exception if you are legally obliged to keep the data.

No guidelines available.

Guidelines on Choice & Consent for Platform Developers from the Article 29 Opinion on Apps

  • Consent is only valid if the user is informed about the key elements of the data processing before the processing of personal data begins. If such information is provided only after personal data has started to process consent is not valid.
  • Comply with the consent requirement determined in Article 5(3) of the ePrivacy Directive when you read or write data on mobile devices, in cooperation with the app developers and/or third parties, to provide users with information on the purposes of data processing.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Choice & Consent for Platform Developers from the FTC Mobile Privacy Disclosures

  • Before allowing apps to access sensitive content through APIs, such as geolocation information, platforms should provide a just-in-time disclosure of that fact and obtain affirmative express consent from consumers.
  • Platforms should consider obtaining affirmative express consent for the collection of other content that consumers would find sensitive in many contexts, such as photos, contacts, calendar entries or the recording of audio or video content.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • For practices requiring choice, offer the choice at a time and in a context in which the consumer is making a decision about his or her data. Obtain affirmative express consent before (1) using consumer data in a materially different manner than claimed when the data was collected; or (2) collecting sensitive data for certain purposes.
  • Affirmative express consent is appropriate when you use sensitive data for any marketing, whether first- or third-party. A consumer choice mechanism should be provided at the time of data collection.
  • You do not need to provide choice before collecting and using consumer data for practices that are consistent with the context of the transaction or your relationship with the consumer, or are required or specifically authorized by law. Practices such as fulfilment, fraud prevention, internal operations, legal compliance and public purpose, and most first-party marketing (including cross-channel marketing) would not typically require consumer choice.
  • Where you have a first-party relationship with a consumer on your own website and engage in third-party tracking of the consumer across other websites you should provide meaningful choice to the consumer.
  • Your affiliates are third parties and a consumer choice mechanism is necessary unless the affiliate relationship is clear to consumers (for example, through common branding).

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Choice & Consent for Ad Networks from the CA AG Mobile Privacy Guide

  • Use enhanced measures and obtain prior consent from users before accessing personal information such as phone number, e-mail address or name.
  • Use enhanced measures and obtain prior consent from users before delivering out-of-app ads.

Guidelines on Choice & Consent for Ad Networks from the Article 29 Opinion on Apps

  • Comply with the consent requirement determined in Article 5(3) of the ePrivacy Directive when you read or write data on mobile devices, in cooperation with the app developers and/or app stores, to provide users with information on the purposes of data processing.
  • Consent is only valid if the user is informed about the key elements of the data processing before the processing of personal data begins. If such information is provided only after personal data has started to process consent is not valid.

No guidelines available.

Guidelines on Choice & Consent for Ad Networks from the NAI Mobile Code

  • The level of choice that members must provide is commensurate with the sensitivity and intended use of the data. Specifically:
    • Use of Non-PII for Cross-App Advertising shall require access to an Opt-Out Mechanism (an easy-to-use mechanism by which users may exercise choice to disallow Cross-App Advertising with respect to a particular browser or device)
    • Use of PII to be merged with Non-PII on a going-forward basis for Cross-App Advertising purposes (prospective merger) shall require access to an Opt-Out Mechanism accompanied by robust notice of such choice
    • Use of PII to be merged with previously collected Non-PII for Cross-App Advertising purposes (retrospective merger) shall require a user’s Opt-In Consent (where a user takes some affirmative action that manifests the intent to opt in)
    • Use of Precise Location Data for Cross-App Advertising shall require a user’s Opt-In Consent
    • Use of Sensitive Data for Cross-App Advertising shall require a user’s Opt-In Consent
  • Member companies should not intentionally access a device without user authorization and obtain Personal Directory Data for Cross-App Advertising.
  • Members who make a material change to their Cross-App Data collection and use policies and practices shall obtain Opt-In Consent before applying such change to data collected prior to the change. In the absence of Opt-In Consent, data collected prior to the material change in policy shall continue to be governed by the policy in effect at the time the information was collected.

No guidelines available.

No guidelines available.

Guidelines on Choice & Consent for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • For practices requiring choice, offer the choice at a time and in a context in which the consumer is making a decision about his or her data. Obtain affirmative express consent before (1) using consumer data in a materially different manner than claimed when the data was collected; or (2) collecting sensitive data for certain purposes.
  • Affirmative express consent is appropriate when you use sensitive data for any marketing, whether first- or third-party. A consumer choice mechanism should be provided at the time of data collection.
  • You do not need to provide choice before collecting and using consumer data for practices that are consistent with the context of the transaction or your relationship with the consumer, or are required or specifically authorized by law. Practices such as fulfilment, fraud prevention, internal operations, legal compliance and public purpose, and most first-party marketing (including cross-channel marketing) would not typically require consumer choice.
  • Where you have a first-party relationship with a consumer on your own website and engage in third-party tracking of the consumer across other websites you should provide meaningful choice to the consumer.
  • Your affiliates are third parties and a consumer choice mechanism is necessary unless the affiliate relationship is clear to consumers (for example, through common branding).

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Choice & Consent for Operating Systems are only available in the Article 29 Opinion on Apps and FTC Mobile Privacy Disclosures.

Guidelines on Choice & Consent for Operating Systems from the Article 29 Opinion on Apps

  • Update APIs, store rules and user interfaces to offer users sufficient control to exercise valid consent over the data processed by apps.
  • Ensure that methods and functions allowing access to personal data include features aiming to implement granular consent requests.
  • Pre-installed apps, which rely on consent as a legal basis, must ensure consent is valid. A separate consent mechanism should be considered to give the data controller an opportunity to fully inform the consumer, when the app is first run. If special categories of data are used consent must be explicit as defined in Article 8 of the Data Protection Directive.
  • Consent is only valid if the user is informed about the key elements of the data processing before the processing of personal data begins. If such information is provided only after personal data has started to process consent is not valid.
Guidelines on Choice & Consent for Operating Systems are only available in the Article 29 Opinion on Apps and FTC Mobile Privacy Disclosures.
Guidelines on Choice & Consent for Operating Systems are only available in the Article 29 Opinion on Apps and FTC Mobile Privacy Disclosures.
Guidelines on Choice & Consent for Operating Systems are only available in the Article 29 Opinion on Apps and FTC Mobile Privacy Disclosures.
Guidelines on Choice & Consent for Operating Systems are only available in the Article 29 Opinion on Apps and FTC Mobile Privacy Disclosures.

Guidelines on Choice & Consent for Operating Systems from the FTC Mobile Privacy Disclosures

  • Before allowing apps to access sensitive content through APIs, such as geolocation information, platforms should provide a just-in-time disclosure of that fact and obtain affirmative express consent from consumers.
  • Platforms should consider obtaining affirmative express consent for the collection of other content that consumers would find sensitive in many contexts, such as photos, contacts, calendar entries or the recording of audio or video content.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • For practices requiring choice, offer the choice at a time and in a context in which the consumer is making a decision about his or her data. Obtain affirmative express consent before (1) using consumer data in a materially different manner than claimed when the data was collected; or (2) collecting sensitive data for certain purposes.
  • Affirmative express consent is appropriate when you use sensitive data for any marketing, whether first- or third-party. A consumer choice mechanism should be provided at the time of data collection.
  • You do not need to provide choice before collecting and using consumer data for practices that are consistent with the context of the transaction or your relationship with the consumer, or are required or specifically authorized by law. Practices such as fulfilment, fraud prevention, internal operations, legal compliance and public purpose, and most first-party marketing (including cross-channel marketing) would not typically require consumer choice.
  • Where you have a first-party relationship with a consumer on your own website and engage in third-party tracking of the consumer across other websites you should provide meaningful choice to the consumer.
  • Your affiliates are third parties and a consumer choice mechanism is necessary unless the affiliate relationship is clear to consumers (for example, through common branding).

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.
No guidelines available.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • For practices requiring choice, offer the choice at a time and in a context in which the consumer is making a decision about his or her data. Obtain affirmative express consent before (1) using consumer data in a materially different manner than claimed when the data was collected; or (2) collecting sensitive data for certain purposes.
  • Affirmative express consent is appropriate when you use sensitive data for any marketing, whether first- or third-party. A consumer choice mechanism should be provided at the time of data collection.
  • You do not need to provide choice before collecting and using consumer data for practices that are consistent with the context of the transaction or your relationship with the consumer, or are required or specifically authorized by law. Practices such as fulfilment, fraud prevention, internal operations, legal compliance and public purpose, and most first-party marketing (including cross-channel marketing) would not typically require consumer choice.
  • Where you have a first-party relationship with a consumer on your own website and engage in third-party tracking of the consumer across other websites you should provide meaningful choice to the consumer.
  • Your affiliates are third parties and a consumer choice mechanism is necessary unless the affiliate relationship is clear to consumers (for example, through common branding).

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Accountability & Oversight for App Developers from the CA AG Mobile Privacy Guide

  • You are accountable for complying with applicable laws and with any privacy notices you provide.
  • Appoint someone in the organization to be responsible for reviewing your general privacy policy whenever the app is updated or your business practices change.
  • The same person should also maintain an archive of previous versions of the policy, confirm your rules for limiting internal access to PII, act as the point of contact for privacy questions and comments and stay informed of new privacy laws.
  • Ensure that all who work in your organization receive training in privacy obligations and in your own policies and practices. Such training should be provided at least annually and to new employees as they are hired
  • Consider using a data checklist, which can be used in making decisions about privacy practices, in designing an app, and in generating privacy notices and statements. Also consider the data collection and use practices of any third-party software (such as libraries or SKDs) used in your app, by both testing and reading about those practices.
  • Consider privacy when making updates in technology and business practices.

Guidelines on Accountability & Oversight for App Developers from the Article 29 Opinion on Apps

  • Study the relevant guidelines with regard to specific security risks and measures.
  • Provide a single point of contact for the users of the app.
  • Adopt "purpose limitation" and "data minimization" principles.
  • Ensure that the way data is processed is not changed from one version of an app to another (function creep) without giving the end users appropriate information notices and opportunities to withdraw from either the processing or the entire service.
  • Adopt the principles of privacy by design and default in order to comply with security obligations.
  • Subject to user request, the app data controller must enable rectification, erasure or blocking of personal data if they are incomplete, inaccurate or processed unlawfully.
  • Grant app users to access their rights of access, rectification, erasure and their right to object to data processing only after a user's identity is established (in many cases, authentication could suffice instead of (full) identification).

Guidelines on Accountability & Oversight for App Developers from the FPF-CDT Best Practices

  • There should be at least one person responsible for making sure that privacy protections are integrated into the app. This person should ensure the following:
    • Review the privacy policy before each app release to ensure that it remains accurate and complete
    • Maintain an archive of your privacy policy, and ensure that change notices are appropriately posted for users
    • Confirm your company's rules for internal access to personal information, and ensure access is limited to team members who need to see it
    • Answer all privacy-related emails and communication
    • Keep abreast of new privacy developments by following the FTC and other industry organizations
  • Adopt the principles of privacy by design and incorporate such principles at all stages of development.
  • Provide users with an opportunity to contact you with questions, concerns or complaints. Be sure to review and respond to user feedback.
  • Make sure you comply with applicable laws and regulations. Federal laws and regulations do extend to user credit reports, electronic communications, education records, bank records, video rental records, health information, children’s information, and user financial information. If your app handles information in these areas, or implicates foreign users' data, you should consult with an attorney or privacy expert.
  • Only work with third parties that do not engage in behavioral targeting or that offer users the opportunity to opt-out of such targeting.

No guidelines available.

Guidelines on Accountability & Oversight for App Developers from the GSMA Mobile Privacy Principles

  • Assign responsibility for ensuring end-user privacy is considered and delivered throughout the product lifecycle and through applicable business processes: Each entity that collects personal information about users must ensure a company representative(s) is assigned the responsibility for ensuring end-user privacy is built into applications and services and business processes.
  • Users must be able to report problems with your applications or the content they contain, or with the application platforms themselves. Provide a short statement and link on the app landing page, and or your corporate website. Clearly signpost this. If you collect email contact addresses (with permission) you could also email that information to users.
  • Users must be provided with information explaining how they can report applications that they suspect or that are found to breach the privacy and security of their personal information. Procedures should be established and maintained to deal with such reports and address any specific threats and risks.

Guidelines on Accountability & Oversight for App Developers from the NTIA Short Form Notice

  • After an app developer or publisher has actual knowledge of unauthorized collection or sharing it must promptly either take reasonable steps to prevent collection or sharing that is inconsistent with its short form notice or modify its short form notice to make an appropriate disclosure.
  • App developers should be aware that there are other Fair Information Practices (FIPs) beyond transparency; app developers are encouraged to adhere to the full set of FIPs.
  • App developers should be aware that California’s Online Privacy Protection Act and other privacy laws may also require app developers to post a long form privacy policy. Because long form consumer privacy policies constitute a generally accepted best practice, app developers are encouraged to post a long form privacy policy.

Guidelines on Accountability & Oversight for App Developers from the FTC Mobile Privacy Disclosures

  • Improve communication with third-party service providers to better understand the data they collect and use in order to make truthful disclosures.
  • Participate in trade groups, industry organizations and self-regulatory programs.
  • Adopt principles of privacy by design by limiting the information you collect, securely storing information you hold on to and safely disposing of information you no longer need.
  • Honor your privacy promises, including any statements made in a privacy policy or elsewhere.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you obtain marketing data for enhancement, you should take steps to encourage your third-party data broker sources to increase their own transparency, including by participating in a centralized data broker website where consumers could learn more information about data brokers and exercise choices. You may also consider contractually requiring your data broker sources to take these steps.
  • All stakeholders should expand their efforts to educate consumers about commercial data privacy practices.

Guidelines on Accountability & Oversight for App Developers from the OPC Good Privacy Practices (Canada)

  • Avoid associating data across apps unless it is obvious to the user and necessary to do so. If you must make links, ensure that sensitive data is not linked to a user’s identifier for longer than it needs to be.
  • Build a privacy management program and identify someone within your company to be responsible for privacy protection, even if you only have a small team.
  • Have a monitoring program in place to make sure that the app in fact handles personal information in the way described in your privacy policy.
  • Develop your privacy policy by mapping out where the information is going and identify potential privacy risks. These descriptions need to be mapped and evaluated to ensure that they comply with your company’s privacy policy.
  • Make sure you have controls in place such as contracts to ensure that third parties process personal information in accordance with their obligations under privacy law, and make sure the controls are aligned with user expectations.
    • Ensure that all of your business arrangements and contracts are compliant with privacy laws because you are ultimately accountable.
    • Be cautious when using third party code or software development kits—such as those from advertising networks or analytics providers—which could contain code you aren’t aware of, such as aggressive adware or malware.
  • For additional guidance on accountability, consult "Getting Accountability Right with a Privacy Management Program."

Guidelines on Accountability & Oversight for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Avoid associating personal information across apps, or between your app and a user's social media account, unless it is obvious to the user and necessary to do so.
    • If you must make links, ensure that personal information is not linked to a user's identifier for longer than it needs to be.
  • Have a monitoring process in place to make sure that you and your app handle personal information as described in your privacy policy.
  • Adopt a 'privacy by design' approach by integrating good privacy protections into your day-to-day business practice.
  • Ensure that your business arrangements and contracts protect users' privacy and comply with your obligations under the Privacy Act.
  • Put in place a privacy management program for your business to help you manage risks up front.
  • Identify someone within your business to be responsible for privacy protection and dealing with privacy complaints, even if you have a small team.
  • Use a Privacy Impact Assessment (PIA) to map where information is going, identify potential privacy risks, and assist with privacy planning (including 'privacy by design'). More information about PIAs can be found here.
  • Put in place controls (such as contracts) to ensure that third parties accessing personal information through your app respect their privacy obligations.
  • If your app experiences a data breach, you may need to inform your users – and the OAIC.

Guidelines on Accountability & Oversight for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Consider the types of data your app might access, collect or transmit and think about how these could affect a user of the app at the design stage.
  • If you develop for multiple platforms, take account of any differences between mobile platforms and their respective app stores.
  • Test your app to ensure that the app's behavior is as expected and still matches with the plan you created in the design phase.
    • Where your app gives users a choice on whether to permit or deny access to personal data, make sure you test the user experience in both scenarios
    • Check that a decision to deny access does in fact have the desired effect and that your app does not go on to use the personal data anyway
  • Once the app is made available to users, continue to ensure that you are living up to your promises.
  • Know where and how data will flow when your app is used, and who is in control of the data throughout the lifecycle of the app.
  • You are responsible for understanding the behavior of any software components that you incorporate into your app, including code used for the purpose of advertising.
  • If you are a data controller, choose a service provider carefully; the DPA requires that you have a written contract which includes security requirements.
  • If you are developing an app on behalf of a client, you may well not be a data controller, but your client will need to comply, so consider privacy and security as part of your development process.
  • If you are acting as a data controller, it is fundamental that you identify yourself and give your app users a simple means to contact you.
    • The major app stores allow developers to include an email address and website address in the app catalogue
    • Monitor this contact method and respond effectively to any queries, including bug and feature requests
  • As a data controller, you will have a legal responsibility to respond to a user if they make a written request for a copy of their personal data that you hold. This is called a 'subject access request' and includes requests made by email or through social media.

Guidelines on Accountability & Oversight for Platform Developers from the CA AG Mobile Privacy Guide

  • Implement processes to respond to consumer reports or questions.
  • Educate app developers about their obligations to respect consumer privacy and disclose to consumers what PII they collect, how they use the information, with whom they share it and other privacy practices.
  • Help to educate consumers on mobile privacy. Provide educational information on or linked from the app platform.

Guidelines on Accountability & Oversight for Platform Developers from the Article 29 Opinion on Apps

  • Adopt the principles of privacy by design and default in order to comply with security obligations.
  • Warn apps about the specificity of European privacy law before submitting the application in Europe.
  • Remain aware of future and personal data breaches notification obligations.
  • Make the necessary disclosures in accordance with Article 10 of the Data Protection Directive. which gives data subjects are right to know the identity of the data controller who is processing their personal data.
  • Subject all apps to a public reputation mechanism.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Accountability & Oversight for Platform Developers from the FTC Mobile Privacy Disclosures

  • Add provisions to contracts with app developers requiring apps to provide disclosures and obtain affirmative consent before collecting sensitive information and reasonably enforce these provisions.
  • Reasonably enforce contractual requirements that apps have privacy policies.
  • Educate app developers on privacy.
  • Conduct compliance checks after apps have been placed in the app stores.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you obtain marketing data for enhancement, you should take steps to encourage your third-party data broker sources to increase their own transparency, including by participating in a centralized data broker website where consumers could learn more information about data brokers and exercise choices. You may also consider contractually requiring your data broker sources to take these steps.
  • All stakeholders should expand their efforts to educate consumers about commercial data privacy practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available

Guidelines on Accountability & Oversight for Ad Networks from the Article 29 Opinion on Apps

  • Adopt the principles of privacy by design and default in order to comply with security obligations.
  • Do not circumvent any mechanism designed to avoid tracking.
  • Specifically avoid delivering ads outside the context of the app.
  • Refrain from the use of unique device or subscriber identifiers for the purpose of tracking.
  • Refrain from processing children's data for behavioral advertising purposes.
  • Inform users as soon as possible if a security issue requires an update to fix.
  • Make the necessary disclosures in accordance with Article 10 of the Data Protection Directive. which gives data subjects are right to know the identity of the data controller who is processing their personal data.

No guidelines available.

Guidelines on Accountability & Oversight for Ad Networks from the NAI Mobile Code

  • Each member shall provide a mechanism by which users can submit questions or concerns about the company’s collection and use of data for Interest-Based Advertising, and shall make reasonable efforts to timely respond to and resolve questions and concerns that implicate the company’s compliance with the NAI Code and NAI policies
  • When a user has opted out of Cross-App Advertising, member companies must honor the user’s choice as to the particular device. Companies may continue to collect data for other purposes, including Ad Delivery and Reporting.
  • Members shall not use, or allow use of, data collected for Cross-App Advertising or Ad Delivery and Reporting for any of the following purposes:
    • Employment Eligibility
    • Credit Eligibility
    • Health Care Eligibility
    • Insurance Eligibility and Underwriting and Pricing
  • Members should make reasonable efforts to enforce contractual notice requirements and to otherwise ensure that all apps where they collect data for Cross-App Advertising purposes furnish or require notices comparable to those described in this Code.
  • Members shall contractually require that any unaffiliated parties to which they provide PII for Cross-App Advertising or Ad Delivery and Reporting services adhere to applicable provisions of this Code.
  • Members shall contractually require that all parties to whom they provide Non-PII collected across applications owned or operated by different entities not attempt to merge such Non-PII with PII held by the receiving party or to re-identify the individual without obtaining the individual’s Opt-In Consent. This requirement does not apply where the Non-PII is proprietary data of the receiving party.
  • Members shall conduct appropriate due diligence to ensure that they obtain data used for Cross-App Advertising from reliable sources that provide users with appropriate levels of notice and choice.
  • To help ensure compliance with the NAI Code of Conduct, each member company should designate at least one individual with responsibility for managing the company’s compliance with the NAI Code and providing training to relevant staff within the company.

No guidelines available.

No guidelines available.

Guidelines on Accountability & Oversight for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you obtain marketing data for enhancement, you should take steps to encourage your third-party data broker sources to increase their own transparency, including by participating in a centralized data broker website where consumers could learn more information about data brokers and exercise choices. You may also consider contractually requiring your data broker sources to take these steps.
  • All stakeholders should expand their efforts to educate consumers about commercial data privacy practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Accountability & Oversight for Operating Systems from the CA AG Mobile Privacy Guide

  • Work with device manufacturers and mobile carriers on setting cross-platform standards for privacy controls, means of enabling the delivery of special privacy notices and privacy icons.

Guidelines on Accountability & Oversight for Operating Systems from the Article 29 Opinion on Apps

  • Adopt the principles of privacy by design to prevent secret monitoring of users.
  • Ensure security of processing.
  • Systematically offer and facilitate regular security updates.
  • Develop clear audit trails into the devices so app users can see what app is accessing what information.
  • Offer granular access to data, sensors and services, in order to ensure that the app developer can only access those data that are necessary for the app.
  • Inform users as soon as possible if a security issue requires an update to fix.
  • Make the necessary disclosures in accordance with Article 10 of the Data Protection Directive, which gives data subjects a right to know the identity of the data controller who is processing their personal data.
  • Offer an API with precise controls to differentiate each type of underlying device data and ensure that app developers can request access to only those data that are strictly necessary for the (lawful) functionality of their app.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Accountability & Oversight for Operating Systems from the FTC Mobile Privacy Disclosures

  • Add provisions to contracts with app developers requiring apps to provide disclosures and obtain affirmative consent before collecting sensitive information and reasonably enforce these provisions.
  • Reasonably enforce contractual requirements that apps have privacy policies.
  • Educate app developers on privacy.
  • Conduct compliance checks after apps have been placed in the app stores.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you obtain marketing data for enhancement, you should take steps to encourage your third-party data broker sources to increase their own transparency, including by participating in a centralized data broker website where consumers could learn more information about data brokers and exercise choices. You may also consider contractually requiring your data broker sources to take these steps.
  • All stakeholders should expand their efforts to educate consumers about commercial data privacy practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Accountability & Oversight for Mobile Service Providers from the CA AG Mobile Privacy Guide

  • Work with operating system developers and device manufacturers on setting cross-platform means of enabling the delivery of special privacy notices and privacy icons.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Accountability & Oversight for Mobile Service Providers from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you obtain marketing data for enhancement, you should take steps to encourage your third-party data broker sources to increase their own transparency, including by participating in a centralized data broker website where consumers could learn more information about data brokers and exercise choices. You may also consider contractually requiring your data broker sources to take these steps.
  • All stakeholders should expand their efforts to educate consumers about commercial data privacy practices.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Privacy Controls for App Developers from the CA AG Mobile Privacy Guide

  • Default settings should be privacy protective.
  • Offer a convenient way to make choices and to change them when desired.
  • Provide privacy controls in a settings menu or “dashboard” that is readily accessible within the app.
  • Include a mechanism to revoke prior choices.
  • Develop mechanisms to give users access to the PII that the app collects and retains about them.
  • Give users control over the collection of any PII used for purposes other than the app’s basic functions.
  • Enhanced notice and control might be provided through “special notices,” delivered in context and just-in-time or short-form privacy notices.

Guidelines on Privacy Controls for App Developers from the Article 29 Opinion on Apps

  • Develop and implement online access tools that enable users to customize retention periods without collecting additional data.
  • Offer users technical means to verify statements about declared purposes, by allowing them access to information about the amounts of outgoing traffic per app, in relation to user-initiated traffic.
  • Allow users to withdraw their consent and uninstall the app and thereby remove all personal data, including any data stored on the servers of the data controller(s). The withdrawal mechanism should be simple and effective.
  • Develop information and user controls to ensure that the principles of data minimization and purpose limitation are respected.
  • Under Articles 12 and 14 of the Data Protection Directive, app developers must enable app users to exercise their rights of access, rectification, erasure and their right to object to data processing.

Guidelines on Privacy Controls for App Developers from the FPF-CDT Best Practices

  • Provide users with meaningful controls like an opt-out mechanism when data is used in a non-obvious way.
  • If you keep records on your users, set up a mechanism so that users can see what information you are collecting and storing about them.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for App Developers from the NTIA Short Form Notice

  • Employ a mechanism that allows consumers access to expanded definitions of each data element.
  • The short form notice must implement the following design elements:
    • All data categories as described in II.A, and all entities as described in II.B shall be listed in text, which may be accompanied by or include an icon or symbol that conveys or attracts attention to the information.
    • A short form notice may display more specific descriptions of the data elements collected or of the entities with which information is shared. That information may be conveyed in larger or smaller font than the font of the data element or entity categories.
    • A short form notice may list the categories of data shared and data collected that do not apply in smaller text, or otherwise distinguish the non-applicable categories from applicable categories.
    • If an app neither collects categories of data from II.A, nor shares with any entities listed in II.B, nor collects categories or shares with any entities (other than the excepted data collection and disclosures), the short form notice may clearly set forth in its short form notice that it "does not collect," "does not share" or "does not collect or share" in lieu of listing the categories or entities.
    • Where practicable, the short form notice should display the information required under Sections II.A and II.B in a single screen.
    • A short form notice shall enable consumers ready access to explanatory information that explains the applicable terms set forth in Sections II.A and II.B.
    • Text and font shall be distinct so as to easily stand out from the page background.
    • A short notice shall be readily available from the application.
    • This Code of Conduct encourages but does not require presentation of a short form notice prior to installation or use of the application.
    • App developers that materially change their data collection or data sharing practices in a way that results in expanded or unexpected collection or disclosure of data shall notify consumers and may be required to obtain consent in order to satisfy the requirements under Section 5 of the Federal Trade Commission Act.
    • Companies who endorse this Code may test a notice with consumers before or during implementation. If that user testing, performed in good faith, shows significant and demonstrable improvement in consumer ease of use or understanding when the short form notice lists only the data elements from the list in II.A that are collected and only the entities listed in II.B with which data is shared or who are authorized to collect data, then those endorsers shall have the option to comply with the Code by displaying only the data elements that are collected and only the entities with which data elements are shared or who are authorized to collect data.

Guidelines on Privacy Controls for App Developers from the FTC Mobile Privacy Disclosures

  • Give your users tools that offer choices in how to use your app, such as privacy settings, opt-outs or other ways for users to control how their personal information is collected and shared.

Guidelines on Privacy Controls for App Developers from the OPC Good Privacy Practices (Canada)

  • Provide a privacy dashboard that displays the user’s privacy settings with a tool that allows users to tighten their settings.
    • Approach this display in a way that encourages user action, such as with the use of radio buttons rather than web links.
    • Explain to users the consequences of making a choice to provide data so they can make an informed decision rather than instead of just providing an on/off button.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for Platform Developers from the CA AG Mobile Privacy Guide

  • Provide app users with tools to ask questions and report apps that do not comply with applicable laws or their privacy policies or terms of service.

Guidelines on Privacy Controls for Platform Developers from the Article 29 Opinion on Apps

  • Define rules that apply to submit apps to their apps store that must be respected or risk not being listed in the stores.
  • Provide users with feedback channels to voice privacy concerns about apps.
  • Implement a privacy-friendly remote uninstall mechanism for app users.
  • Allow users to selectively enable and disable permissions for apps.
  • The use of visual signifiers or icons regarding apps' data uses is strongly recommended to make users aware of the types of data processing.
  • In collaboration with the OS manufacturer, develop control tools for users, such as symbols representing access to data on and generated by the mobile device.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for Platform Developers from the FTC Mobile Privacy Disclosures

  • Consider developing a one-stop “dashboard” approach to allow consumers to review the types of content accessed by the apps they have downloaded.
  • Consider offering a Do Not Track (DNT) mechanism for smartphone users. A mobile DNT mechanism, which a majority of the Commission has endorsed, would allow consumers to choose to prevent tracking by ad networks or other third parties as they navigate among apps on their phones.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for Ad Networks from the Article 29 Opinion on Apps

  • Develop and implement online access tools for users without collecting excessive personal data.

No guidelines available.

Guidelines on Privacy Controls for Ad Networks from the NAI Mobile Code

  • The technologies that members use for Cross-App Advertising purposes must provide users with an appropriate degree of transparency and control.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for Ad Networks from the FTC Mobile Privacy Disclosures

  • Work with platform developers to provide a successful implementation of Do Not Track for mobile.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Privacy Controls for Operating Systems from the CA AG Mobile Privacy Guide

  • Provide tools for app developers that enable comprehensive evaluation of data collection, use and transmission.
  • Develop global privacy settings and overrides that enable users to set controls for PII, features or hardware configurations that can be accessed by apps.

Guidelines on Privacy Controls for Operating Systems from the Article 29 Opinion on Apps

  • Implement consent collection mechanisms in the OS at the first launch of the app or the first time the app attempts to access one of the categories of data that have significant impact on privacy.
  • Enable users to uninstall apps and provide a signal to the app developer to enable deletion of relevant user data.
  • Develop and facilitate icons that allow app users to see what data is being used by apps.
  • Provide user-friendly and effective means to avoid being tracked by advertisers and any other third party.
  • Provide a signal to app developers once a user un-installs an app, so that the developer knows to delete all of that users data. Such a signal could be provided through the API.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Privacy Controls for Operating Systems from the FTC Mobile Privacy Disclosures

  • Consider developing a one-stop “dashboard” approach to allow consumers to review the types of content accessed by the apps they have downloaded.
  • Consider offering a Do Not Track (DNT) mechanism for smartphone users. A mobile DNT mechanism, which a majority of the Commission has endorsed, would allow consumers to choose to prevent tracking by ad networks or other third parties as they navigate among apps on their phones.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available
No guidelines available
No guidelines available
No guidelines available
No guidelines available
No guidelines available
No guidelines available

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Security for App Developers from the CA AG Mobile Privacy Guide

  • Use security safeguards to protect PII from unauthorized access, use, disclosure, modification or destruction.
  • Limit internal access to user PII on a need-to-know basis.
  • Use encryption in the transit and storage of PII.
  • Comply with the Payment Card Industry Data Security Standard if payment card information is collected.
  • Work with others in the ecosystem to ensure the application of appropriate security measures to protect personally identifiable data.

Guidelines on Security for App Developers from the Article 29 Opinion on Apps

  • In accordance with the Article 17 of the Data Protection Directive, data controllers and data processors must take the necessary organizational and technical measures to ensure the protection of the personal data they process.
  • Be mindful of the security implications of where you choose to store data (e.g., on the device or remotely in a client-server architecture).
  • Identify clear-cut policies about how software is developed and distributed.
  • Design and implement a security-app-dev-friendly environment, with tools to prevent malicious apps from spreading and allow each app to be installed/uninstalled easily.
  • Minimize the lines and complexity of the code and implement checks to exclude that data might be unintentionally transferred or compromised.
  • All inputs should be validated to prevent buffer overflow or injection attacks.
  • Include adequate security patch management strategies and perform regular, independent system security audits.
  • Take measures to prevent unauthorized access to personal data by ensuring that data are protected both in transit and when stored.
  • Design apps implementing the principle of the least privilege by default, so that apps are enabled to access only the data necessary to make a functionality available to the user.
  • Establish an entropy check of passwords to test the robustness of chosen passwords and encourage users, with warnings, to adopt virtuous user practices such as updating their apps to the latest available version and reminders to avoid the reuse of passwords across different services.
  • In collaboration with the OS manufacturer and/or app store, use available mechanisms to allow users to see what data are being processed by which apps, and to selectively enable and disable permissions. The use of hidden functionalities should not be allowed.
  • Consider re-authentication methods using different channels and multiple factors and/or use of authentication data linked to the end user when sensitive data or paid-for resources are involved.
  • Run apps in specific locations within the memory of the devices (a sandbox) to reduce the consequences of malware/malicious apps.
  • Use low entropy app-specific or temporary device identifiers to avoid tracking users over time, rather than persistent (device-specific) identifiers.
  • Implement privacy-friendly authentication mechanisms, with special care to management of user-ids and passwords. Passwords must be stored encrypted and securely, as a keyed cryptographic hash value.
  • When selecting session identifiers, unpredictable strings should be used, possibly in conjunction with contextual information such as date and time, but also IP addresses or geo-location data.
  • Remain aware of future data breaches notification obligations (such as in the proposed General Data Protection Directive), and work closely together with app developers to prevent those breaches.
  • Develop fixes or patches for any security flaws or vulnerabilities in apps on the market and make them available to users (or to other players who can distribute them to users).
  • Implement and continuously evaluate a thorough security plan that covers the collection, storage and processing of any personal data and provides for vulnerability management and timely and secure releases of reliable bug fixes.

Guidelines on Security for App Developers from the FPF-CDT Best Practices

  • Understand the security risks associated with your app such as the sensitivity of any information you collect and store and the number of people using the app.
  • All applications that access, use, or transfer individuals’ data should be tested rigorously for security purposes and comply with current security best practices.
  • Encrypt data in transit (e.g., SSl/TLS) when authenticating users or transferring personal information.
  • Encrypt data you store about or on behalf of your users, especially sensitive information and passwords.
  • Make an effort to de-identify data before sharing it with another part.
  • Consider hashing device identifiers.
  • Make sure users can log out of a session using the mobile client and that password changes on the back-end side invalidate mobile clients' current sessions.
  • If your application accesses, collects or stores sensitive data or is a fruitful target for phishing attacks, consider using two-factor authentication.

No guidelines available.

Guidelines on Security for App Developers from the GSMA Mobile Privacy Principles

  • Actively manage identifiers. Each party that uses identifiers is responsible for taking measures to:
    • Ensure any unique identifiers apply to only one unique user
    • Ensure unique identifiers are kept up to date and kept only for as long as necessary to fulfill the applications purpose and reasons notified to users
    • Prevent a unique identifier being associated with another user unless required by a justified business need
  • Take appropriate steps to protect users’ personal information from unauthorized disclosure or access.
    • Adopt technical measures and business processes to prevent the misuse or corruption of personal information.
    • Where an application creates or collects personal information considered sensitive, such as log-on details, UDIDs, mobile numbers, contact details, financial details, such information must be stored and transmitted in a secure manner.
    • If you need to collect, transmit and retain sensitive information such as a user’s financial payment details or log-on details, then you should secure this data by using encryption or a suitable hashing mechanism and delete it when it is no longer needed.
  • Authenticate users where possible using risk-appropriate authentication methods.
    • Where the assertion of a real-world identity is an important component of a service, stronger authentication should be implemented, such as two-factor authentication using a mobile handset and UICC.
    • Consider using CAPTCHAs and RE-CAPTACHAs to help differentiate bona fide members from spammers.
    • Use technical tools to restrict spidering and bulk downloads or access without network permission.

No guidelines available.

Guidelines on Security for App Developers from the FTC Mobile Privacy Disclosures

  • Make someone responsible for considering security at every stage of your app's development.
  • Research the mobile platforms you work with so that you can adapt your practices and policies to the specific security-related features and permissions of each platform.
  • Make sure you understand the security features of mobile platforms, implement them properly and take any additional measures necessary to protect your users.
  • Do not rely on platform-based permissions to convey security information to your customers; talk to your users in your own words.
  • If you create credentials for your users (like usernames and passwords), create them securely.
  • Consider protecting the data you store on a user's device by using encryption or other means.
  • If you have servers that communicate with your app, take the appropriate measures to protect your servers.
  • Do not store passwords in plaintext. Instead, consider hashing users' passwords.
  • Use transit encryption for usernames, passwords and other important data. Consider using HTTPS with a digital certificate.
  • Do due diligence before using someone else's code to build or augment your app to ensure there are no security vulnerabilities.
  • Stay aware and communicate with your users, so that you can spot and fix security vulnerabilities.
  • Limit access to a need-to-know basis.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Adopt reasonable security measures.

Guidelines on Security for App Developers from the OPC Good Privacy Practices (Canada)

  • Make sure you secure information you collect.
  • Your security safeguards should be appropriate to the sensitivity of the information.
  • Have appropriate controls in place both on the mobile device and on the backend systems that will store the information to ensure the security of the personal information being handled.
  • Users' information should be encrypted when it is stored and when it is transmitted over the Internet.
  • Ensure that users have a clear and easy way to refuse an update, deactivate and delete the app.
  • To help evaluate your personal information protection readiness, consult the Securing Personal Information: A Self-Assessment Tool for Organizations.

Guidelines on Security for App Developers from the OAIC Mobile Privacy Practice Guide (Australia)

  • Secure the information you collect from users.
  • Make someone in your business responsible for security.
  • Have the appropriate controls in place both on the mobile device and on the backend systems to store personal information securely.
    • Encrypt user information when it is transferred via the internet or stored
    • Adapt your code to allow for differences in mobile platforms
    • Generate credentials securely
    • Do your due diligence on libraries and other third-party code
  • Don’t store passwords in plain text on your server.

Guidelines on Security for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • Research good security practices and apply them to the design of your app and the design of any central servers that the app communicates with.
  • Where passwords are used, ensure they are appropriately salted and hashed.
  • Take advantage of encrypted connections to ensure security of data in transit, such as SSL/TLS.
  • Always use encrypted connections for transmitting usernames, passwords and any particularly sensitive information, including device IDs or other unique IDs.
  • The method of encryption should be appropriate to the sensitivity of the data.
  • You may choose to rely on the operating system's ability to enable encrypted storage.
  • Use tried and tested cryptographic methods.
  • Avoid writing your own code to perform functions which have well established implementations that you can re-use, such as in-app billing.
  • If your app accesses data from other apps or locations, respect the sensitivity of the data in the context of its original purpose, not solely in the context of your app.
  • Pay attention to security vulnerabilities unique to the mobile apps environment. Such vulnerabilities include:
    • Inter-app injection flaws: Ensure that your app sanitizes any input is accepts in a way appropriate for the task at hand.
    • Failure to properly check SSL/TLS certificates: Verify the identity of the party you're communicating with by checking the certificate.
    • Misconfiguration of SSL/TLS on central server: Ensure that any central server only enables strongly encrypted connections and has a valid SSL/TLS certificate.
  • Consider conducting security vulnerability scanning and penetration testing on your app and central servers before roll-out.
  • If any personal data is to be transferred outside the European Economic Area, you will have to demonstrate that there will be adequate protection for it.
  • If you are made aware of a security vulnerability in your app, take action to protect your users. This involves:
    • Fixing the issue in the app's code and issuing an updated version of the app, and
    • Where possible, notifying users of known-vulnerable versions of the app so that they can protect themselves by upgrading
  • If you become aware of an actual security breach of systems you are responsible for, take swift and appropriate action to remedy the problem.

No guidelines available.

Guidelines on Security for Platform Developers from the Article 29 Opinion on Apps

  • In accordance with the Article 17 of the Data Protection Directive, data controllers and data processors must take the necessary organizational and technical measures to ensure the protection of the personal data they process.
  • Collaborate with the app developer using available mechanisms to allow users to see what data are being processed by which apps, and to selectively enable and disable permissions. The use of hidden functionalities should not be allowed.
  • Design and implement a security-friendly environment, with tools to prevent malicious apps from spreading and allow each app to be installed/uninstalled easily.
  • Perform robust security checks on apps before admitting them to the app store. Provide information on such checks and include information on what type of data protection compliance checks are carried out.
  • Apps should be subject to a public reputation mechanism that allows users to rate the app on the basis of its functionalities, with a specific references to privacy and security mechanisms. Such reputation mechanisms should be engineered to avoid false ratings.
  • Feedback channels should be established to give users the opportunity to report security problems with their apps and on the effectiveness of any remote removal procedure.
  • Remain aware of future data breaches notification obligations (such as in the proposed General Data Protection Directive), and work closely together with app developers to prevent those breaches.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Security for Platform Developers from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Adopt reasonable security measures.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Security for Ad Networks from the CA AG Mobile Privacy Guide

  • Transmit user data securely, using encryption for permanent unique device identifiers and personal information, such as an e-mail address or phone number.

Guidelines on Security for Ad Networks from the Article 29 Opinion on Apps

  • In accordance with the Article 17 of the Data Protection Directive, data controllers and data processors must take the necessary organizational and technical measures to ensure the protection of the personal data they process.
  • When collecting and processing personal data for your own purposes, ensure secure transmission and encrypted storage of unique device and app user identifiers and other personal data.
  • When collecting and processing personal data for your own purposes (in particular, advertising or analytics), apply all applicable security features and considerations required of app developers, app stores and OS and device manufacturers.

No guidelines available.

Guidelines on Security for Ad Networks from the NAI Mobile Code

  • Members that collect, transfer or store data for use in Cross-App Advertising and/or Ad Delivery and Reporting shall provide reasonable security for that data.

No guidelines available.

No guidelines available.

Guidelines on Security for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Adopt reasonable security measures.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Security for Operating Systems from the CA AG Mobile Privacy Guide

  • Work with mobile carriers and other appropriate parties to facilitate timely patching of security vulnerabilities.

Guidelines on Security for Operating Systems from the Article 29 Opinion on Apps

  • In accordance with the Article 17 of the Data Protection Directive, data controllers and data processors must take the necessary organizational and technical measures to ensure the protection of the personal data they process.
  • Make available strong and well known encryption algorithms and support appropriate key lengths.
  • Make strong and secure authentication mechanisms available for app developers (e.g., the use of certificates signed by trusted certification authorities to verify the authorization of a remote resource).
  • The access to and processing of personal data by apps should be managed by API built-in classes and methods providing proper checks and safeguards.
  • Ensure that the methods and functions allowing access to personal data include features aiming to implement granular consent requests.
  • Actions should be taken to exclude or limit access to personal data by using low-level functions or other means that could circumvent controls and safeguards incorporated into APIs.
  • Develop clear audit trails into the devices such that end users can clearly see which apps have been accessing data on their devices.
  • Respond quickly to security vulnerabilities in a timely fashion such that the end users are not unnecessarily exposed to security flaws.
  • With app developers, provide end users with upfront information about the length of time they might expect regular security updates. Inform users as soon as possible if a security issue requires an update to fix.
  • Implement a security-friendly environment, with tools to prevent malicious apps from spreading and allow each functionality to be installed/uninstalled easily.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Security for Operating Systems from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Adopt reasonable security measures.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Security for Mobile Service Providers from the CA AG Mobile Privacy Guide

  • Work with operating system developers and other appropriate parties to facilitate timely patching of security vulnerabilities.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Security for Operating Systems from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Adopt reasonable security measures.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Children for App Developers from the CA AG Mobile Privacy Guide

  • Ensure your data collection practices comply with COPPA if the app is directed towards children under 13 or if it collects data from children under 13.

Guidelines on Children for App Developers from the Article 29 Opinion on Apps

  • Data controllers should remain aware of the age limit defining children and minors in national legislation, where parental consent to data processing is a precondition to lawful data processing by apps (can range from 12-18 years old).
  • Data controllers should more strictly respect the principles of data minimization and purpose limitation when consent can be legally obtained from a minor and the app intended for a child or minor. Specifically, data about children should not be processed for analytics or behavioral advertising because those activities are outside the scope of a child's understanding and thus exceed the scope of lawful processing.
  • Relevant information about data processing should be presented in a simple manner, with age specific language.
  • Data controllers should refrain from collecting any relating to the parents or family members of the child user, such as financial information or other sensitive information.
  • Heightened obligations to adapt the data protection principles of data quality, legitimacy, data security, individual rights and notice to children arise from the Article 29 Working Party Opinion on the protection of children's personal data.

Guidelines on Children for App Developers from the FPF-CDT Best Practices

  • Avoid sharing information about kids or teens with third parties and provide clear, age-appropriate notice about any data you do collect or share.
  • Ensure that parents are able to make an informed decision before installing your app, by disclosing your data collection and use practices prior to download.
  • If your app is directed at children 12 and under, you will likely have to comply with COPPA, which requires you to obtain verifiable parental consent before collecting any personal information (e.g., name, email address, or phone number) from a child under the age of 13.
  • Avoid sharing information about kids and teens with ad networks or any other party for the purposes of behavioral advertising.
  • Keep data collection to an absolute minimum.

No guidelines available.

Guidelines on Children for App Developers from the GSMA Mobile Privacy Principles

  • An application or service that is directed at children and adolescents should ensure that the collection, access and use of personal information is appropriate in all given circumstances and compatible with national law.
  • Applications that are intended for children and adolescents should be appropriate for the target age range and help such users to easily understand the consequences of installing or using an application or service.
    • Applications must provide clear notice about the content that will be made available, and its suitability for specific age groups.
    • Ensure that the language and style of the application are appropriate, and that it aids understanding prior to installation and activation of the application.
  • Set privacy protective default settings. Applications that are intended for children and adolescents must have a location default setting that prevents users from automatically publishing their precise location data. Limit the granularity of location data that a child or adolescent is able to share to a generic level such as city or region.
  • Comply with laws on the protection of children. Applications must at all times comply with the special legal requirements that applicable jurisdictions may impose to protect children.
  • Age verify where possible and appropriate. Under certain circumstances, age verification may be appropriate (for example, where applications contain social networking features or allow access to adult content).
    • Where possible, integrate age verification processes into the application in order to control access to age restricted apps or content and minimise inappropriate collection and sharing of personal information relating to children and adolescents.
    • Where integration with access controls is not possible, users may be asked to self-certify instead—n that case, they must be asked for a date of birth during installation, activation or registration. Consider that children and adolescents are adept at bypassing safety controls. If users enter a date of birth indicating an age where they must be denied access to a service or otherwise restricted, they must be prevented from starting over and entering a different date of birth during that session and thereafter if technically possible.
    • Make sure not to include prompts to the user that could be seen as encouraging them to lie about their date of birth.

No guidelines available.

Guidelines on Children for App Developers from the FTC Mobile Privacy Disclosures

  • Ensure that your app complies with COPPA if it is designed for children under 13 and collects personal information or you know your apps is collecting personal information for children under 13.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Ensure that your app complies with COPPA if it is designed for children under 13 and collects personal information or you know your apps is collecting personal information for children under 13.
  • Parents should be able to learn what information an app collects, how the information will be used, and with whom the information will be shared. You should provide this information through simple and short disclosures or icons that are easy to find and understand on the small screen of a mobile device.
  • Alert parents if the app connects with any social media, or allows targeted advertising to occur through the app.

Guidelines on Children for App Developers from the OPC Good Privacy Practices (Canada)

  • PIPEDA, Canada's federal privacy law, does not differentiate children from adults with regard to their privacy rights.
  • British Columbia, Alberta and Quebec have their own privacy laws substantially similar to PIPEDA. These provincial laws also do not differentiate between children's and adults' privacy rights.

No children-specific guidelines available

Guidelines on Children for App Developers from the ICO Privacy in Mobile Apps (U.K.)

  • If your app is aimed at children, pay particular attention to what personal data you may be collecting. The potential harm caused by inappropriate collection of personal data will be greater if the child is not old enough to fully understand the significance of providing their personal data.
  • Data controllers should remain aware of the age limit defining children and minors in national legislation, where parental consent to data processing is a precondition to lawful data processing by apps (can range from 12-18 years old).

Guidelines on Children for Platform Developers from the CA AG Mobile Privacy Guide

  • Inform parents of resources available to help protect their children’s privacy, such as the FTC’s information for parents on the Children’s Privacy Protection Act.

Guidelines on Children for Platform Developers from the Article 29 Opinion on Apps

  • Give special attention to apps directed at children to protect against the unlawful processing of their data.
  • Data controllers should remain aware of the age limit defining children and minors in national legislation, where parental consent to data processing is a precondition to lawful data processing by apps (can range from 12-18 years old).
  • Data controllers should more strictly respect the principles of data minimization and purpose limitation when consent can be legally obtained from a minor and the app intended for a child or minor. Specifically, data about children should not be processed for analytics or behavioral advertising because those activities are outside the scope of a child's understanding and thus exceed the scope of lawful processing.
  • Ensure that relevant information about data processing is presented in a simple manner, with age specific language.
  • Data controllers should refrain from collecting any relating to the parents or family members of the child user, such as financial information or other sensitive information.
  • Heightened obligations to adapt the data protection principles of data quality, legitimacy, data security, individual rights and notice to children arise from the Article 29 Working Party Opinion on the protection of children's personal data.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Children for Platform Developers from the FTC Mobile Privacy Disclosures

  • The app stores should provide a more consistent way for developers to display information regarding their app’s data collection practices and interactive features.
  • App store developer agreements require developers to disclose the information their apps collect; app stores should enforce these requirements.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Provide a more consistent way for developers to display information regarding their app’s data collection practices and interactive features.
  • Enforce your developer agreements’ requirements that developers disclose the information their apps collect.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.

Guidelines on Children for Ad Networks from the Article 29 Opinion on Apps

  • Data controllers should remain aware of the age limit defining children and minors in national legislation, where parental consent to data processing is a precondition to lawful data processing by apps (can range from 12-18 years old).
  • Data controllers should more strictly respect the principles of data minimization and purpose limitation when consent can be legally obtained from a minor and the app intended for a child or minor. Specifically, data about children should not be processed for analytics or behavioral advertising because those activities are outside the scope of a child's understanding and thus exceed the scope of lawful processing.
  • Data controllers should refrain from collecting any relating to the parents or family members of the child user, such as financial information or other sensitive information.
  • Heightened obligations to adapt the data protection principles of data quality, legitimacy, data security, individual rights and notice to children arise from the Article 29 Working Party Opinion on the protection of children's personal data.

No guidelines available.

Guidelines on Children for Ad Networks from the NAI Mobile Code

  • Member companies shall not create Cross-App Advertising segments specifically targeting children under 13 without obtaining verifiable parental consent.

No guidelines available.

No guidelines available.

Guidelines on Children for Ad Networks from the FTC Mobile Privacy Disclosures

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • If you collect user information through apps, disclose your privacy practices, whether through a link on the app promotion page, the developers’ disclosures, or another easily accessible method.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No guidelines available.

Guidelines on Children for Operating Systems from the Article 29 Opinion on Apps

  • Data controllers should remain aware of the age limit defining children and minors in national legislation, where parental consent to data processing is a precondition to lawful data processing by apps (can range from 12-18 years old).
  • Data controllers should more strictly respect the principles of data minimization and purpose limitation when consent can be legally obtained from a minor and the app intended for a child or minor. Specifically, data about children should not be processed for analytics or behavioral advertising because those activities are outside the scope of a child's understanding and thus exceed the scope of lawful processing.
  • Relevant information about data processing should be presented in a simple manner, with age specific language.
  • Data controllers should refrain from collecting any relating to the parents or family members of the child user, such as financial information or other sensitive information.
  • Heightened obligations to adapt the data protection principles of data quality, legitimacy, data security, individual rights and notice to children arise from the Article 29 Working Party Opinion on the protection of children's personal data.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

Guidelines on Children for Operating Systems from the FTC Mobile Privacy Disclosures

  • The app stores should provide a more consistent way for developers to display information regarding their app’s data collection practices and interactive features.
  • App store developer agreements require developers to disclose the information their apps collect; app stores should enforce these requirements.

NOTE: ALL COMPANIES that collect or use consumer data (unless you only collect non-sensitive data from fewer than 5,000 consumers per year and do not share the data with third parties):

  • Provide a more consistent way for developers to display information regarding their app’s data collection practices and interactive features.
  • Enforce your developer agreements’ requirements that developers disclose the information their apps collect.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

Guidelines on Children for Mobile Service Providers from the CA AG Mobile Privacy Guide

  • Inform parents of resources available to help protect their children’s privacy, such as the FTC’s information for parents on the Children’s Privacy Protection Act.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No miscellaneous guidelines.

Additional guidelines for App Developers from the EU Legal Framework

  • If you store or gain access to information stored on the device, you must comply with the consent requirement in Article 5(3) of the ePrivacy directive.
  • To the extent you determine the purposes and means of the processing of personal data on smart devices, you are the data controller and must comply with the provisions of the entire Data Protection Directive. (If you process data for your own purposes, even when the household exemption applies to a user, you are still responsible as data controller).
  • If you have outsourced some or all the actual data processing to a third party and that third party assumes the role of data processor then you must comply with all obligations related to the use of a data processor (this includes the use of a cloud computing provider, see WP29 Opinion 05/2012 on Cloud Computing).
  • Limited responsibilities under EU law exist if no personal data are processed and/or made available outside the device, or if you have taken appropriate technical and organizational measures to ensure that data are irreversibly anonymized and aggregated on the device itself prior to any data leaving the device.
  • If you allow for access of user data by third parties (like ad networks getting geo-location data), then you must employ appropriate mechanisms to comply with the applicable requirements under the EU legal framework.
    • If the third party accesses data stored on the device, the obligation of informed consent of Article 5(3) of the ePrivacy Directive applies.
    • If the third party processes personal data for its own purposes, it may be a joint data controller with you and must therefore ensure respect of the purpose limitation principle and security for the part of the processing for which it determines purposes and means. In different arrangements the responsibility of each party will have to be determined on a case-by-case basis.

No miscellaneous guidelines.

No miscellaneous guidelines.

Additional guidelines for App Developers from the GSMA Mobile Privacy Principles

Social networking & social media:

  • Prompt users to register for social networks, but be careful about mapping registration information to public profiles.
  • Ensure default settings are privacy protective and give users control of their personal profiles in ways that are easy to understand and use.
  • Take measures to protect children from endangering themselves. Underage users require more privacy protective defaults and other protective measures.
  • Create appropriate tools to deactivate and delete data from applications and accounts.

Mobile advertising:

  • Inform users about advertising features. Let users know when an application is ad-supported before they download and/or activate the application.
  • Capture appropriate agreement to target advertising to a user. Users must agree to targeted advertising and give active consent to profiling across applications or by third parties.
  • Target based on legitimately collected data.
  • Advertising may be targeted based only on personal information that is necessary to the application’s primary purpose.
  • Respect privacy when viral marketing. Viral marketing may only occur with the active consent of the user.
  • Ensure content is appropriate. Non-targeted advertising must be appropriate to an overall audience. The content of advertising must be appropriate to the target age range or known age of the user.

Location:

  • Inform the user that location will be used and give them choice. Applications must only access, use and share location data with a prior and informed agreement.
  • Capture appropriate consents to use location data. Some uses of location data require giving users additional privacy information and getting their active consent.

Exceptions to the NTIA Short Form Notice for App Developers

  • This code does not apply to software that a consumer does not interact directly with or to inherent functions of the device. This code also does not apply to apps that are solely provided to or sold to enterprises for use within those businesses.
  • Short form notice is not required for the collection or sharing of data that is not identified or that is otherwise promptly de-identified as long as reasonable steps are taken to prevent the data from being re-associated with a specific individual or device. App developers shall be deemed to take such reasonable steps if they:
    • Take reasonable measures to de-identify the data
    • Commit not to try to re-identify the data
    • Contractually prohibit downstream recipients of data with whom they have contracts from trying to re-identify the data or from disclosing the data to any other person who has not agreed by contract not to re-identify the data
  • The most common app collection and sharing activities for operational purposes as listed below in (a)-(g) are exempt from the short notice requirements in Sections II.A and B, and include those activities necessary to:
    • (a) Maintain, improve or analyze the functioning of the app
    • (b) Perform network communications
    • (c) Authenticate users
    • (d) Cap the frequency of advertising
    • (e) Protect the security or integrity of the user or app
    • (f) Facilitate legal or regulatory compliance
    • (g) Allow an app to be made available to the user on the user’s device
  • With regard to the collection by the app of data listed in II.A or the sharing of data with any third party listed in II.B, the short form notice need not disclose the collection or sharing if the entity providing the notice does not affirmatively authorize such collection or sharing and does not have actual knowledge of, or deliberately avoids obtaining actual knowledge of, such collection or sharing before it occurs. After an app developer or publisher has actual knowledge of such collection or sharing it must promptly either take reasonable steps to prevent collection or sharing that is inconsistent with its short form notice or modify its short form notice to make an appropriate disclosure.
  • If an app as one of its functions permits the purchase of goods or services and does not otherwise passively collect financial information without advance consumer notice, the short form notice is not required to list collection of financial information unless the consumer chooses to make a purchase in which such information is collected or that collection represents a material change from the app's previous short form notice.
  • Short form notice is not required for sharing consumer data with third party service providers where a contract between the app and the third party explicitly:
    • Limits the uses of the data provided by the app to the third party solely to provide a service to or on behalf of the app
    • Prohibits the sharing of the consumer data with subsequent third parties
  • User-specific data does not include aggregated or otherwise substantively de-identified information that does not include any of the user’s personally identifying information and would not allow that identifying information to be inferred.

Guidelines for App Trade Associations from the FTC Mobile Privacy Disclosures

Notice & Transparency:

  • Develop standardized icons to depict app privacy practices.
  • Develop short-form disclosures for app developers.
  • App developer trade associations could continue to work on "badges" or other similar short, standardized disclosures that could appear within apps or within advertisements for apps.
  • App developer trade associations could develop ways to have more standardization with app privacy policies.

Accountability & Oversight

  • Educate app developers on privacy issues.
  • Promote standardized app developer privacy policies that will enable consumers to compare data practices across apps.
  • Take into account the important work of academics, usability experts, privacy researchers, and others in developing icons and other standardized approaches.
  • Consider consumer testing of new mechanisms to ensure meaningful consumer comprehension.
  • Any standardized icons, terminology, format, privacy notices or other disclosures should be accompanied by a robust education campaign.

Additional guidelines for App Developers from the Canadian Privacy Framework

  • An organization is accountable for personal information that it collects, uses and discloses under Canadian privacy laws. Personal information generally means information about an identifiable individual.
    • Information will be about an identifiable individual where there is a "serious possibility" that an individual could be identified through the use of that information, alone or in combination with other available information.
    • Photographs and IP addresses have been found to meet the definition in specific circumstances, and there are several other types of data collected by mobile apps that could be considered personal information.
  • The Personal Information Protection and Electronic Documents Act (PIPEDA), a federal law, sets ground rules for how organizations may collect, use or disclose information about individuals in the course of commercial activities.
    • PIPEDA gives individuals the right to see and ask for corrections to information an organization may have collected about them.
    • PIPEDA applies to organizations engaged in commercial activities across the country, except in Quebec, Alberta and British Columbia, which have their own private sector privacy laws similar to PIPEDA.
    • You may still be covered by PIPEDA even if you aren’t generating revenue from an app. Collecting, using and disclosing personal information to improve user experience, which indirectly contributes to the commercial success of your app, could still be considered a commercial activity under the law.

Additional guidelines for App Developers from the Australian Legal Framework

  • 'Personal information' is any information about an individual whose identity is apparent, or can reasonably be ascertained, from the information. What constitutes personal information will vary, but may include:
    • Photographs
    • Internet Protocol (IP) addresses, Unique Device Identifiers (UDIDs) and other unique identifiers in specific circumstances.
    • Contact lists which reveal details about the contacts themselves and also a user’s social connections.
    • Voice print and facial recognition biometrics, because they collect characteristics that make an individual's voice or face unique.
    • Location information, because it can reveal user activity patterns and habits.
  • 'Sensitive information' includes an individual’s health information, their membership of a union or political association, their sexual preferences or practices, and more. If your app collects sensitive information, you are likely to have additional privacy obligations under the Privacy Act.
  • The Privacy Act regulates the way in which ‘personal information’ is handled by private sector businesses and Australian, ACT and Norfolk Island government agencies. It covers:
    • Any business that:
      • Collects or discloses personal information for a benefit, service or advantage;
      • Handles health information; OR
      • Has an annual turnover of more than $3 million
    • Credit providers and credit reporting agencies
    • Most Australian, ACT and Norfolk Island Government agencies
    • Your app is likely to be covered by the Privacy Act if your business model relies on using personal information to sell advertising.
  • If your business is covered by the Privacy Act, it is important that you understand whether your app is used for direct marketing and make sure it complies with the direct marketing requirements of the Privacy Principles.
  • In most cases, businesses covered by the Privacy Act must comply with the Australian Privacy principles (APPs) beginning March 12, 2014.

Additional guidelines for App Developers from the U.K. Legal Framework

  • The DPA is concerned with personal data and how it should be dealt with. 'Personal data' is defined under the DPA as follows:
    • "personal data" means data which relate to a living individual who can be identified—(a) from those data, or (b) from those data and other information which is in the possession of, or is likely to come into the possession of, the data controller
    • If you are unsure about whether the data you're dealing with is personal, it will likely be simpler to treat it as personal data from the start
  • To comply with the DPA, it is important to understand if you are a 'data controller' or 'data processor.'
    • A data controller is a person who "determines the purposes for which and the manner in which any personal data are, or are to be, processed"
    • A data processor is any person (other than an employee of the data controller) who processes the data on behalf of the data controller
  • If you are a data controller, unless your organization is exempt you must register with the ICO.
    • It is an offense to fail to register when you are required to do so
    • The ICO provides a self-assessment which can help you decide whether or not registration is necessary for your organization
  • The ICO also regulates restrictions in the Privacy and Electronic Communications Regulations (PECR) that will be relevant to your app if it is designed to:
    • Send email, SMS text messages, or voicemail messages
    • Make phone calls
    • Set cookies or other tracking elements, or
    • Engage in 'viral' marketing campaigns
  • If your app is intended to use a premium rate service, adhere to the guidance provided by PhonepayPlus.
  • The Office of Fair Trading (OFT) enforces a range of consumer protection laws which are also relevant to app development, including:
  • The OFT has also proposed 8 principles for developing online and app-based games. These principles outline how an app-based game can better fulfil the requirements of the relevant consumer protection laws, but they will also have relevance to any app, whether or not it is a game.

No miscellaneous guidelines.

Additional guidelines for Platform Developers from the EU Legal Framework

  • You are likely to be the data controller if you process purchase and/or usage information or report it back to app developers. As a data controller, you must comply with the provisions of the entire Data Protection Directive.
  • Where you process an end user’s app download or usage history or similar facility to restore previously downloaded apps, you would also be the data controller for personal data processed for this purpose.
  • If you store or gain access to information stored on the device, you must comply with the consent requirement in Article 5(3) of the ePrivacy Directive.

No miscellaneous guidelines.

No miscellaneous guidelines.

No miscellaneous guidelines.

No miscellaneous guidelines.

Guidelines for App Trade Associations from the FTC Mobile Privacy Disclosures

Notice & Transparency:

  • Develop standardized icons to depict app privacy practices.
  • Develop short-form disclosures for app developers.
  • App developer trade associations could continue to work on "badges" or other similar short, standardized disclosures that could appear within apps or within advertisements for apps.
  • App developer trade associations could develop ways to have more standardization with app privacy policies.

Accountability & Oversight

  • Educate app developers on privacy issues.
  • Promote standardized app developer privacy policies that will enable consumers to compare data practices across apps.
  • Take into account the important work of academics, usability experts, privacy researchers, and others in developing icons and other standardized approaches.
  • Consider consumer testing of new mechanisms to ensure meaningful consumer comprehension.
  • Any standardized icons, terminology, format, privacy notices or other disclosures should be accompanied by a robust education campaign.

No guidelines available.

This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

No guidelines available.

No miscellaneous guidelines.

Additional guidelines for Ad Networks from the EU Legal Framework

  • If you execute operations exclusively on behalf of the app owner (e.g., analytics) and do not process data for their own purposes and/or share data across developers, you are likely to be a data processor and must comply with relevant provisions of the Data Protection Directive.
  • If you collect information across apps to supply additional services or process personal data for your own purposes, you act as a data controller and must comply with all applicable provisions form the Data Protection Directive.
    • In the case of behavioral advertising, the data controller must obtain valid user consent for the collection and processing of personal data through a prior opt-in consent mechanism (WP29 Opinion 2/2010 on online behavioral advertising)
  • To the extent you access or store information on the smart device, you must comply with the consent requirement of Article 5(3) of the ePrivacy Directive.
  • No miscellaneous guidelines.

    Guidelines on Membership Standing for Ad Networks from the NAI Mobile Code

    • Membership in the NAI requires public representations that a member company’s business practices are compliant with each aspect of this Code that applies to its business model, as supplemented by applicable implementation guidelines that shall be adopted by the NAI Board from time to time. Such representations involve explicit acknowledgement of NAI membership and compliance with the Code in each member’s publicly available privacy policy, and inclusion in a group listing of participating companies on a designated page of the NAI website.
    • Members are required to annually undergo reviews of their compliance with the NAI Code by NAI compliance staff or other NAI designee. Members shall fully cooperate with NAI compliance staff or NAI designee, including in the course of annual compliance reviews and any investigation of a potential violation of the NAI Code.
    • The NAI’s policies and procedures for annual compliance reviews and compliance investigations may be updated from time to time, and these policies and procedures shall be made available on the NAI website. These policies and procedures shall not only describe the process undertaken for a compliance review, but shall also articulate the penalties that could be imposed for a finding of non-compliance, including referral of the matter to the U.S. Federal Trade Commission.
    • Compliance with the NAI Mobile Application Code will not be required as part of the 2013 compliance review process.
    • This Code does not govern member companies’ activities insofar as they are acting as first parties or as “service providers” collecting and using data solely on behalf of a single first party. To the extent a company is collecting data across websites owned or operated by different entities, that activity will be governed by the 2013 NAI Code.
    • The NAI shall annually post on its website a report summarizing the compliance of its members with the NAI Code and NAI policies, including any enforcement actions taken and a summary of complaints received.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    Guidelines for App Trade Associations from the FTC Mobile Privacy Disclosures

    Notice & Transparency:

    • Develop standardized icons to depict app privacy practices.
    • Develop short-form disclosures for app developers.
    • App developer trade associations could continue to work on "badges" or other similar short, standardized disclosures that could appear within apps or within advertisements for apps.
    • App developer trade associations could develop ways to have more standardization with app privacy policies.

    Accountability & Oversight

    • Educate app developers on privacy issues.
    • Promote standardized app developer privacy policies that will enable consumers to compare data practices across apps.
    • Take into account the important work of academics, usability experts, privacy researchers, and others in developing icons and other standardized approaches.
    • Consider consumer testing of new mechanisms to ensure meaningful consumer comprehension.
    • Any standardized icons, terminology, format, privacy notices or other disclosures should be accompanied by a robust education campaign.

    No guidelines available.

    This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

    No guidelines available.

    No miscellaneous guidelines.

    Additional guidelines for Operating Systems from the EU Legal Framework

    • You should be considered data controller (and where relevant, joint controller) for any personal data which is processed for your own purposes (such as the smooth running of the device, security, etc.), including user-generated data, data automatically generated by the device or personal data processed by the OS/device manufacturer resulting from the installation or use of apps. As data controller, you must comply with all applicable provisions of the Data Protection Directive.
    • If you provide additional functionality such as a back-up or remote location facility you would also be the data controller for personal data processed for this purpose.
    • To the extent you access or store information on the smart device, you must comply with the consent requirement of Article 5(3) of the ePrivacy Directive.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    Guidelines for App Trade Associations from the FTC Mobile Privacy Disclosures

    Notice & Transparency:

    • Develop standardized icons to depict app privacy practices.
    • Develop short-form disclosures for app developers.
    • App developer trade associations could continue to work on "badges" or other similar short, standardized disclosures that could appear within apps or within advertisements for apps.
    • App developer trade associations could develop ways to have more standardization with app privacy policies.

    Accountability & Oversight

    • Educate app developers on privacy issues.
    • Promote standardized app developer privacy policies that will enable consumers to compare data practices across apps.
    • Take into account the important work of academics, usability experts, privacy researchers, and others in developing icons and other standardized approaches.
    • Consider consumer testing of new mechanisms to ensure meaningful consumer comprehension.
    • Any standardized icons, terminology, format, privacy notices or other disclosures should be accompanied by a robust education campaign.

    No guidelines available.

    This guide is directed to app developers, but may also help assist others in the app ecosystem, including advertising networks, advertisers, mobile platform operators, app developer trade associations, and developers of other (non-mobile) apps.

    No guidelines available.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    No miscellaneous guidelines.

    Guidelines for App Trade Associations from the FTC Mobile Privacy Disclosures

    Notice & Transparency:

    • Develop standardized icons to depict app privacy practices.
    • Develop short-form disclosures for app developers.
    • App developer trade associations could continue to work on "badges" or other similar short, standardized disclosures that could appear within apps or within advertisements for apps.
    • App developer trade associations could develop ways to have more standardization with app privacy policies.

    Accountability & Oversight

    • Educate app developers on privacy issues.
    • Promote standardized app developer privacy policies that will enable consumers to compare data practices across apps.
    • Take into account the important work of academics, usability experts, privacy researchers, and others in developing icons and other standardized approaches.
    • Consider consumer testing of new mechanisms to ensure meaningful consumer comprehension.
    • Any standardized icons, terminology, format, privacy notices or other disclosures should be accompanied by a robust education campaign.