Regulatory Guidance: Mobile Privacy, Tracking & Advertising

Regulatory Guidance: Mobile Privacy, Tracking & Advertising

As much of online activity migrates to mobile platforms -- where screens are smaller, user awareness of marketing practices is low, and the ability to control privacy is often hampered by digital locks or lack of access to things such as cookies -- concerns over privacy are increasing. Many mobile applications lack the most basic and minimal building block of a privacy protection, the privacy policy. While awareness is low, user concern appears evident. For example, a recent Pew Internet Project survey demonstrated, that 57% of all mobile app users have either avoided installing an app based on privacy concerns or uninstalled an app upon becoming aware of concerning privacy practices. And the concerns may well be justified -- a recent report by Juniper found that free apps are far more likely than paid apps to include privacy-invasive features. Further, a large percentage of these are not using the information to send targeted advertisements through their mobile service so much of this collection might be "for reasons less apparent than advertising."

In this atmosphere of heightened concerns, two sets of regulatory guidelines, both issued last week, may shed light on the obligations of those in the app market to protect user privacy and the right to be left alone. The first, a set of guidelines from the Office of the Privacy Commissioner of Canada and the Offices of the Alberta and B.C. Information & Privacy Commissioners, highlights some best practices that app developers should take to ensure their compliance with PIPEDA ("Seizing Opportunity: Good Privacy Practices for Developing Mobile Apps"). The second is a set of Information Bulletins released by the CRTC's enforcement branch in anticipation of the hopefully soon-to-be in-force Canadian Anti Spam & Spyware Legislation (CASL, S.C. 2010, c. 23). The Information Bulletins focus on electronic advertising (including mobile) and the instillation of computer programs, so the two recent Compliance and Enforcement Information Bulletins (CRTC 2012-548 and CRTC 2012-549) are likely to be relevant to both the collection of personal information and the distribution of electronic messages on mobile platforms including text messaging.

Although neither process sought any stakeholder input, the OPC and the CRTC have each held proceedings on loosely related matters in the past. The OPC held a consultation on online tracking and related activities in 2010 (CIPPIC's submission to this) and the CRTC recently completed a proceeding on the parameters for regulations arising from CASL which touched on some portion of these broader Information Bulletins [Telecom Notice of Consultation CRTC 2011-400 which resulted in Telecom Regulatory Policy CRTC 2012-183]. In addition, Industry Canada's e-Commerce branch is in the process of generating CASL regulations overlapping in scope.

OPC Guidelines: Privacy Practices for Developing Mobile Apps

The OPC guidelines confirm that even applications that are not generating revenue may be covered, and that small organizations remain accountable for the personal information of their customers. Data collection must be minimized to what is strictly necessary for legitimate purposes and should be retained only as long as is necessary to accomplish those purposes. Canadian customers have the right to refuse to provide any piece of personal information that is not strictly necessary for the operation of the application:

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. For example, it is not clear why a time management app would need to collect a user's location of their date of birth...A key feature of privacy protection, with respect to non-sensitive information, is allowing users to opt out of data collection. So, if you are sharing behavioural information or device identifiers with third parties (such as an ad network), your privacy policy should identify those third parties and link to information about how to modify or delete the data. You should also provide a means for users to opt out of such tracking.

For more sensitive information, express opt-in consent is required prior to collection. Once collected, information should be technically secured by means of encryption and other mechanisms, and kept only for as long as is strictly necessary to achieve the purpose for which it was collected. For clarity, once a user deletes or uninstalls an app, the app developer no longer has any legitimate purpose to retain their information and it should be deleted.

Not only must app developers ensure their data practices are documented in a privacy policy, but customers should not have to conduct a scavenger hunt in order to locate it. App developers need to ensure users have ready access to the privacy policy before the app is downloaded so that they can decide whether to download it or not. Privacy policies and notification should take into consideration the mobile medium -- smaller screens and intermittent/limited customer attention. The Guidelines suggest the use of icons and layered privacy policies that provide key information at the highest layer and supplement these with more information in subsequent layers. Changes to privacy practices, in particular, must be brought to the customer's attention by means of the update process itself.

Privacy policies alone, however, are not enough, and just-in-time consent mechanisms should be used to supplement information provided in the policies themselves:

Users cannot be expected to remember months later information they read when downloading an app, especially given that they may have many apps on one mobile device. This limits the value of obtaining one-time user consent. Privacy messaging carries more weight if it is delivered at the right time.

While judgement must be exercised in order to avoid notice fatigue, in general, customers should be provided with meaningful real-time information and choices on how their personal information is being used. This is can be accomplished through the use of mark-up/icons, popup notifications or in-line controls, and is particularly important with respect to more invasive collection activities such as location tracking or activation of video and audio recording capabilities.

Where personal information of third parties is collected from a user's device, such as an application user's contacts from their address book, the guidelines underline that specific consent must be obtained. The guidelines are ambiguous as to whether this would constitute independent consent from the application user alone, or whether additional consent from the third parties must be navigated, stating simply that "avoid collecting personal information about third parties from a user’s device unless you have consent." However, application developes should exercise caution in harvesting such personal information absent third party consent, particularly if the data in question is of a sensitive nature and where this information is used for commercial purposes (i.e. to contact third parties or to build on existing advertising profiles relating to third party individuals)(see OPC Report of Findings 2009-008, para 304 et seq). 

Finally, although the document does not provide guidance to mobile app platforms on what their obligations might be with respect to the information they are disclosing to these apps, it is noteworthy that most major app distribution platforms have recently entered into a voluntary pact with the Attorney General of California to refuse distribution of any apps that do not have a privacy policy.

CRTC Anti-SPAM Bulletins

The Canadian Anti-SPAM Legislation will give the CRTC the power to regulate three types of activities: the use of unsolicited commercial electronic messages (CEMs), including messages sent through mobile platforms; the alteration of data transmitted in electronic messages; and the installation of computer programs onto an individual's computer ['Regulated Activities'] but our focus here is primarily on unsolicited CEMs and, to a lesser extent, installation of programs. CASL requires explicit consent prior to sending any commercial electronic message to an individual, although it should be noted that this will likely not apply to banner advertisements, RSS feeds, website content, blog posts, etc., as these are not directed at an individual account, but to the general public. Additionally, CASL provides Canadians protection against programs that would undermine their privacy or the integrity of their computer systems. The animating principle of CASL is to empower individuals by requiring businesses to get consent prior to carrying out any of the regulated activities. In light of this, the recently issued CRTC information bulletins seek to provide guidance on how these consent obligations might be met. Before examining the CRTC Information Bulletins, it should be noted that CASL is not yet in force and that a complimentary set of regulations from Industry Canada are still being development and it is not yet clear how those regulations will interact with the Information Bulletins issued by the CRTC.

The Information Bulletins provide guidance on a number of fronts. First, while both the person sending the message and the person on whose behalf the message is sent must provide contact information to recipients of CEMs, platforms need notdo so as they have no input into the specific content of the CEM [2012-548]. It is not clear, however, at what point a platform might be viewed as synonymous with 'the person sending the message' or whether this changes if the platform receives monetary compensation on a per message basis, as many platforms do. This flexibility is welcome, as platforms are often the animating force behind the sending of CEMs.

Second, as noted above, CASL requires advertisers to seek consent prior to sending CEMs to individuals. This consent-based approach is important, as it lets Canadians be the arbiters of what messages they do or do not wish to receive. Given the low cost in time and effort involved in sending a CEM, the impetus for businesses is to flood Canadians and businesses alike, which is why over 80% of global email traffic is spam. While the cost of dealing with one piece of spam is low, the sheer volume and scope of the spam problem quickly adds up. Researchers estimate the costs of dealing with spam (measured in software and hardware costs, as well as in the collective time it takes to assess messages) within the United States alone at between $20-50 billion annually. Just the electricity it takes to transmit all of this spam annually is equal to the energy consumption of a city the size of chicago over a two year period and a carbon footprint equivalent to what 3.1 million cars generate in one year. Finally, spam is a primary vehicle for spyware, malware, identity theft and fraud. For all of these reasons, the consent-based approach adopted by CASL is useful, as it makes Canadians the arbiters of which CEMs are 'unwanted' and thereby forces companies to ask before flooding their inboxes with unwanted messages.

Consent must be 'sought separately' and must be express or 'opt in' (there are some specified scenarios where CASL allows consent to be implied, but these fall outside the scope of the Information Bulletins). The Bulletins define the 'sought separately' criteria in a manner designed to maximize individual control by preventing tied selling for any of the regulated activities. App developers cannot, for example, force consent to receipt of CEMs as a condition to the installation of a game or other program. Neither can consent to receipt of CEMs be bundled alongside consent to the broader set of terms that accompany any service. In either case, individuals must be free to accept one while rejecting the other. As a further means of enhancing individual control, an unsubscribe mechanism that is 'readily performed' must be made available and set out clearly and prominently. This can be achieved through an unsubscribe link or, in the context of SMS, by notifying users of a one-word SMS command to unsubscribe.

It is not enough for consent to be sought separately, it must also be express. Bulletin 2012-548 specifies that this must involve a positive action by the user to indicate assent. In an electronic context, this requires a positive act of assent by the user (express or opt-in consent) such as toggling an un-toggled box or clicking on a particular icon indicating consent to each specific regulated activity. Bulletin 2012-549 provides additional guidance on how to seek and obtain express consent -- pre-selected toggles are not sufficient. The prohibition on pre-selection appears consistent with industry views on what constitutes express consent in an online tracking environment. Consent may also be sought orally, but the onus on proving consent has been acquired is on the entity seeking to rely on it. For oral consent, this obligation can be met as long as it an independent third party can verify consent was given or, alternatively, where a "complete and unedited audio recording" of the consent is retained by the person seeking to rely on it. Where consent is sought electronically, there must be a way to subsequently verify it has been received by, for example, keeping a record of the date, time, purpose and manner in which such consent was obtained.

Finally, the Bulletin sets out some transparency requirements. For example, if certain specified functions of programs are likely to conflict with user expectations, these must be brought directly to the user's attention and a description of the nature and foreseeable impact of such functions must be provided. Specified functions of programs that fall within this category include:

• collection of personal information stored on the computer;
• making changes to established settings or preferences on the device on which the program is to be installed without the user's knowledge;
• any functionality that might cause the host device to communicate with another device or computer without the user's authorization; and
• the installation of any subsidiary program that can be activated by a third party without the user's knowledge.

Certain types of programs (such as HTML cookies, operating systems and java scripts) are exempted as long as there is user conduct that suggests they have expressly consented to these, perhaps through browser controls or other mechanisms (note: this seems to exclude zombie cookies and similar mechanisms designed to bypass user expectations or controls). These functions, where implicated, must be brought to the individual's attention separately from the general terms of use or licensing agreement if consent is to be obtained.

Where a specified function is necessary for core operation of the program being installed, this must be clearly indicated as part of the app developer's attempt to notify the user of the function in question and this must occur before the program is installed. It appears as though non-essential specified functions should be accompanied by distinct opt-in or 'toggle' consent as well:

...an example of an acceptable means of obtaining consent...would be an icon or any empty toggle box, separate from the licence agreement and other requests for consent, that would need to be atively clicked or checked, as applicable, in order to indicate consent to one, several, or all of the [Specified Functions], as applicable...

 

This page was last updated: October 31, 2012

Tamir Israel, Staff Lawyer