- 1798.100 – Consumers right to receive information on privacy practices and access information
- 1798.105 – Consumers right to deletion
- 1798.110 – Information required to be provided as part of an access request
- 1798.115 – Consumers right to receive information about onward disclosures
- 1798.120 – Consumer right to prohibit the sale of their information
- 1798.125 – Price discrimination based upon the exercise of the opt-out right
Do companies have to “flow down” access requests to service providers?
Probably.
When a business receives a request from a consumer to access the personal information that the business has “collected,” it must decide whether to grant the request or to deny it based upon one of the exceptions to access contained in the CCPA.1 If the business decides to grant the request and provide the personal information in its possession, the CCPA does not specifically state that the business must also direct its service providers to produce the personal information that may be in their possession. This contrasts with deletion requests where the CCPA expressly states that a business which intends to honor such a request must “direct any service providers to delete the consumer’s personal information from their records.”2
Although the CCPA does not expressly state that a business must direct its service providers to search for and produce information collected from a consumer, privacy advocates are likely to take the position that flowing down an access request is implicitly required for the following reasons:
- Service providers are an extension of a business. The CCPA states that a service provider “processes information on behalf of a business.”3 To the extent that a service provider functions as an agent of a business, an argument could be made that a failure by the business to instruct the service provider to search for and produce information could constitute a violation by the business itself.
- The CCPA refers to access to the information “collected.” The CCPA states that a consumer should be able to request access to the “specific pieces of personal information the business has collected.”4 To the extent that a business collects personal information and then transmits it to a service provider for storage or further processing, the personal information was still “collected” by the business and, therefore, may need to be identified and produced regardless of whether it currently resides with the business or with its service provider.
- Access requests under the European GDPR are typically flowed down. Like the CCPA, the European GDPR does not expressly state that a controller must flow down an access request to a processor. In practice, however, it is well accepted in Europe that if a controller grants an access request it should flow down an instruction to its processors to provide the impacted personal information. In turn, the GDPR requires processors to “assist[] the controller . . . [in] the fulfilment of the controller’s obligation to respond to requests for exercising data subject’s rights . . . .”5
The act of instructing service providers to provide personal information in response to a consumer’s request is often referred to as “flowing down” an access request, or an “access request flow down.”
What type of contractual provisions are included within service provider agreements in connection with consumer deletion requests?
Although the CCPA does not itself require that a service provider honor a deletion request that it receives directly from a consumer, a service provider may be contractually obligated to do so by a business.
Many businesses include a contractual provision in their agreement with a service provider requiring the service provider delete personal information that is processed on the business’s behalf at the direction of the business. A less specific “reasonable assistance” provision is also common, which obligates the service provider to reasonably assist the business in fulfilling a deletion request. Although here a service provider retains an argument that facilitating deletion when not required to do so by the CCPA may not be “reasonable assistance,” the existence of this provision signals that a business may be expecting the service provider to honor its deletion requests.
A business may assert that the contractual provisions which are required to meet the definition of “service provider,” imply that a service provider must honor a business’s deletion requests. However, the CCPA specifically allows a service provider to process personal information outside of its relationship to the service provider if such processing is “otherwise permitted by [the CCPA].” 1 As discussed above, the CCPA permits a service provider to refuse a deletion request for a variety of reasons.2
Beyond CCPA specific provisions, a business may argue that other provisions in the agreement with a service provider require deletion of personal information at a business’s direction. If personal information fits the agreement’s definition of confidential information, the confidentiality provision may require confidential information be deleted or returned at the disclosing party’s direction. A provision where a service provider has agreed to abide by the business’s privacy policy may also create an argument that the service provider must delete personal information, depending on the drafting of the privacy policy. If a data protection agreement containing the GDPR’s required Article 28 processor provisions applies, the definition of “personal data” in those provisions may be broad enough to apply to CCPA personal information and thus require deletion.
Can a company market to individuals whose information was collected as part of a sweepstakes?
Federal law sometimes requires that companies obtain consent prior to sending marketing communications. Whether a company needs consent to send a marketing communication to an individual that provided her information as part of a sweepstakes entry depends on the following factors:
(1) The mode of communication (e.g., email, telephone, or SMS) that the company intends to use to contact the individual. As a general proposition, consent is not needed within the United States to send email communications; consent may be needed to send telephone (voice or SMS) marketing communications to individuals.
(2) The technology utilized for the contact. If a company intends to send a telephone (voice or SMS) marketing communication, the level of consent and the level of documentation to substantiate the consent are generally greater if the company uses an automated telephone dialing system (“ATDS”) to send the message, will be transmitting a pre-recorded message, or is contacting a wireless telephone number.
The CCPA does not enhance, or lessen, the consent requirements imposed by federal law for transmitting marketing communications. It may require, however, that if a business collects personal information as part of a sweepstakes that the following steps be taken:1
Is it possible for data that has undergone salted-hashing to still be considered “personal information?”
Maybe.
“Salting” refers to the insertion of a random value (e.g., a number or a letter) into personal data before that data is hashed.
Whether personal information that has undergone salting and hashing is still considered “personal information” depends upon the particular law or regulation at issue.
In the context of the CCPA, information is not “personal information” if it has been “deidentified.”1 Deidentification means that the data “cannot reasonable identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer.”2 A strong argument could be made that data that is salted and then hashed cannot reasonably be associated with an individual. That argument is strengthened under the CCPA if a business takes the following four steps to help ensure that the salted and hashed data will not be re-identified:3
- Implement technical safeguard that prohibit reidentification. Technical safeguards may include the process or techniques by which data has been deidentified. For example, this might include the hashing algorithm being used or the number of characters inserted as part of the salting process.4
- Implement business processes that specifically prohibit reidentification. This might include an internal policy or procedure that prevents employees or vendors from attempting to reidentify data or reverse the salted and hashed values.
- Implement business processes to prevent inadvertent release of deidentified information. This might include a policy against disclosing hashed values to the public.
- Make no attempt to reidentify the information. As a functional matter, this entails taking steps to prohibit reidentification by the business’s employees.
In comparison, in the context of the European GDPR the Article 29 Working Party5 has stated that while the technique of salting and then hashing data “reduce[s] the likelihood of deriving the input value,” because “calculating the original attribute value hidden behind the result of a salted hash function may still be feasible within reasonable means,” the salted-hashed output should be considered pseudonymized data that remains subject to the GDPR.6
For more information and resources about the CCPA visit http://www.CCPA-info.com.
This article is part of a multi-part series published by BCLP to help companies understand and implement the General Data Protection Regulation, the California Consumer Privacy Act and other privacy statutes. You can find more information on the CCPA in BCLP’s California Consumer Privacy Act Practical Guide, and more information about the GDPR in the American Bar Association’s The EU GDPR: Answers to the Most Frequently Asked Questions.
1. CCPA, Section 1798.145(a)(5).
2. CCPA, Section 1798.140(h).
3. CCPA, Section 1798.140(v).
4. Salting refers to the insertion of characters into data before it is hashed to make brute force reidentification more difficult.
5. The Article 29 Working Party was the predecessor to the European Data Protection Board.
6. Article 29 Working Party, WP 216: Opinion 05/2014 on Anonymisation Techniques at 20 (adopted 10 April 2014).
Is it possible for a token to still be considered “personal information?”
Maybe.
“Tokenization” refers to the process by which you replace one value (e.g., a credit card number) with another value that would have “reduced usefulness” for an unauthorized party (e.g., a random value used to replace the credit card number).1 In some instances, tokens are created through the use of algorithms, such as hashing techniques.
Whether personal information that has been tokenized is still considered “personal information” depends upon the particular law or regulation at issue.
In the context of the CCPA, information is not “personal information” if it has been “deidentified.”2 Deidentification means that the data “cannot reasonable identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer.”3 A strong argument could be made that data that is fully tokenized, and no longer is connected to a particular consumer, cannot reasonably be associated with an individual. That argument is strengthened under the CCPA if a business takes the following four steps to help ensure that the tokenized data will not be re-identified:4
- Implement technical safeguards that prohibit reidentification. Technical safeguards may include the process, or techniques, by which tokens are assigned. For example, a business might take steps to randomly generate tokens, or ensure that tokens are not assigned sequentially in a manner that might allow a third party to guess to whom the token relates.
- Implement business processes that specifically prohibit reidentification. This might include an internal policy or procedure that separates tokens from any “key” that might allow an individual to match a token to a consumer.
- Implement business processes to prevent inadvertent release of deidentified information. This might include a policy against disclosing information about individuals even if the names of the individuals have been replaced with tokens.
- Make no attempt to reidentify the information. As a functional matter, this entails taking steps to prohibit reidentification by the business’s employees.
In comparison, in the context of the European GDPR, the Article 29 Working Party5 has stated that even when a token is created by choosing a random number (i.e., it is not derived using an algorithm), the resulting token typically does not make it impossible to re-identify the data and, as a result, the token is best described as “pseudonymized” data which would still be “personal data” subject to the GDPR.6
Is it possible for data that has undergone hashing to still be considered “personal information?”
Maybe.
Hashing refers to the process of using an algorithm to transform data of any size into a unique fixed sized output (e.g., combination of numbers). To put it in layman’s term, some piece of information (e.g., a name) is run through an equation that creates a unique string of characters. Anytime the exact same name is run through the equation, the same unique string of characters will be created. If a different name (or even the same name spelled differently) is run through the equation, an entirely different string of characters will emerge.
While the output of a hash cannot be immediately reversed to “decode” the information, if the range of input values that were submitted into the hash algorithm are known, they can be replayed through the hash algorithm until there is a matching output. The matching output would then confirm, or indicate, what the initial input had been. For instance, if a Social Security Number was hashed, the number might be reverse engineered by hashing all possible Social Security Numbers and comparing the resulting values. When a match is found, someone would know what the initial Social Security Number that created the hash string was. The net result is that while hash functions are designed to mask personal data, they can be subject to brute force attacks.
Whether a hash value in and of itself is considered “personal information” depends upon the particular law or regulation at issue.
In the context of the CCPA, information is not “personal information” if it has been “deidentified.”1 Deidentification means that the data “cannot reasonable identify, relate to, describe, be capable of being associated with, or be linked, directly or indirectly, to a particular consumer.”2 An argument could be made that data once hashed cannot reasonably be associated with an individual. That argument is strengthened under the CCPA if a business takes the following four steps to help ensure that the hashed data will not be re-identified:3
- Implement technical safeguard that prohibit reidentification. Technical safeguards may include the process or techniques by which data has been deidentified. For example, this might include the hashing algorithm being used, or combining the hashed algorithm with other techniques that are designed to further obfuscate information (e.g., salting).4
- Implement business processes that specifically prohibit reidentification. This might include an internal policy or procedure that prevents employees or vendors from attempting to reidentify data or reverse hashed values.
- Implement business processes to prevent inadvertent release of deidentified information. This might include a policy against disclosing hashed values to the public.
- Make no attempt to reidentify the information. As a functional matter, this entails taking steps to prohibit reidentification by the business’s employees.
In comparison, in the context of the European GDPR, the Article 29 Working Party5 considered hashing to be a technique for pseudonymization that “reduces the linkability of a dataset with the original identity of a data subject” and thus “is a useful security measure,” but is “not a method of anonymisation.6 In other words, from the perspective of the Article 29 Working Party while hashing might be a useful security technique it was not sufficient to convert “personal data” into deidentified data.
Is the disclosure of personal information for purposes of creating a look-alike audience a “sale” under the CCPA?
Sometimes.
Many companies today use “look-alike audiences” (a.k.a “mirror audiences” or “similar audiences”) to reach potential consumers through online advertising. A look-alike audience is created when a business sends information, typically in hashed form, about a group of its current customers (the “seed audience”) to an advertising platform who matches the seed audience to an entirely new audience (the “look-alike audience”). The matching process uses the aggregated seed audience information to identify new individuals who have similar purchase habits, preferences, search histories, or other relevant traits. After the match is complete and the look-alike audience created, the advertising platform then serves the business’s ads directly to the look-alike audience.1 While the use of a look-alike audience can offer significant advantages to a company, it can also raise concerns that a company is “selling” personal information as defined by the CCPA.
Depending on the underlying contractual terms, the business’s initial transfer of customer’s personal data to the advertising platform could be considered a “sale” under the CCPA. The CCPA broadly defines “sale” to include “selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating…a consumer’s personal information by the business to another business or a third party for monetary or other valuable consideration.”2 As such, the very act of transferring the data arguably falls within this broad definition, since the business almost certainly gets valuable consideration in return.
However, a “sale” does not include sharing information with a “service provider.” A “service provider” includes an entity who “process[es] information on behalf of a business and to which a business discloses a consumer’s personal information for a business purpose pursuant to a written contract.”4 Importantly, the contract must prohibit the entity from “retaining, using, or disclosing” the personal information for any purpose other than to perform the services specified in the contract.5 The contractual terms between the business and the advertising company governing the creation of the look-alike audience, such as the advertising platform’s terms of service, may exclude the initial data transfer from the definition of “sale” by qualifying the advertising platform as a “service provider.” Each advertising platform has different contractual terms, so in order to determine whether the creation of a look-alike audience is a “sale” under the CCPA, a business must determine the following:
- Does the contract prohibit the advertising platform from “using” the data for any purpose other than to create the look-alike audience?
- Does the contract prohibit the advertising platform from “disclosing” the data to another third party except for the purposes of creating the look-alike audience?
- Does the contract prohibit the advertising platform from “retaining” the data longer than as necessary to create the look-alike audience?
If the contract fails to do any of those three things, or the contract does not govern all of the personal information subject to the transfer, the transfer of data to the advertising platform is likely a “sale” under the CCPA.
What concerns do website owners have with the IAB’s final CCPA Do Not Sell Framework?
The Interactive Advertising Bureau (“IAB”) is a trade association comprised of companies that participate in digital marketing. Its members include both media companies and advertising technology (“adTech”) companies.
In October of 2019, the IAB published a draft IAB CCPA Compliance Framework for Publishers & Technology Companies (the “Draft IAB Do Not Sell Framework”).1 The draft proposed that website owners would provide consumers with a “do not sell” link, transmit a do not sell signal to IAB framework participants if a consumer opted-out, and the framework participants would agree to abide by a “Limited Service Provider Agreement” in their treatment of such data. The proposal was presented as a means of complying with the CCPA’s requirement that companies disclose if they sell personal information, and, if a sale is occurring, include a “Do Not Sell My Personal Information” link on their website.2
Numerous questions and concerns were raised by privacy advocates and the business community with the draft. In December, the IAB released a final version of the framework (the “IAB Do Not Sell Framework”) which addressed some (but not all) of those concerns. The following are some of website owners’ concerns with the viability of the framework as it was finalized:
- Website owners would be contractually limited to dealing with adTech companies that participate in the framework. The IAB Do Not Sell Framework effectuates a do not sell request by attempting to convert adTech companies that have joined the framework, and that have executed a “Limited Service Provider Agreement” provided by the IAB, into “service providers” when such companies receive a do not sell signal from a website owner. From a website owner’s perspective, however, if they participate in the IAB Do Not Sell Framework they are effectively self-restricting the adTech companies with whom they can partner to those that have joined the framework. Specifically the Limited Service Provider Agreement that website owners are required to accept requires that they represent and warrant that if a consumer clicks their do not sell link the website owner will “only” transmit “bid requests . . . to Downstream Participants that are Signatories” of the IAB Do Not Sell Framework.3 Given uncertainty concerning how many companies in the behavioral advertising ecosystem will join the framework, many website owners are concerned about the cost, and the potential disruption, that could be involved in (1) identifying which of their behavioral advertising partners have joined the framework, (2) terminating relationships with behavioral advertising companies that choose not to participate in the framework, and (3) conducting ongoing monitoring of behavioral advertising partners to ensure that they continue their framework participation.
- Website owners that continue to transmit data to non-IAB participants could be alleged to have engaged in deceptive practices. The IAB Do Not Sell Framework requires that website owners post a “do not sell my personal information” link on their website, and disclose in their privacy notice that by clicking the link a consumer’s information will no longer be sold. To the extent that the website owner continues to transmit data to non-IAB participants (i.e., companies that have neither entered the IAB Do Not Sell Framework, or agreed via a separate contract to refrain from using, sharing, or disclosing information that they receive from the website owner for their own purpose if the website owner broadcasts the IAB do not sell signal) it is possible that a regulator or a privacy advocate may allege that the website owner has misrepresented the effect of clicking on the Do Not Sell link.
- The effectiveness of the Limited Service Provider Agreement is unknown. In order for a company to be considered a “service provider” under the CCPA the Act states that there must be a “written contract” and implies that the contract must be “with the business.”4 Although the “Limited Service Provider Agreement” published by the IAB purports to be a contract between and among “all other Signatories to this Agreement” there is ambiguity about whether a court will interpret such an arrangement as a sufficient “contract” between a website owner and downstream adTech companies.5 Furthermore, although the Limited Service Provider Agreement purports to take precedence over pre-existing contracts entered into between a website owner and its adTech partners, the order of precedence identified in the Limited Service Provider Agreement may itself conflict with priority designations within those existing contracts.6 Existing contracts may also prohibit, or nullify, contractual arrangements, like the Limited Service Provider Agreement, that are created without bilateral signatures from both parties.
- IAB, and the adTech participants, refuse to accept any liability for the effectiveness of the framework. The “Limited Service Provider Agreement” disclaims any representation that the the IAB Do Not Sell Framework complies with the CCPA. To the contrary it states that “changes in the interpretation of the CCPA by an enforcement authority or court of competent jurisdiction . . . may hold that this Agreement, in whole or in part, is not permissible.”7 The IAB reiterates its reluctance to warrant that its framework complies with the CCPA in the IAB CCPA Compliance Framework for Publishers & technology Companies document itself where it states that the “IAB make[s] no representations or warranties, express or implied, as to the completeness, correctness, or utility of the information contained in this Framework and the accompanying Agreement and assume no liability of any kind whatsoever resulting from the use or reliance upon its contents.”8 The reluctance to assume any monetary liability if a CCPA penalty is assessed as a result of the use of the framework is reiterated in the Limited Service Provider Agreement where it states in all CAPS that “IN NO EVENT WILL A SIGNATORY BE LIABLE TO ANY OTHER SIGNATORY . . . FOR ANY DAMAGES OF ANY KIND . . . ARISING FROM OR RELATING TO THIS AGREEMENT, REGARDLESS OF WHETHER SUCH SIGNATORY WAS ADVISED, HAD OTHER REASON TO KNOW, OR IN FACT KNEW OF THE POSSIBILITY THEREOF.”9 It is unclear to what extent website owners who may be directly liable for a violation of the CCPA will be comfortable relying upon a compliance framework that ascribes no liability to their adTech partners.
- The Limited Service Provider Agreement may erode existing liability protections. To the extent that a website owner has entered into a separate contract with an adTech partner that provides contractual remedies (e.g., damages) if the adTech partner fails to comply with data privacy laws, the Limited Service Provider Agreement may erode those protections. Specifically, the Limited Service Provider Agreement states that in the face of a conflict with pre-existing contract terms, the Limited Service Provider Agreement will take precedence in connection with the “Sale and/or use of Personal Information.”10 As the Limited Service Provider Agreement states that “IN NO EVENT WILL A SIGNATORY BE LIABLE TO ANY OTHER SIGNATORY . . . FOR ANY DAMAGES OF ANY KIND” an adTech company may attempt to argue that any monetary recovery permitted by an underlying agreement is eroded by the Limited Service Provider Agreement.11
- Device/Browser level opt-out may not comply with the CCPA. The IAB Do Not Sell Framework appears to contemplate that when a user clicks on a website owner’s Do Not Sell My Personal Information link it would typically trigger a “Device/Browser Level Opt Out.”12 A “Device/Browser Level Opt Out means that the consumer’s instruction for their information not to be sold would only apply “to the particular device (e.g., mobile or desktop hardware unit) or browser on which the applicable Consumer has Opted Out.”13 It is unclear whether a device-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and the requirement that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”14 Put differently, while the CCPA prohibits a business from selling a consumer’s personal information after they click a Do Not Sell link, under the IAB Do Not Sell Framework it would appear that a consumer’s personal information would continue to be sold each time they visit a website owner’s site from a different device or a different browser.
- Failure to adequately disclose device/browser level opt-out could result in allegations of deception. The draft IAB Do Not Sell Framework suggested that websites notify consumers who opted out under the framework that if they visited the website from a different device (e.g., a work computer instead of a smartphone, or a smartphone instead of a personal computer) their information would again be sold until, or unless, the consumer submitted a new opt-out request on the new device.15 Specifically it required website owners to state in their privacy notices that “opt out is at a device level and how to opt out across different devices.”16 Interestingly, the final IAB Do Not Sell Framework does not contain such an explicit requirement and instead requires the website owner to generally explain “the effective scope of the opt out.”17 If a website owner does not accurately describe to consumers that the IAB Do Not Sell Framework’s opt-out mechanism appears to be limited to the device/platform used by the consumer to submit an opt-out request, privacy advocates may attempt to allege that the website owner has misrepresented the consumers’ ability to opt-out.”18
- Non-persistent opt-outs may not comply with the CCPA. When a user clicks on a website’s Do Not Sell My Personal Information link, it appears that the framework contemplates that the user’s preference would be recorded in a cookie placed on the user’s machine.19 If a user clears their browser’s cache, that preference selection would, presumably, be erased and, as a result, the user’s personal information would again start to be sold by a business. Put differently, by suggesting that website owner’s utilize cookies to store user Do Not Sell requests, the framework appears to be endorsing a non-persistent system for recording consumer preferences. It is unclear whether a non-persistent opt-out mechanism fully complies with the CCPA’s requirement that a business “refrain from selling personal information collected . . . about the consumer” after receiving an initial opt-out request and wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”20
- Offline to online sales. The CCPA arguably requires a company that receives a do not sell request to cease the selling of information that is collected by the business both online and offline. The IAB framework’s focus on the online collection, and transmission, of do not sell requests does not appear to anticipate that many organizations may not collect sufficient information about a consumer to effectuate the request in the offline environment.
- Admission that most website visitors are “consumers.” The CCPA applies to “consumers” a term defined under the Act as including only residents of the state of California. Many website owners have struggled with how to identify whether a website visitor is, in fact, a California resident. While data points that are sometimes collected by website owners (e.g., IP address, shipping information, or billing information) might bear some correlation to residency, such data points are far from conclusive. For example, a resident of Colorado who works for a company that is headquartered in Los Angeles might ship information to a California office address, present with a California billing address, and even have a California IP address (e.g., via a corporate VPN), but would not be a California resident. The Limited Service Provider Agreement requires that website owners represent and warrant that they have “undertaken commercially reasonable efforts to determine that the User [that clicks on a Do Not Sell My Personal Information Link] is a Consumer” for the purposes of the CCPA, or that the website owner “has assumed that all Users on the Digital Property are Consumers.”21 Both representations may be problematic. The former may state or imply that some effort has been undertaken to verify the residency of website visitors when most websites do not collect residency, or take efforts to verify residency. The latter would require that the website confer upon all visitors the rights of Californians. It also raises the specter that the California attorney general might use the contractual representation in an enforcement action to prevent a company from arguing that a particular visitor was not a Californian.
What concerns have been raised with the IAB’s Do Not Sell Framework?
The Interactive Advertising Bureau (“IAB”) is a trade association comprised of companies that participate in digital marketing; its members include both media companies and advertising technology companies.
In October of 2019, the IAB published a draft IAB CCPA Compliance Framework for Publishers & Technology Companies (the “IAB Do Not Sell Framework”).1 The IAB Do Not Sell Framework proposed a system for companies that participate in third party behavioral advertising to provide consumers with an option for expressing their preference that their information not be sold. The proposal was presented ostensibly as a means of complying with the CCPA’s requirement that companies that sell personal information include a “Do Not Sell My Personal Information” link on their website, and honor the preference of consumers that opt out of such sales.2
Numerous questions and concerns have been raised by privacy advocates and businesses with the IAB Do Not Sell Framework. These include, but are not limited to, the following issues:
- Websites would be limited to dealing with adTech companies that participate in the framework. The IAB Do Not Sell Framework attempts to effectuate a do not sell request by converting any adTech company that has joined the framework, and that has executed a “Limited Service Provider Agreement” provided by the IAB, into a “service provider” when they receive a do not sell signal from a participating website. From a website’s perspective, however, if they participate in the IAB Do Not Sell Framework they may be effectively restricting the adTech companies (including the behavioral advertising network providers) with whom they can partner to those that have joined the framework. Websites may incur significant disruption if they are forced to terminate current adTech partners that decide not to join.
- The terms of the Limited Service Provider Agreement are unknown. Advertising technology companies that participate in the framework (e.g., third party behavioral advertising networks) would contractually agree to be bound by a “Limited Service Provider Agreement.” Although the IAB provides a high level description of the provisions that might be included in the Limited Service Provider Agreement, as of November 20, 2019, the agreement itself had not been published.3 As a result, it is not possible to determine whether the agreement comports with the service provider requirements of the CCPA.
- The effectiveness of the Limited Service Provider Agreement is unknown. In order for a company to be considered a “service provider” under the CCPA the Act states that there must be a “written contract” and implies that the contract must be “with the business.”4 Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that the agreement will not be entered into between a website and a technology company directly as “Digital Properties lack privity with many Downstream Framework Participants.”5 It may be that the IAB anticipates that adTech companies will agree to a set of industry rules or terms to which a website will be a third party beneficiary. Assuming that is the case it is unclear whether a court will interpret such a contractual arrangement as a “contract” between the parties sufficient to create a service provider relationship.
- The Limited Service Provider Agreement will contain no indemnification of websites. Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that it will include “no indemnification provisions.”6 It is unclear to what extent websites that may be directly liable under the CCPA will be comfortable with the risk that arises from service providers that are unwilling to provide any indemnification for privacy-related violations.
- The Limited Service Provider Agreement will impose no liability on adTech companies. Although the “Limited Service Provider Agreement” contemplated in the IAB Do Not Sell Framework has not been published, the IAB states that it will include “a complete limitation of liability.”7 It is unclear to what extent websites that may be directly liable under the CCPA will be comfortable with the risk that arises from service providers that are unwilling to assume any liability for privacy related violations.
- Device level opt-out may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would trigger a device-level opt-out.8 Among other things, the IAB Do Not Sell Framework suggests that websites notify consumers that if they visit the website from a different device (e.g., a work computer instead of a smartphone, or a smartphone instead of a personal computer) their information will again be sold until, or unless, the consumer submits a new opt-out request on the new device. It is unclear whether a device-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and the requirement that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”9
- Browser level opt-out may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would trigger a browser–level opt-out.10 Among other things, the IAB Do Not Sell Framework suggests that websites notify consumers that if they visit the website from a different browser (e.g., Chrome instead of Safari) their information will again be sold until, or unless, the consumer submits another opt-out request on the new device. It is unclear whether a browser-level opt-out fully complies with the CCPA’s requirement that businesses “refrain from selling personal information collected by the business about the consumer” after receiving an initial opt-out request and that businesses wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”11
- Non-persistent opt-outs may not comply with the CCPA. Under the framework when a user clicks on a website’s Do Not Sell My Personal Information link it would record their preference in a cookie placed on the user’s machine.12 If a user clears their browser’s cache that preference selection would, presumably, be erased and, as a result, the user’s personal information would again start to be sold by a business. It is unclear whether a non-persistent opt-out mechanism fully complies with the CCPA’s requirement that a business “refrain from selling personal information collected . . . about the consumer” after receiving an initial opt-out request and wait “at least 12 months before requesting that the consumer authorize the sale of the consumer’s personal information.”13
- Offline to online sales. The CCPA arguably requires a company that receives a do not sell request to cease the selling of information both online and offline. The IAB framework’s focus on the online collection, and transmission, of do not sell requests does not appear to anticipate that many organizations may not collect sufficient information about a consumer to effectuate the request in the offline environment.
- Misrepresentation and deception litigation risk. Some privacy advocates have asserted that the IAB framework would, if adopted, “result in significant misrepresentations of the law.”14 It is not precisely clear what misrepresentations they believe would be made through the framework. However, their statements may be a signal that they intend to work with plaintiff attorneys to test whether use of the framework might be the foundation of a deception claim in litigation.
CCPA Privacy FAQs: Are payment processors and acquiring banks “service providers” under the CCPA?
It’s unclear.
A vendor must be bound by a written contract that prohibits it from:
- Retaining the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,”
- Using the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title,” or
- Disclosing the personal information “for any purpose other than for the specific purpose of performing the services specified in the contract . . . or as otherwise permitted by this title.”
While an argument could be made that a payment processor contains the retention, use, and disclosure restrictions mandated by the CCPA because they receive information from merchants for the purpose of processing credit card payments for the benefit of the merchant, it is possible that a California court could determine that their purpose in processing the information goes beyond simply providing service for their merchant client. For example, in addition to using a credit card number transmitted from a merchant to process a credit card transaction, a payment processor may use that information to look for suspicious activity that could indicate a data breach, or identity theft of a cardholder. They may also have obligations to third parties (e.g., Visa and MasterCard) to retain cardholder information even after they have completed the transaction requested by the merchant. A court might view these types of activities as going beyond the “specific purpose of performing the services” specified in a contract with a merchant.
To the extent that a court were to determine that a payment processor or an acquiring bank does not fall under the statutory definition of “service provider,” a merchant would have to disclose to consumers that their credit card information was “sold” to these companies unless the information transfer fell under one of the exceptions to a “sale” under the CCPA. It is possible that a business could argue that by providing their credit card, the consumer implicitly or explicitly “direct[ed] the business to intentionally disclose personal information or use[d] the business to intentionally interact with a third party.” Put differently, a reasonable consumer would understand that in order for a business to process a credit card transaction, the consumer’s credit card would need to be provided to a variety of third parties ranging from a payment processor, payment gateway, payment authentication service, acquiring bank, and payment card network. The act of providing the credit card and requesting that it be used for payment must, by its nature, be a request that the business disclose the consumer’s information to these entities.