Regulatory Guidance: Mobile Privacy, Tracking & Advertising
Regulatory Guidance: Mobile Privacy, Tracking & 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. 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 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:
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.
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 can be accomplished through the use of mark-up/icons, popup notifications or in-line controls.
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 not do 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.
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