Info Law Group : Technology Lawyers & Attorneys : Information Law Group : Privacy, Security & Intellectual Property Law

Cookies Everywhere

“Cookies,” small text files that a website automatically places on a visitor’s computer when the website is loaded, are ubiquitous on the Web. Session cookies track a user’s activity from page to page during a session, so that the user does not have to re-enter information or selections. Authentication cookies store logon credentials so that the user does not have to log on again after navigating to another website. Persistent cookies store user preferences for each successive visit to the website.

Tracking cookies may be used to collect analytic data on how an individual website is used, and some kinds of tracking cookies record the user’s activity across websites – which is more controversial from a privacy perspective. For example, “conversion tracking cookies” allow an advertiser to determine whether a user who clicks on a third-party advertising link ends up making an online purchase from the advertiser. Some behavioral marketing programs use cookies to collect information about the pages and sites visited by a consumer so that a profile can be constructed for targeted marketing purposes. Google Analytics uses cookies to create statistical reports for advertisers and website operators, without identifying the individual users other than by IP address.

The ePrivacy Directive

The European Union’s Privacy and Electronic Communications Directive (the “ePrivacy Directive”) essentially required transparency concerning cookies. Website visitors were to be informed about the website operator’s practices and available options to refuse or delete cookies. This has been the standard for website operators and advertisers since 2002.

In November 2009, the ePrivacy Directive was modified by amendments that included a revised Article 5(3) emphasizing the need for informed consent:

Member States shall ensure that the storing of or access to information already stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information in accordance with Directive 95/46/EC [the EU Data Protection Directive], inter alia about the purposes of the processing.

There is an exception for storage or access that is “strictly necessary” to provide an explicitly requested service.

The UK Response

Member States were required to transpose the amendments into national law in 18 months. This explains the timing for the revision of Regulation 6 of the UK Privacy and Electronic Communications Regulations 2003 (“PERC”), which will require after May 25 that the user “has given his or her consent” to storing or accessing information on the user’s equipment.

ICO’s announcement this week concerning the rule change raises as many questions as it answers, and the announcement itself states that ICO will issue separate guidance on how it intends to enforce PERC with respect to cookies.

Key Issues

• ICO expects that the more intrusive cookies (such as those that create profiles of users, especially across multiple websites) will require more explanation and well-documented consent. Conversion tracking and behavioral marketing uses of cookies are clearly in the crosshairs.

• The recitals to the amended ePrivacy Directive discuss the possibility of relying on the user’s browser settings to accept or reject cookies. ICO rejects this as a current solution, however, given the variety of browsers and settings in use, their unfamiliarity to many users, and the increasing use of mobile devices to access websites.

• ICO mentions several other possible ways of informing users about cookies and obtaining consent, such as highlighted or scrolling headers, footers, or splash screens; disclosures on pages requesting personal information or offering particular downloads such as videos; website terms and conditions or pop-ups that require a user to click “I agree” before proceeding; website “settings” that could be selected by a user once and then remembered (presumably using a cookie) for subsequent visits.

• ICO frankly acknowledges that third-party cookies may present the most challenging compliance issues and simply concludes that “everyone has a part to play in making sure that the user is aware of what is being collected and by whom.” An ICO spokesperson mentioned the possibility of establishing advertising network policies and procedures that could be viewed (and consented to?) by clicking on an icon displayed with banner ads and other advertising links.

• ICO says the exception for “strictly necessary” cookies will be interpreted narrowly. It gives one potential example: cookies used to keep track of a user’s purchases in a “shopping basket” until the user is ready to “check out” and pay for the purchases. ICO advises that it would not be acceptable to use cookies without consent simply to make the presentation of the website more attractive or collect statistics about the use of the website.

Implications for Website Operators

• Websites hosted in Europe are clearly subject to the new rules as they are implemented in each country this year. Data protection authorities and courts in some European countries may also assert that websites hosted elsewhere but targeting European residents should conform to the new cookie rules. When a company offers a UK or EU version of a website, for example, it may be required (or at least expected by users) to follow the EU rules.

• The trend toward requiring fuller disclosure and explicit consent, especially for behavioral tracking, is likely to be seen in the US as well, as suggested by the Federal Trade Commission’s December 2010 report on consumer privacy.

• Website operators should stay abreast of official interpretations and enforcement policies, such as those promised by ICO, that may offer more detailed guidance on cookie notices and consent mechanisms.

• It’s a good time to inventory your organization’s cookie practices, make sure they are fully disclosed in website privacy policies, and consider how to operationalize express consent requirements in Europe.  Watch how popular commercial websites in the UK adapt to the new rules.  (Right now, even the privacy policy on ICO's website would be inadequate!)

• Contracts with third-party advertisers, advertising networks, providers of website and browsing statistics, and business partners involved in co-branded websites should clearly delineate who is responsible for providing cookie notices and obtaining (and preserving evidence of) consent where required.

The goal in revising EU data protection rules (which also apply to members of the European Economic Area) is to facilitate the establishment of clear and consistent data protection requirements as well as to modernize Europe’s data protection laws to meet the challenges raised by new technologies (e.g., behavioral tracking) and globalization. Europe's data protection laws are currently based in large part on the 1995 EU Data Protection Directive.

The Commission’s announcement comes on the heels of the Data Protection Commissioners Conference in Jerusalem, during which many participants highlighted the need to bring data protection legislation up to date, and raised concerns about inconsistent and complex data protection requirements in various countries (including among EU member states).

The Commission’s strategy to revise data protection rules is based on the goals of:

• Limiting the collection and use of personal data to the minimum necessary;
• Transparency as to how, why, by whom and for how long personal data is collected and used;
• Informed consent;
• Right to be forgotten;
• Reducing administrative compliance burdens on businesses;
• Uniform implementation of data protection rules in EU member states;
• Improving and streamlining procedures for data transfers outside the EU;
• Cooperation with countries outside the EU and promotion of high standards of data protection at a global level;
• Strengthening enforcement of data protection rules by harmonizing the role and power of national data protection authorities;
• Facilitating consistent enforcement of data protection laws across the EU; and
• Implementing coherent rules for the protection of personal data in the fields of police and criminal justice.

Notably, many of these goals were announced at the Jerusalem conference.

The Commission’s review will serve as the basis for further discussions of data protection rules and, ultimately, new legislation, which the Commission expects to propose in 2011.

Please see the Commission’s press release, FAQs, and the strategy document for more details. The Commission is encouraging organizations and individuals to submit comments.

Stay tuned for more about the proposed revisions.

I reported in February about the European Union adopting a new set of SCCs to legitimize the transfer of European personal data to foreign processors. From May 15 onward, the new SCCs must be used unless there is another legal basis for the transfers, such as the EU-US “Safe Harbor” program.

Here is a summary of the impact of this EU decision, in the form of FAQs:

Why Use Standard Contract Clauses?

The EU Data Protection Directive requires national authorities to forbid the transfer of personal information to countries outside the European Economic Area (EEA) unless the data will be adequately protected by law or a specific derogation, such as approved SCCs or the individual’s informed consent, applies.

The United States, India, China, the Philippines, Jamaica, South Africa, and other common destinations for outsourced data services do not have similar data protection laws and are not deemed to provide an “adequate level of protection.” US companies that participate in the “Safe Harbor” framework for handling European personal data in the US, or sending it onward for processing in a third country, are treated as offering adequate protection. So are multinationals that implement Binding Corporate Rules (“BCRs”) approved by each of the relevant European countries for data transfers within a corporate group. But apart from transfers to Safe Harbor companies or in certain narrow contexts such as express consent or BCRs, offshoring arrangements involving personal data typically do not comply with European national data protection laws unless the company in Europe enters into a contract with the foreign vendor that includes EU-approved SCCs.

(It is also possible to seek approval from each relevant country for a unique set of contractual clauses, but this is an uncertain and time-consuming alternative that few organizations pursue.)

There are good reasons for a US company to consider Safe Harbor or BCRs, although these are beyond the scope of this article. But in any event, there will almost certainly be contexts in which neither Safe Harbor nor BCRs will cover all the data transfers that the company requires, such as data transfers outside the corporate group or directly from Europe to vendors outside the United States. In those cases, SCCs will typically be required.

What Countries Accept the EU SCCs?

EU-approved SCCs are ostensibly a passport for personal data from all 27 EU member states plus the other three EEA countries – Iceland, Liechtenstein, and Norway. However, one EU member state, Hungary, has not yet conformed its national law to routinely allow data transfers based on SCCs (or on Safe Harbor or BCRs, for that matter); individual consent is still required in most cases in Hungary.

Outside the EEA, Switzerland and Israel, which have similar data protection regimes, allow the transfer of personal data abroad if the companies use EU-approved SCCs. There are also instances where other non-EEA countries, such as Russia, have approved data transfers under contracts employing the EU SCCs, on a case-by-case basis.

This does not mean that a company can sign an agreement including, or annexing, SCCs and just start transferring personal data to an affiliate or vendor in the US or India. Unlike transfers to “adequate” countries such as Canada or to US Safe Harbor companies, data transfers under SCCs require notification to the data protection authorities (DPAs) in many European countries, and in some countries the transaction must await prior approval by the local DPA. In the UK, notice is effected simply by checking a box on an online registration form. In France, Spain, or The Netherlands, on the other hand, the European company must submit details and await an official response. In Germany, the internal data protection officer must approve the transfers, and approval may also be required from a works council or labor union if the outsourcing involves employee data.

If a company does not vary from the text of the EU SCCs and attaches a satisfactorily detailed annex describing the data transfers, including any special provisions for protecting sensitive categories of personal information, authorization should be forthcoming. But authorization often takes as long as three or four months in some countries. This should be factored into project and contract timing.

What Do the SCCs Provide?

One of two different versions of EU-approved “controller-controller” SCCs must be used if the data controller in Europe is transferring personal data to a foreign data controller, such as a parent, affiliate, or business partner that will make its own use of the data. For transfers to a processor that is merely handling the data on behalf of a European data controller, the newly adopted version of “controller-processor” SCCs must be employed.

The SCCs, which must be made available to the authorities and affected individuals on request, identify the “data exporter” in Europe and the “data importer” overseas. In contracts with processors, the processor must agree to follow the instructions of the data controller and maintain the confidentiality and security of the data. In the case of contracts between data controllers, each of which can use the data for its own purposes, the relevant SCCs allow the parties to select the governing European data protection law or a minimum set of data privacy principles.

SCCs provide for third-party beneficiary liability to the affected individuals and allow the data exporter to terminate the entire data transfer agreement if the data importer fails to comply with the SCCs. The SCCs also require the parties to annex a description of the covered data transfers in a prescribed format.

What’s Different about the New Processing SCCs?

The chief difference between the new controller-processor SCCs and the prior version published in 2001 is that the new SCCs take account of the trends to subcontract storage, technical support, or specific processing functions to third parties. When such “subprocessing” is contemplated, the new SCCs require the vendor to obtain the customer’s consent to subprocessing and execute written agreements with the subprocessors placing them under the same obligations to protect the personal data. The customer is also required to maintain a list of such subprocessing agreements and make it available on request to the data protection authorities, who may audit any subprocessing.

Here are some examples where these changes will typically involve more investigation and documentation than previously:

• An outsourcing vendor in the US plans to have some contracted functions performed by its affiliates in India or China.

• A cloud computing vendor aggregates services and hosting provided by a network of third parties.

• A parent company in the US, which has been providing technical support to European affiliates under SCCs, plans to outsource some support functions to vendors.

Are Existing Vendor Contracts Grandfathered?

Yes. Contracts in place before May 15, using the older version of EU-approved processing SCCs, may continue without revision until they expire, or until the nature of the data transfers changes materially or the vendor seeks to add a subprocessor.

Should We Use the Controller or Processor SCCs?

Sometimes it’s hard to tell which SCCs to use, because it is a factual question whether the data importer is in some respects acting as a controller of the data as opposed to acting as a mere processor. Simply saying in the contract that the data importer is only a processor may not preclude a different opinion by the authorities or the courts.

A parent company in the US, for example, may support global communications and ERM functions on behalf of its European subsidiaries, similar to what an unrelated outsourcing vendor might provide. But if the US parent also has access to the European data for its own purposes – such as corporate planning, career development and succession planning, and perhaps global insurance, audit, or legal functions – the US parent looks more like a data controller with respect to those purposes. Thus, a US parent company might be viewed as both a controller and a processor of European data.

Similarly, a global company may retain a benefits provider, perhaps to manage an employee stock option program or administer a pension fund. To the extent that the benefits provider simply performs functions at the employer’s behest, it appears to be a processor. But if the benefits provider also markets and provides additional services directly to the employees, it seems to be taking on the role of a controller.

In most European countries, the parties could safely rely on the controller-controller SCCs in such cases of mixed use. However, DPAs (especially in Greece) sometimes insist on separating the functions and require the data importer to sign two SCCs, one as a controller and the other as a processor. European Commission staff reports have occasionally noted the potential ambiguities in this, and other, applications of the controller and processor concepts, but as yet there is not a uniform and predictable approach to the problem.

The EU Data Protection Directive primarily regulates data controllers. A controller is defined in Article 2 of the Directive as the natural or legal person or public agency that “alone or jointly with others” determines “the purposes and means of processing” personal data. A processor is a natural or legal person or agency that processes data on behalf of a controller. “Processing” is defined very broadly in the Directive to include collection, use, storage, manipulation, disclosure, disposal, and virtually any other action with personal data. A controller can decide either to process personal data itself or delegate some or all processing activities to a processor. International data transfer agreements using SCCs always involve a data controller in Europe transferring personal data to either a controller or processor abroad.

In February, the Article 29 Data Protection Working Party, comprised of data protection officials from the European Commission and each of the member states, issued Opinion 1/2010 on the concepts of “controller” and “processor.” The concepts are important, of course, not only in choosing which SCCs to use in international transfers, but more importantly in deciding who has ultimate responsibility for protecting and properly using personal data, and which country’s law applies.

The Article 29 Working Party Opinion identifies controllers as the entities that decide to have some personal data processed for their own purposes. It recognizes that multiple parties (such as a parent company and its affiliates or business partners) may collectively decide which data elements are needed and how they will be handled. They need not have equal voices in those decisions, and their respective responsibility and liability may be limited to their own decisions. The Working Party also concluded that a processor may have some discretion in determining “the most suitable technical and organizational means” to accomplish delegated processing, without becoming a controller.

The Opinion, in my view, supports the conclusions that many global companies have reached, that parent and affiliate companies in a group usually should be considered joint controllers of employee and customer data used for a variety of purposes within the group, and that third-party outsourcing vendors remain merely processors even if they propose and implement decisions about the means of processing, based on their expertise. When struggling with the controller/processor distinction, organizations should ask the basic questions, “who wants this personal data, and why?” as a guide to recognizing who is ultimately responsible for the data and who is merely crunching it on their behalf. Among other things, the answers to those questions will determine which set of SCCs to use for international data transfers.
 

What is Cloud Computing?

How about a picture to start off:

The National Institute of Standards and Technology (NIST) has provided a definition of cloud computing that is helpful, but not really in plain English.  Moreover, it does not really help to illuminate the legal aspects of cloud computing. So here is my attempt.

From a user's perspective, when utilizing cloud computing, rather than data processing and storage occurring on an individual's laptop or desktop computer (or a company's internal network), it happens on computing platforms run by third parties (such as Google, Yahoo, Amazon, etc). Services that may be available through those cloud platforms include data storage (e.g., infrastructure as a service (IaaS)), application development/deployment  (platform as a service (PaaS) and software hosting (e.g., software as a service (SaaS)). So rather than store data on an organization's own computer network, if purchasing IaaS, the data is stored on servers "in the cloud" and available on demand by the organization. Rather than installing and maintaining data/software on a network or desktop computer, the data/application is hosted on computers in the cloud and available on demand.

This can result in cost savings because companies using cloud services need not purchase their own infrastructure or software, need not hire people to maintain it, and need not regularly upgrade when necessary.  In addition, cloud computing is highly and cheaply scalable.  So rather than maintaining an over-capacity of computing power (e.g. extra servers only used for the holiday e-commerce rush) companies can maintain variable capacity levels to suit their immediate needs using the cloud.  Moreover, utilizing the cloud will allow companies to take advantage of the best and latest technology since they will not have to disassemble and rebuild their entire IT infrastructure in order to upgrade.  For more information on some of the technical aspects of cloud computing, please check out this white paper put out by Sun Microsystems.

That is all nice, and fairly understandable, but what IS the cloud? Right. Some analogies are in order. Think of airlines and how they sell seats. Sometimes seats are still available for a flight as the departure date gets closer and closer. From the airline's point of view it is better to sell those seats for a lower price then to let the plane take off with empty seats. As long as can sell the seat for a price that exceeds the cost of taking a passenger. Bring this same rationale to the e-commerce context. Amazon.com has huge server farms that can handle millions of transactions. During the 3 month holiday period its servers and processing abilities may be taxed to their limits because of high online sales volumes. Then of course, February rolls around and all those servers that hummed during the holiday season suddenly lay dormant. Yet Amazon still needs to maintain them so it can be ready for the next holiday rush. What to do? Rather than let that processing capacity go unused, why not sell it to third parties?  Allow an application service provider to host its application on Amazon's computers for a price. Allow an organization to store and process data on Amazon's servers.  In fact, since any additional funds received (above maintenance costs) are "gravy" perhaps Amazon could charge a lower price than other companies that provide capacity. This rationale can serve as a building block for companies to get into cloud computing.

The second rationale/building block is economies of scale. Going beyond the Amazon rationale of attempting to sell excess capacity that it had to have anyway, savvy IT companies began to realize that they could sell processing capacity as a business. In fact, computing processing prices have continued to drop more or less as predicted by Gordon Bell's corollary to Moore's Law. Beyond that, companies like Google have begun to realize that if they build massive server farms they can bring down their per unit of price for processing power even further. Moreover, with highly evolved technologies they realized they could create additional processing efficiencies and bring down the per unit price of processing even further. Based on these economies of scale, cloud platforms realized they could provide processing capabilities much cheaper than companies that did it all "in house."

Terrific, so how is this any different than a typical outsourcing relationship?  Why is this a Cloud? One of the key differences between a traditional outsourcing relationship and cloud computing is where the data resides or is processed.  For example, in the traditional outsourcing situation, a company looking to offload some of its data storage would create a dedicated data center and then sell the storage capacity to its clients.  The data center might be in another country, but for the most part the client knew where its data was going and where it would be stored and processed.

Enter the cloud.  In a cloud environment, geography can lose all meaning.  Cloud platforms may not be able to tell "where" data is at any given point in time.  Data may be dispersed across and stored in multiple data centers all over the world.  In fact, use of a cloud platform can result in multiple copies of data being stored in different locations.  This is true even for a "private cloud" that is essentially run by a single entity.  What this also means is that data in the cloud is often transferred across multiple borders, which (as discussed below) can have significant legal implications.

It gets more complicated when you begin talking about the "public cloud" or "hybrid cloud" and interactions between cloud providers.  In some public cloud set ups, the players in the cloud are essentially trading processing and storage capacity.  So if Google has excess capacity at a given point and time, and Amazon or Amazon's clients need more capacity than Amazon can provide, it can buy some capacity from Google.  Some refer to this as "surge computing." The analogy here is electricity companies and providers.  In warmer climates during peak electricity demand times, the local power company may not be able to generate enough electricity to meet increased demand, and will have to purchase it from other companies who are not at full capacity.  Under the cloud arrangement, data is like electricity, essentially fungible and able to be moved instantaneously to available servers and computation resources.  In fact, cloud computing providers will begin charging for the cloud the same way electricity is charged:  based on units of use (in this case computing cycles).  So in the cloud, while the data may have started out on an Amazon server in the European Union, when handed off to Google it may be processed in the United States, China or some other country where Google has servers (in fact countries like China and India are very keen to get into this business since they think they can provide these services for even cheaper).  Moreover, the parts of the data may be copied and sent for processing to other participants in the cloud.  To the Amazon user all of this movement of data and processing across multiple borders involving multiple entities and even multiple copies of data is invisible.  The Amazon user simply gets back the answer it expected when it began the processing transaction.

What are the legal issues?

Transborder Data Flow Triggering Legal Obligations in Multiple Jurisdictions. This sharing and transfer of data within the cloud, the inability for anybody to easily say where the data is or has been, is the key problem that creates legal issues.  An obvious problem is transborder data flow.  For example under the EU Data Protection Directive, unless they take certain steps, organizations are prohibited from transferring personal information to countries that do not provide the same level of protection with respect to personal information of EU residents (the United States is one such country).  A company that does its processing in the cloud may be violating EU law if data goes to servers outside of the EU to prohibited countries.  Unfortunately, contracts may not be too helpful because cloud providers will not be in any position to make any contractual promises to their clients because in many cases they cannot say which countries data will be transferred to or from.  So how can companies seeking the efficiency and cost savings of the cloud utilize it if, by its very nature, it leads to potential legal compliance nightmares?

"Reasonable Security" Under the Law. Then there is the issue of "reasonable security" in the cloud computing context, and potential liability arising out of security breaches in the cloud.  Generally speaking if a company outsources the handling of personal information to another company they may have some responsibility to make sure the outsourcer has some level of reasonable security to protect personal and confidential information.  What happens when the could is utilized? Service providers using the cloud platform essentially rely on the security of each of the cloud participants receiving personal information.  That could be name brand companies like Google who are likely to have some level of adequate security, but it could also be lesser players trying to engage in business as cheaply as possible and not implementing rigorous controls.  The bottom line again is that the organization seeking to do business in the cloud has no way to even perform a due diligence of "the cloud" to ensure that adequate security is in place.  Moreover, cloud companies and service providers that contract directly with such companies are not likely to make any contractual promises around security since they ultimately don't control it (or even know how good or bad it is within the cloud).  Ultimately, the legal question is, what liability does a company face when there has been a security breach in the cloud that has resulted in the theft or harm of valuable or protected data?

Electronic evidence/e-discovery. Utilizing the cloud can be problematic in the litigation context.  First off, when litigation ensues and a litigation hold is initiated, the organization will have to deal with a third party cloud provider in order to get at the information relevant to the litigation.  It may not be easy for that provider to actually preserve the data that is needed for several reasons.  For example, an organization may be using a third party software provider that itself utilizes the a cloud platform.  The data subject to the litigation hold therefore may actually reside in the cloud and may not be readily accessible/preserved by the software provider.  This could complicate gathering electronic evidence and responding to e-Discovery requests.  Moreover, it could lead to spoliation of evidence.  In addition, considering that multiple copies of data may be created, stored, recompiled, dispersed, reassembled and reused, the idea of what constitutes a "record" or a "document" for evidentiary purposes may be difficult to grapple with in the cloud.

What can lawyers do to address these issues?

Ultimately this is the big question.  Can the law wrap its head around cloud computing (when frankly, the cloud computing industry itself is having difficulty defining key components of the business)?  The first area to explore are contractual arrangements.  Lawyers have been involved in outsourcing transactions for sometime, and have been able to address issues of relative risk between the parties.  However, contracting may be much more difficult in the cloud environment because the players may not be in a position to make certain promises, and additional duties/obligations may destroy the cheap pricing model for cloud computing.  In part two of this series, we dive more deeply into the legal issues around cloud computing and the necessary involvement of lawyers in this context with respect to contractual arrangements.