Imminent Expansion of the Security Breach Notification Law

Back in 2003, California became the first state in the U.S. to pass a security breach notification law. California’s Security Breach Notification Law applies to any business that conducts business in California, which of course means that the law reaches nearly all companies that have an e-commerce presence.  In a nut shell, the statute requires businesses to notify California residents when the security of such residents’ personal information has been breached.  The rationale behind the law is that breach notification ensures that residents become aware of a breach, thereby allowing them to take actions to mitigate potential financial losses due to fraudulent use of their personal information.

Attribution: Tom Murphy
Attribution: Tom Murphy

Fast forward ten years.  California Attorney General’s specialized eCrime Unit found that increasingly “criminals are targeting Internet Web sites with inadequate security, including some social media Internet Web sites, to harvest email addresses, user names, and passwords,” and “[b]ecause most people do not use unique passwords for each of their accounts, acquiring the information on one account can give a thief access to [many different] accounts.”

And so, on September 10, the California legislature passed and sent to the Governor’s desk a bill that would amend California’s security breach notification law in a significant way.  This is the second bill in as many weeks to reach the Governor’s desk addressing consumer privacy.  Last week it was AB-370, which I discussed here.  This week, it is California Senate Bill 46 (SB-46), which would expand the definition of “personal information” subject to California’s existing security breach disclosure requirements to include “a user name or email address, in combination with a password or security question and answer that permits access to an online account.”  This could have a significant impact, given that notification requirements following a security breach incident depend upon whether the compromised data falls within the definition of “personal information”.

Overview of California’s Security Breach Notification Law

California’s Security Breach Notification Law (Section 1798.82 of the California Civil Code) requires businesses that own or license computerized data consisting of personal information to disclose any breach of the security of the system following discovery of such breach to any resident of California whose unencrypted personal information was believed to be acquired by an unauthorized person.  The triggering event is a “breach of the security of the system”, which means the unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information maintained by the business.  Likewise, 1798.82 requires businesses that maintain (but do not own or license) computerized data consisting of personal information to notify the owner or licensee of the information of any associated security breach immediately following the discovery of such breach.

Where a data breach occurs and a business is required to issue a notification, the law requires that the notification be written in plain language, and include (1) the name and contact information of the business, (2) the types of personal information that were believed to have been the subject of a breach, (3) the estimated date, or date range, of the breach, (4) the date of the notice, (5) whether the notification was delayed as a result of a law enforcement investigation, (6) a general description of the breach incident, (7) the toll-free telephone numbers and addresses of the major credit reporting agencies if the breach exposed a social security number or a driver’s license number.  Additionally, at the discretion of the business, the notification may also include information about what the business has done to protect individuals whose information has been breached and advice on steps the individual may take to protect him/herself.

Up until what appears to be the imminent passage of SB-46, the definition of “personal information” meant an individual’s first name or first initial and last name in combination with that individual’s (1) social security number, (2) driver’s license or California ID number, (3) account number, in combination with any required security code, PIN, or password that would permit access to that individual’s financial account, (4) medical information, or (5) health insurance information, when either the name or any of the data elements (1)-(5) are not encrypted.

How SB-46 Amends Section 1798.82

SB-46, if signed by Gov. Jerry Brown, would amend 1798.82 in three notable ways.  First, and probably most significantly, SB-46 would broaden the definition of “personal information” to include “a user name or email address, in combination with a password or security question and answer that would permit access to an online account.”  Unlike the existing data elements (e.g., social security number, medical information, etc.), this new category of personal information does not need to be in combination with the individual’s name to be deemed personal information.

Second, and perhaps in an effort to mitigate the impact that will surely be felt by companies, the bill would provide a streamlined notification process for breaches concerning the new online account information category of personal information.  The streamlined notification process would allow the business to comply with notification requirements by providing the security breach notification in “electronic or other form that directs the person whose personal information has been breached promptly to change his or her password and security question or answer, as applicable, or to take other steps appropriate to protect the online account with the business and all other online accounts for which the person whose personal information has been breached uses the same user name or email address and password or security question or answer.”

Third, the bill would create a variation on the streamlined notification process for breaches concerning login credentials of an email account that is furnished by the business.   For these businesses (i.e., email service providers) the business must provide notice by the traditional method required under the current notification requirements (i.e., non-streamlined) or “by clear and conspicuous notice delivered to the resident online when the resident is connected to the online account from an Internet Protocol address or online location from which the business knows the resident customarily accesses the account.”

Certainly, with the occurrence of data breaches on the rise, and while usernames/email addresses and passwords are commonly collected by companies with an eCommerce or social network presence, the additional category of personal information introduced by SB-46 will have a compounding effect on companies’ notification obligations.  Companies, going forward, would be wise to put together a strategy to treat usernames/emails in combination with passwords (or security questions/answers) just as they would a person’s name in combination of a social security number under their existing information security policies.

Do Not Track: How Impending California Law Will Affect All Commercial Web Sites

Do Not Track has found a home in California.  As of September 3rd, California Assembly Bill No. 370 (“AB-370”) sits upon Governor Jerry Brown’s desk awaiting his signature.  Once signed, this bill amends the California Online Privacy Protection Act (“CalOPPA” at Section 22575 of the California Business and Professions Code) and will require commercial website operators that collect personally identifiable information (“PII”) through the Internet to disclose how it responds to Do Not Track (“DNT”) signals.  Most mainstream web browsers have functionality that allows the user to signal her desire to not be tracked.  However, under current federal and state law, websites are not legally required to honor that signal.  While AB-370 does not make honoring a DNT signal a legal requirement, it does aim to inform consumers as to which websites have a practice in place to honor DNT signals.

Attribution:  Electronic Frontier Foundation
Attribution: Electronic Frontier Foundation

Background on the Existing CalOPPA Statute

In 2003, the California Legislature passed CalOPPA.  The law requires operators of “web sites and online services” that collect users’ PII to conspicuously post its privacy policy on its site and comply with the posted policy.  CalOPPA currently requires privacy policies to identify the categories of PII collected, the categories of third-parties with whom that PII may be shared, the process for consumers to review and request changes to his or her PII, the process for notifying users of material changes to the privacy policy, and the effective date of the privacy policy.  An operator has 30 days to comply after receiving notice of noncompliance with the privacy policy posting requirement. Failure to comply with the CalOPPA requirements may result in penalties of up to $2,500 for each violation.

It is important to note, CalOPPA has broad reach.  Virtually all commercial websites fall within its scope for two reasons.  First, it is hard to imagine any commercial website not collecting PII, which (for the purposes of CalOPPA) is defined under Section 22577 as “individually identifiable information about an individual consumer collected online by the operator from that individual and maintained by the operator in an accessible form, including […] (1) a first and last name, (2) a home or other physical address, including street name and name of a city or town, (3) an e-mail address, (4) a telephone number, (5) a social security number, (6) any other identifier that permits the physical or online contacting of a specific individual, or (7) information concerning a user that the Web site or online service collects online from the user and maintains in personally identifiable form in combination with an identifier described in this subdivision.”  Second, even though this is a California law, it applies to any website that collects PII from consumers residing in California.  As such, CalOPPA (including the AB-370 revisions) has a de facto nationwide reach.

The Need to Amend CalOPPA (via AB-370)

The impetus for introducing AB-370 is the growing concern over online tracking, which is also referred to as online behavioral targeting.  According to the good folks at Wikipedia,

“When a consumer visits a web site, the pages they visit, the amount of time they view each page, the links they click on, the searches they make and the things that they interact with, allow sites to collect that data, and other factors, create a ‘profile’ that links to that visitor’s web browser. As a result, site publishers can use this data to create defined audience segments based upon visitors that have similar profiles. When visitors return to a specific site or a network of sites using the same web browser, those profiles can be used to allow advertisers to position their online ads in front of those visitors who exhibit a greater level of interest and intent for the products and services being offered. On the theory that properly targeted ads will fetch more consumer interest, the publisher (or seller) can charge a premium for these ads over random advertising or ads based on the context of a site.”

And, by many accounts, the practice of online behavioral targeting is on the rise. Last year, the Wall Street Journal featured an article describing user-tailored advertising and the explosive demand for web-browser collected consumer data.  One practice is online auctions of consumer web browser data. The article notes that “[d]espite rising privacy concerns, the online industry’s data-collection efforts have expanded in the past few years. One reason is the popularity of online auctions, where advertisers buy data about users’ Web browsing. Krux [which sells a service for website publishers to protect their customer data] estimated that such auctions, known as real-time bidding exchanges, contribute to 40% of online data collection.”  The article tells of one study, where the average visit to a webpage triggered 56 instances of data collection.

And, so, here we have AB-370 to the rescue.  According to the bill’s author, Assemblyman Al Muratsuchi, AB-370 “would increase consumer awareness of the practice of online tracking by websites and online services, […] [which] will allow the consumer to make an informed decision about their use of the website or service.”

CalOPPA After AB-370

In addition to the requirements under the existing law outlined above, the amended CalOPPA will:

1)      Require an operator’s privacy policies to disclose how it responds to web browser DNT signals or “other mechanisms that provide consumers the ability to exercise choice regarding the collection of PII about an individual consumer’s online activities over time and across third-party Web sites or online services”; provided the operator engages in PII data collection;

2)      Require an operator’s privacy policies to disclose whether third parties may collect PII about an individual consumer’s online activities over time and across different Web sites when a consumer uses the operator’s site; and

3)      Permit an operator to satisfy the response disclosure requirement for DNT signals by providing a clear and conspicuous hyperlink in the privacy policy to an online location containing a description, including the effects, of any program or protocol the operator follows that offers the consumer that choice.

For all the non-techies out there, it may be useful to quickly explain how Do Not Track technology works.  It is actually relatively simple.  In practice, a consumer wishing to communicate a DNT signal to sites she is visiting would generally do so via her web browser controls.  By changing the setting in her browser properties, the browser enables the HTTP header field (known as the “DNT Header”) that requests that a web application disable its tracking of an individual user.  The header field name is DNT and it accepts three values: “1” in case the user does not want to be tracked (opt out), “0” in case the user consents to being tracked (opt in), or “null” (no header sent) if the user has not expressed a preference. The default behavior required by the standard is not to send the header (i.e., null value), until the user chooses to enable the setting via their browser.

Implications of AB-370

Before going into the implications of the bill, it should be made clear what AB-370 is not.  One thing that the text of the bill and supporting commentary make clear is that AB-370 is not a Do Not Track law.  Back in March 2012, the FTC finalized the “Protecting Consumer Privacy in an Era of Rapid Change” report, in which the FTC endorsed the implementation of a Do Not Track system.  The report is not a regulation and, as such, there remains (even after AB-370 is signed into law) no legal requirement for sites to honor the headers.

In contrast, AB-370 is a disclosure law.  Its aim is to promote transparency.  The logic goes something like this:  If a privacy policy discloses how an operator handles a Do Not Track signal from a browser, then individual consumers will make informed decisions about their use of the site or the service.  As the California Attorney General’s Office put it, “AB-370 is a transparency proposal, not a Do Not Track proposal. When a privacy policy discloses whether or not an operator honors a Do Not Track signal from a browser, individuals may make informed decisions about their use of the site or service.”

What Remains to Be Seen Through AB-370 Transparency

While on the surface of the bill, the disclosure requirement might seem simple.  However, the next logical question is “but, how exactly?”  Despite the best efforts of industry consortiums, such as the World Wide Web Consortium (W3C), there is still no clear consensus on how to handle DNT signals.  Even less clear is how best to handle DNT signals in the face of third-party tracking on the operator’s site.  So, by extension, how best to disclose the operator’s handling of DNT signals is likewise unclear.  Until an industry practice becomes standardized, the best way forward has to be for the operator of the site to simply (but, extremely accurately) state how it responds to the DNT Header.  By way of example, this could perhaps be achieved by adding the following sentence to the operator’s privacy policy:

  • If Operator Doesn’t Recognize Do Not Track Signals: “This Site does not receive or respond to the DNT Header”
  • If Operator Does Recognize Do Not Track Signals: “This Site receives the DNT Header and responds to a DNT:1 value by … {fill in the blank with how data collection by the operator and/or its third-parties is impacted}“

Lastly, even though AB-370 is a disclosure law and not a legal requirement to honor DNT signals, the practical effect could leave little distinction.  The Consumer Watchdog predicts, albeit somewhat cautiously, that “requiring transparency could well prompt companies to compete based on their privacy practices [and] will likely prompt more companies to honor Do Not Track requests […]”.  How website operators react to the full transparency impact of AB-370 will be interesting to see! (Pun entirely intended)

Blurred Lines: Using Google AdWords after 1-800-Contacts

Last month, the 10th Circuit issued its opinion in 1-800 Contacts v. Lens.com.  This decision essentially establishes that using a competitor’s trademark in Keyword advertising will not constitute infringement, to the extent the competitor’s mark is not used within the sponsored link.

The 1-800-Contacts case arises out of advertising through AdWords, which is a program offered by Google. A company using AdWords pays Google to feature one of its ads within sponsored search results whenever a designated term (a “Keyword”) is used in a Google search.  The issue before the Court was whether the Lanham Act was violated by an advertiser’s use of Keywords that resembled a competitor’s service mark.  The Lanham Act prohibits the infringement of trademarks used to identify products, and of service marks used to identify services.  1-800-Contacts is a supplier of replacement contact lenses. It owns the federally registered service mark “1800CONTACTS”. One of its competitors is Lens.com.  1-800-Contacts sued Lens.com asserting that Lens.com infringed the 1800CONTACTS mark by purchasing Keywords resembling the mark. 1-800-Contacts alleged that Lens.com’s conduct directed potential customers to Lens.com under the theory of “initial-interest confusion”.

Screenshot of search results from Googling "Velcro"...trademark law humor.
Screenshot of search results from Googling “Velcro”…trademark law humor.

Before getting too far into the Court’s legal analysis, it is helpful to understand a little more about Google search and how the AdWords program fits into the marketing strategies of companies.  As most everyone is aware, a typical Google search serves up two types of results: (1) organic results, and (2) sponsored links. Organic results are links generated by Google’s search algorithms and are sorted by relevance and quality.  Google does not serve up advertisements among the organic results. However, through the AdWords program a company can pay Google to be displayed as a sponsored link.  As you can see from the screenshot above, sponsored links (the first 3 results) include advertising copy and links to the advertisers’ websites.

For its ad to appear as a sponsored link, an advertiser bids to reserve a particular word or phrase (i.e., the Keywords) that triggers the display of its ad.  The serving up of the ad based on a user’s search is referred to as an “Impression”. An advertiser pays Google only if the user actually clicks on its Impression.  The per-click amount that the advertiser owes Google is based on the advertiser’s bid price for the Keyword underlying the Impression.  Advertisers who bid higher amounts will generally receive greater visibility to consumers based on their higher placement among the sponsored link results.  Essentially, a Google search for “1800CONTACTS” resulting in a sponsored link for Lens.com could occur only if Lens.com had bid on that exact term or on some phrase containing that exact term.

Putting aside search engine optimization and marketing and returning now to the law, the Lanham Act protects service marks, in addition to trademarks.  A service mark is “any word, name, symbol, or device, or any combination thereof” that is used “to identify and distinguish the services of one person, including a unique service, from the services of others and to indicate the source of the services, even if that source is unknown.”  The service mark “1800CONTACTS” is such a mark.  To succeed on an infringement claim under the Lanham Act, a plaintiff must show:

  1. it has a protectable interest in the mark;
  2. the defendant has used an identical or similar mark in commerce; and,
  3. the defendant’s use is likely to confuse consumers.

With elements (1) and (2) easily satisfied, the only issue remaining for the Court was whether Lens.com’s use resulted in (3) the likelihood of confusion.  1-800-Contacts’ theory of confusion is based on initial-interest confusion. 1-800-Contacts argues that although Lens.com never published any ads containing a 1-800-Contacts mark in their text, Lens.com bid on Keywords causing its ads to appear in response to searches for the 1800CONTACTS mark.  This, argues 1-800-Contacts, diverts customer interest away from 1-800-Contacts’ website and toward Lens.com’s website.  The classic example of initial-interest confusion exists when a consumer seeks a particular company’s product, but is lured to the product of a competitor by that competitor’s use of the other company’s same or a similar mark.  Improper confusion occurs even if the consumer becomes aware of the competitor’s actual identity before purchasing the product.  The Court relied on a six-factor analysis, known as the King of the Mountain factors, to decide whether a likelihood of confusion exists:

  1. the degree of similarity between the marks;
  2. the intent of the alleged infringer in adopting its mark;
  3. evidence of actual confusion;
  4. the relation in use and the manner of marketing between the goods or services marketed by the competing parties;
  5. the degree of care likely to be exercised by purchasers; and
  6. the strength or weakness of the marks.

The Court emphasized that initial-interest confusion occurs when a consumer in search of the plaintiff’s product is lured to the product of the defendant, as in a bait-and-switch tactic, notwithstanding that the confusion is dispelled by the time of sale.  The Court, on behalf of 1-800-Contacts, summarized the initial-interest confusion argument as follows:

A consumer enters a query for “1–800 Contacts” on Google; sees a screen with an ad for Lens.com that is generated because of Lens.com’s purchase of one of the nine Challenged Keywords; becomes confused about whether Lens.com is the same source as, or is affiliated with, 1–800; and therefore clicks on the Lens.com ad to view the site. Lens.com has exploited its use of 1–800’s mark to lure the confused consumer to its website.

While making a convincing, yet somewhat facetious argument, the Court ultimately found the actual data associated with Lens.com’s AdWords campaign to be more compelling.  Citing the actual AdWords data, the Court detailed just how often consumers were lured by the Lens.com Impression. Specifically, Lens.com’s use of the 1800CONTACTS-like Keywords yielded 1,626 Impressions over an eight month period.  Of these 1,626 instances, only 25 resulted in a user actually clicking on the ad for Lens.com.  As the Court stated,

The users in those 25 instances may have been confused into thinking that Lens.com was affiliated with 1–800, or they may simply have wished to look at the offerings of those whom they knew to be 1–800’s competitors. What we can say, though, is that initial-interest confusion occurred at most 1.5% of the time that a Lens.com ad was generated by a Challenged Keyword in those eight months. This number cannot support an inference that Lens.com’s keyword activity was likely to “lure” consumers away from 1–800.  It is thus insufficient to justify relief.  We conclude that the factors other than evidence of actual confusion (even if we assume that 1–800’s mark is a strong one) firmly support the unlikelihood of confusion. This case is readily distinguishable from Australian Gold, in which the alleged infringer used its competitor’s trademarks on its websites.

Note: The Court refers to the Australian Gold case, in which the defendants used Australian Gold’s trademarks on their own websites and placed Australian Gold’s marks in hidden codes associated with their websites (i.e., metatags).  These acts were found to create initial-interest confusion because they caused Internet searches for Australian Gold trademarks to return search results that contained the defendant’s links within a search engine’s organic listings.

The takeaway here is that while using the marks of a competitor to lure consumers into potentially purchasing competing products sounds a lot like a cause of action under the Lanham Act, the context and results of the underlying marketing campaign might show that such use did not actually cause confusion.  Where context and data do not support a finding of actual confusion (and by apparent extension, a likelihood of confusion), then, at least in the 10th Circuit, the trademark owner will have an uphill battle under the theory of initial-interest confusion.

comScore: A Lesson in Unauthorized Use of Consumers’ Data

Last week, the Seventh Circuit upheld a lower court’s class certification in the case of Harris v. comScore, Inc.  Although issued without opinion, the Seventh Circuit’s refusal to reverse the District Court’s certification should signal to online marketing and analytics firms that there may be significant exposure related to consumer data collection.

Public Domain
Public Domain (“Big Data”)

The comScore class action suit was based on violations of the Stored Communications Act (“SCA” at 18 U.S.C. § 2701(a)(1), (2)), the Electronic Communications Privacy Act (“ECPA” at 18 U.S.C. § 2511(1)(a), (d)), the Computer Fraud and Abuse Act (“CFAA” at 18 U.S.C. § 1030(a)(2)(C)), and common law unjust enrichment.

The complaint alleged that comScore improperly obtained and used consumers’ personal information after they downloaded and installed comScore’s software.  The software at issue here is called OSSProxy.  Once installed on a computer, OSSProxy constantly collects data about the user’s computer activity and sends that data back to comScore’s servers.  Depending on how cognizant you are of data collection software and current practices, the following may or may not shock you:

“The OSSProxy software collects a variety of information about a consumer’s computer, including the names of every file on the computer, information entered into a web browser, including passwords and other confidential information, and the contents of PDF files.”

OSSProxy was installed on millions of computers between 2008 and 2011.  To accomplish this, comScore distributes its OSSProxy software through cooperation with third-party providers (appropriately referred to as “bundlers”) who distribute free digital products to consumers online.  Upon downloading the bundlers’ free software, the consumer is prompted to download OSSProxy.  The prompt includes a “Download Statement” and, at least in some cases, a link to comScore’s User License Agreement (ULA).   OSSProxy downloads and installs on a consumer’s computer only after the consumer checks “Accept.”  The bundler’s free digital product downloads and installs even if the consumer “Rejects” the OSSProxy terms, although that fact is confusingly unapparent to an average consumer.

A critical common question among putative class members was whether comScore exceeded the scope of the consent it received from consumers.  As reproduced in the District Court opinion, the Downloading Statement reads in relevant part as follows:

“In order to provide this free download, RelevantKnowledge software, provided by TMRG, Inc., a comScore, Inc. company, is included in this download. This software allows millions of participants in an online market research community to voice their opinions by allowing their online browsing and purchasing behavior to be monitored, collected, aggregated, and once anonymized, used to generate market reports which our clients use to understand Internet trends and patterns and other market research purposes. The information which is monitored and collected includes internet usage information, basic demographic information, certain hardware, software, computer configuration and application usage information about the computer on which you install RelevantKnowledge. We may use the information that we monitor, such as name and address, to better understand your household demographics; for example, we may combine the information that you provide us with additional information from consumer data brokers and other data sources in accordance with our privacy policy. We make commercially viable efforts to automatically filter confidential personally identifiable information and to purge our databases of such information about our panelists when inadvertently collected. By clicking Accept you acknowledge that you are 18 years of age or older, an authorized user of the computer on which you are installing this application, and that you have read, agreed to, and have obtained the consent of all computer and TV users to the terms and conditions of the Privacy Statement and User License Agreement.”

After quickly dismissing the unjust enrichment claim as inappropriate for class action treatment, the Court allowed the claims based on three federal statutes that provide protection against the unauthorized data collection from the plaintiffs’ computers. Each of the three statutes provides an exception to liability if the person obtaining the information has the consent of the computer user.

The plaintiffs alleged that comScore exceeded the scope of their consent to monitoring in the ULA (as incorporated via the Downloading Statement) by:

1)      “fuzzifying” or “obscuring” confidential information collected, rather than automatically filtering that information;

2)      failing to “make commercially viable efforts to purge” confidential information that it does collect from its database;

3)      intercepting phone numbers, social security numbers, user names, passwords, bank account numbers, credit card numbers, and other demographic information;

4)      intercepting the previous 25 websites accessed by a consumer before installation of comScore’s software, the names of every file on the consumer’s computer, the contents of iPod playlists on the computer, the web browsing history of smartphones synced with the computer, and portions of every PDF viewed by the user during web browsing sessions; and

5)      selling the data collected from the consumer’s computer.

Specifically, the Stored Communications Act (SCA) provides a private action against any person who intentionally accesses without authorization a facility through which an electronic communication service is provided or intentionally exceeds an authorization to access that facility; and thereby obtains, alters, or prevents authorized access to a wire or electronic communication while it is in electronic storage in such system. The Electronic Communications Privacy Act (ECPA) provides the same with respect to any person who intentionally intercepts, endeavors to intercept, or procures any other person to intercept or endeavor to intercept, any wire, oral, or electronic communication, or intentionally uses, or endeavors to use, the contents of any wire, oral, or electronic communication, knowing or having reason to know that the information was obtained through the interception of a wire, oral, or electronic communication.  Finally, the CFAA creates a private right of action against any person who intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains information from any protected computer.

The Court concluded that the class action requirements under Federal Rule of Civil Procedure 23(a) (i.e., numerosity, commonality, typicality, adequacy of representation, and ascertainability), as well as the requirements under Rule 23(b)(3) of predominance and superiority were all met.  Rule 23(b)(3) provides that a class action may be maintained only if “the court finds that the questions of law or fact common to class members predominate over any questions affecting only individual members, and that a class action is superior to other available methods for fairly and efficiently adjudicating the controversy.”  As to this “predominance and superiority” requirement, the Court was not moved by comScore’s assertion that class certification should be precluded due to the issue of whether each individual plaintiff suffered damage or loss from comScore’s actions.  As the Court stated,

“That argument has no applicability to the ECPA or SCA claims, both of which provide for statutory damages. The CFAA is different, however, in that it grants a civil action only to “[a]ny person who suffers damage or loss.”  [Nevertheless], the Seventh Circuit has recently reiterated that individual factual damages issues do not provide a reason to deny class certification when the harm to each plaintiff is too small to justify resolving the suits individually.”

The lesson here for businesses is to make sure their terms of service, privacy policies, license agreements, website/mobile app terms of use, etc. accurately reflect their actual practices regarding collection and use of customers’ data.  As companies increasingly leverage “big data” (whether as direct marketing firms or indirectly through outsourced analytics providers), the adequacy of the notice and consent obtained from customers might just be the single most important factor in avoiding a costly, high-profile class action lawsuit.

 

DiOS Mio! Apple’s License for Internal Apps (Part 3 of 3)

In this third and final post on developing internal apps pursuant to Apple’s iOS Developer Program Enterprise License Agreement (the “License”), I will address the terms governing app deployment and distribution.  Also, worth mentioning, are the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.

Creative Commons Attribution: Brion VIBBER
Creative Commons Attribution: Brion VIBBER

As a quick recap, Part 1 discussed the rights and restrictions as they relate to the use of Apple Software; while Part 2 focused on the rights and restrictions as they relate to the use of Internal Apps (i.e., the software programs developed for specific use with an iPhone or iPad for internal deployment to, and use by, the company’s employees).  Leaving now the Internal App development aspects of the license, this post will fast forward and direct its focus on distributing those Internal Apps across the Licensee’s enterprise.

Deployment of Internal Apps

Internal Apps developed under the License may be deployed on Deployment Devices (i.e., the test devices used during the development process and other iOS products owned or controlled by the company) in two ways: (1) General Deployment – deployment for internal use by the company’s employees, and (2) Limited Customer Deployment – deployment for use by customers either on the company’s physical premises or under the direct supervision and physical control of the company’s employees in other locations.  Each of these methods of deployment will be discussed in turn below.

General Deployment

Prior to deployment, all Internal Apps must be signed with an Apple-issued certificate in order to be installed on Deployment Devices.  The company is solely responsible for determining which employees should have access to the Internal Apps and Deployment Devices.  Additionally, it is the company’s responsibility to manage and monitor employees’ use of the Internal Apps and Deployment Devices on an ongoing basis.  The company must promptly retrieve Deployment Devices from individuals who are no longer employed or engaged by the company.  Similarly, the company must cut off such individuals’ access to the Apple Software, Apple-issued digital certificates, and Provisioning Profiles.

Limited Customer Deployment

In addition to the General Deployment to the company’s employees, the License allows customers of the company to use its Internal Apps, but only (i) on the company’s physical premises, or (ii) in other locations, provided all such use is under the direct supervision and physical control of an employee of the company (e.g., a sales presentation to a customer).  This Limited Customer Deployment is subject to Apple’s right to review and approve or reject any Internal App that the company would like to deploy for use by its customers.

Pre-Release Apple Software

Throughout participation in the Program, Apple may make certain Pre-release Software available to the Licensee.  Use of this Pre-release Software is for evaluation and development purposes only.  The Pre-release Software should not be used by the company in a commercial operating environment or with important data.  To the extent the company chooses to use Pre-release Software, any research or development that it performs with respect to the pre-release versions of the Apple Software is done entirely at the company’s risk.

If an Authorized Test Device contains any Pre-release Software, it is the company’s responsibility to restrict access to these Authorized Test Devices to Authorized Developers.  Furthermore, the company’s Authorized Developers must not disclose or otherwise transfer Authorized Test Devices containing Pre-release Software to any third party.  By installing any Pre-release Software on the company’s Authorized Test Devices, Apple reserves the right to lock these devices in testing mode.  This could render Authorized Test Devices incapable of being restored to their original condition.

Confidential Nature of Pre-Release Apple Software

The Pre-release Software is Apple’s Confidential Information and is subject to the confidentiality obligations under the License.  The confidentiality obligations remain in effect until the Pre-release Software (or features thereof) is commercially released.  Pursuant to the License, the company must protect Apple’s Confidential Information using at least the same degree of care that it uses to protect its own confidential information of similar importance.  The Licensee is allowed to use Apple’s Confidential Information only for the purpose of evaluating and developing Internal Apps.  The company is prohibited from disseminating Apple’s Confidential Information to anyone other than: (i) the company’s employees and contractors who have a need to know; and (ii) who are bound by a written agreement that prohibits unauthorized use or disclosure of the Apple’s Confidential Information.

DiOS Mio! Apple’s License for Internal Apps (Part 2 of 3)

In this second part of the three-part post discussing the Apple iOS Developer Enterprise Program (the “Program”), I will continue by describing the terms of Apple’s iOS Developer Program Enterprise License Agreement (the “License”) that specifically govern the apps developed from the Apple Software.  Where Part 1 was limited to the rights and restrictions as they relate to the use of Apple Software, this Part 2 focuses on the rights and restrictions as they relate to the use of Internal Apps.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s (i.e., the “Licensee’s”) employees.

Attribution: Zacfranks
Attribution: Zacfranks
Note: Yes, I am aware that this is an Android App :)

As I mentioned in Part 1, the Licensee retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Nevertheless, the Licensee should be well advised that Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including the Internal Apps.  This means that Apple may use and freely disclose any such information on an unrestricted basis without notifying the Licensee.

APIs and Functionality

The following are requirements that a Licensee’s Internal Apps must adhere to with respect to Application Programming Interfaces (APIs) and functionality.

  • Internal Apps may use documented APIs only in the manner prescribed by Apple
  • Internal Apps must not use or call any private APIs
  • Internal Apps must not download or install executable code
  • Internal Apps must not facilitate commerce, credits, or purchases of any kind
  • Internal Apps may only read data from, or write data to, the Internal App’s designated container area on the device
  • Internal Apps must have at least the same features and functionality when run by a user in compatibility mode on an iPad, except where any feature or functionality is not supported by a particular hardware device
  • Internal Apps must comply with Apple’s Human Interface Guidelines

Data & Privacy

Under the License, a company’s Internal Apps may not collect user or device data without prior end-user (i.e., employees’) consent.  This consent requirement means the Licensee must provide clear notice to users regarding the company’s collection, use, and disclosure of user or device data.  Further, even where consent is obtained, the data collected can only be used to provide a service or function that is directly relevant to the use of the Internal App.  Under no circumstances, can a Licensee use analytics software in their Internal Apps to collect and send device data to a third party.  Additionally, the Licensee must take appropriate steps to protect such data from unauthorized use, disclosure, or access by third parties.  If a user ceases to consent or affirmatively revokes consent for the Internal App’s collection, use, or disclosure of his or her user or device data, the Licensee must promptly cease all such use.  In other words, the company must provide its employees with an opt-out mechanism.

Internal Apps that offer location-based services or functionality must notify and obtain consent from an end-user before his or her location data is collected, transmitted, or otherwise used by the Internal App.  If such Internal App uses location-based APIs to provide real-time navigation, the Licensee must have an end-user license agreement (e.g., a Terms of Service) that includes the following notice: YOUR USE OF THIS REAL TIME ROUTE GUIDANCE APPLICATION IS AT YOUR SOLE RISK. LOCATION DATA MAY NOT BE ACCURATE.

If the Licensee develops Internal Apps that collect or record images, pictures, or voice content (collectively “Recordings”), then the company must comply with all applicable privacy laws and regulations.  Depending on the type of Recording and the intended use of such Recording, this may require notice be provided and/or consent be obtained from employees; as, for example, consent to use the employees’ likeness or image, to the extent the Internal App contains photo-capture functionality.  In addition, per the License, a company’s Internal Apps must display an obvious audio, visual, or other indicator to the end-user as part of any Internal App that is making an active Recording.

Specific Types of Content

All content used within the Licensee’s Internal Apps must either be owned by the company, or properly licensed by the company from the content owner.  If the company’s Internal Apps allow employees to send SMS messages, then the company must inform its employees, prior to their use of such functionality, that standard text messaging rates or other carrier charges may apply.  Internal Apps may include sweepstake or contest functionality; however, the Licensee must be named as the sole sponsor of the promotion.

Security

The Licensee is responsible for preventing any unauthorized person from having access to Provisioning Profiles, digital certificates, and corresponding private keys.  Additionally, the Licensee must immediately notify Apple in writing if it has any reason to believe there has been a compromise of any Provisioning Profiles, digital certificates, or corresponding private keys.  The Licensee cannot provide or transfer Apple-issued digital certificates or Provisioning Profiles provided under the Program to any third party, except for a third party who is developing an Internal App on the company’s behalf.

Additional Functionality

The following sections describe terms that are specific to certain services available with the Apple Software that may be used to develop additional functionality in connection with a Licensee’s Internal Apps.

  • APN (Apple Push Notification service) or Local Notifications

If the Licensee’s Internal Apps send Push Notifications via the APN or Local Notifications, the Licensee must first obtain end-user consent prior to receiving such notifications.  The company cannot disable or interfere with any Apple implemented consent panels or any Apple system preferences for enabling or disabling Notifications functionality.  If an employee’s consent to receive Push Notifications is denied or later withdrawn, the company may not send that employee any further Push Notifications.  As a condition to using the APN or delivering Local Notifications, the company may not transmit sensitive personal or confidential information belonging to an individual (e.g., a social security number, financial account or transactional information, or any information where the individual may have a reasonable expectation of secure transmission) as part of any such notification.  Any Push Notifications that the Licensee sends via the APN, may be transmitted across various public networks, in various forms of media.

  • Mobile Device Management (MDM) Service

Like the Internal Apps themselves, the Licensee’s use of the MDM Service is solely for its internal, in-house management of employees’ Deployment Devices.  Before a company can use the MDM Service, it must install an MDM Profile on each iOS Product that will be managed under the MDM Service.  Use of the MDM Service requires the Licensee to maintain a secure server to interact with Apple’s APN server.  As part of the MDM Service, Apple will provide the Licensee with the “MDM Protocol”, which must be treated as Apple’s Confidential Information.

Prior to installation of the MDM Profiles, the Licensee must provide notice to its employees that it will be able to interact with their Deployment Devices remotely.  Such interaction includes: inspecting, installing, or removing profiles; viewing which Internal Apps are installed; using secure erase functions; and, enforcing device passcodes.  All information that the Licensee obtains through the use of the MDM Service may only be used for the company’s internal information technology and device management purposes; such as, locking the device for security purposes, or remotely wiping a lost device.

  • iCloud Storage

The Licensee’s use of the iCloud Storage APIs and the iCloud service is governed by additional terms governing the iCloud service for software development and testing in connection with the Licensee’s Internal Apps.  Most importantly, the Licensee’s Internal Apps are only permitted to use the iCloud service and the iCloud Storage APIs for the purpose of (1) storage and retrieval of key value data (e.g., a list of stocks in a finance App) for Internal Apps, and (2) allowing its employees to access user-generated documents and files through the iCloud service.

  • Passbook

The Licensee’s development of Passes, and use of Pass IDs, must be in accordance with the terms of the License and the Additional Terms for Passes.  “Pass(es)” are one or more digital passes (e.g., movie tickets, coupons, loyalty reward vouchers, boarding passes, membership cards, etc.) developed by the company, under the company’s trademark or brand, and which are signed with the company’s Pass ID.  A “Pass ID” means the combination of an Apple-issued certificate and Push Application ID that is used to sign the company’s Passes and/or communicate with the APN.

The Licensee may only use the Pass ID for purposes of digitally signing Passes and/or for purposes of using the APN service with Passes.  The Licensee is limited to distributing Passes only to its employees for internal purposes.  Passes may only operate and be displayed in Passbook, which is Apple’s designated container area for the Pass, or through Passbook on the lock screen of an iOS Product.  Within the Passes, the Licensee must state its name and address, and the contact information to which any employee questions, complaints, or claims with respect to its Passes should be directed.  Apple reserves the right to review and approve or reject any Pass that the company intends to distribute for use by its employees.

  • Twitter

If the Licensee’s Internal Apps access the Twitter service through the Twitter API, such access is subject to Twitter’s terms of service (http://dev.twitter.com).

  • Address Book

If the Licensee’s Internal Apps access data from an employee’s Address Book through the Address Book API, then the Licensee must notify and obtain consent from the user before his or her Address Book data is accessed or used by the Internal App.

To be Continued…

In the third and final part of this three-part post, I will address the terms governing app deployment, as well as the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.  Stay tuned!