Monthly Archives: July 2013

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.


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 (

  • 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!

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

The purpose of this three-part post is to provide an overview of the Apple iOS Developer Enterprise Program (the “Program”) from a legal perspective.  These posts should provide guidance to business-unit directors and their software developers as they prepare to distribute in-house, mobile applications on Apple-branded products running the iOS to their employees.  In this Part, I will highlight the general legal obligations and restrictions related to Apple’s iOS Developer Program Enterprise License Agreement (the “License”).  This part will focus only on the License as it relates to the use of the Apple Software.  In future posts, I will discuss how the License governs the subsequently developed apps and their deployment.

Ed g2s
Ed g2s

Overview: Apple’s iOS Developer Enterprise Program

The Program provides companies with tools to develop, test, and distribute proprietary, in-house iOS apps to employees and, under very limited circumstances, customers.  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 employees.  As a general rule, the Program is not intended for the creation of other apps that may be used, distributed, or otherwise made available to other companies, distributors, resellers, or members of the general public.

General Program Terms: The Apple Software

Before a company can begin developing Internal Apps using the Apple Software, it will have to accept the terms of the License. As defined by the license, “Apple Software” includes the Apple iOS, Provisioning Profiles, and the all-important Software Development Kit (“SDK”, i.e., the documentation, software, applications, sample code, simulator, tools, libraries, APIs, etc.).  The company (the “Licensee”) must be sure that the person accepting the License terms has the right and authority to enter into the License on behalf of his/her company.  For companies with multiple subsidiaries and affiliates, it is important to note that the License is both non-sublicensable and non-transferable.  Once the License is entered into, Apple grants the Licensee the right to (1) use Apple Software for developing and testing Internal Apps; and, (2) deploy their Internal Apps for the Licensee’s internal purposes.

While Apple grants a rather broad License for a nominal fee of $299, they at the same time, understandably, limit their liability.  Pursuant to the License, Apple is not obligated to provide any maintenance, technical, or other support for the Apple Software.  Of course, evidence suggests that Apple will continue (although not required) to provide software updates and patches.  Nevertheless, the Apple Software is provided “as is” and is not subject to a warranty of any kind.  As a result, Apple is not responsible for any costs or other losses the Licensee may incur as a result of its Internal App development, use of the Apple Software, or participation in the Program.

Who can use the Apple Software? 

The Apple Software may only be used by the Licensee’s Authorized Developers.  To be an “Authorized Developer”, the developer must: (1) be an employee or authorized contractor of the Licensee; (2) have a valid registered Apple Developer account with Apple; and, (3) have a “need to know” or “need to use” the Apple Software in order to develop and test Internal Apps.

How can the Apple Software be used?

Under the License, a company may use the Apple Software under the following circumstances:

1)      To install a reasonable number of copies of the Apple Software on Apple-branded computers owned or controlled by the Licensee, to be used internally by Authorized Developers for developing or testing Internal Apps.

2)      To make and distribute a reasonable number of copies of Apple’s documentation to Authorized Developers for the sole purpose of developing or testing Internal Apps.

3)      To install one copy of the iOS on each Authorized Test Devices, up to the number of Authorized Test Devices that the Licensee has acquired licenses for, to be used for developing and testing Internal Apps. “Authorized Test Devices” are iOS Products owned or controlled by the Licensee that have been designated for testing and development purposes under the Program and specifically registered with Apple for that purpose.

4)      To distribute Provisioning Profiles to the Licensee’s employees for the purpose of developing and testing Internal Apps.

5)      To distribute Provisioning Profiles to the Licensee’s employees in conjunction with the deployment of the Internal Apps on Deployment Devices for employees’ internal use. “Deployment Devices” collectively means Authorized Test Devices and other iOS Products owned or controlled by the Licensee.

In exchange for these rights, the Licensee must make a number of representations.  The following are those representations that really should be communicated to the company’s project team while developing and deploying Internal Apps.

  • The Licensee must monitor and be responsible for its employees’ use of the Apple Software, Authorized Test Devices, and other Deployment Devices.
  • The Licensee must monitor and be responsible for use of the Internal Apps by its employees.
  • The Licensee’s Internal Apps must not violate, misappropriate, or infringe any Apple or third-party intellectual property rights.
  • The Licensee must indemnify Apple for any claim against Apple arising from its breach of the License, infringement of a third-party’s intellectual property, or use of the Apple Software.

In addition to these reps, the Licensee must adhere to a number of restrictions over its use of the Apple Software.  First, the Licensee may not install, use or, run the SDK on any non-Apple-branded computer.  Second, the Licensee may not install, use, or run the iOS and Provisioning Profiles on or in connection with devices other than Deployment Devices.  Lastly, the License does not allow the Licensee to use Apple’s trademarks or logos.  If the Licensee wishes to make reference to any Apple products or otherwise use Apple’s trademarks, then it must comply with Apple’s published guidelines for such use.

A Quick Note on Intellectual Property

Under the License, Apple of course retains ownership in all Apple Software.  The Licensee, on the other hand, retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Even though the Licensee retains all ownership and interest in its Internal Apps, 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 its Internal Apps.  As such, Apple may use and disclose any such information on an unrestricted basis without notifying the Licensee.

To be Continued…

Part 2 will continue by describing the terms under the License that govern the apps developed and built on the Apple Software.  Finally, in Part 3, the terms governing app deployment will be addressed, as well as the unique requirements related to Apple’s Pre-release Software.