Drafting a Privacy Policy? Beware!
by Eric Goldman, Esq.
Cooley Godward LLP
Privacy policies have recently become the drafting project du jour for cyberspace law practitioners. This new wave of enthusiasm can be attributed to at least three recent phenomena.
First, in June, the FTC released a report entitled “Privacy Online: A Report to Congress” <http://www.ftc.gov/reports/privacy3/toc.html>, proposing congressional regulation of the collection of information from children. The associated din from the press has been deafening.
Second, consumers seem to be increasingly aware and concerned about their lack of control over their online private information. Ironically, “off-line” risks (such as from magazines, charities and companies that request warranty registration cards) may be far higher but get far less press.
Finally, drafting a privacy policy has seemingly never been easier. TRUSTe <http://www.truste.org/>, an independent non-profit privacy initiative, has established a wizard <http://www.truste.org/wizard.html> that allows a website to automatically generate a turnkey privacy policy. The Direct Marketing Association has created a similar tool <http://www.the-dma.org/policy.html>. Yahoo <http://www.yahoo.com/docs/info/privacy.html>, Excite <http://www.excite.com/privacy_policy/> and other major sites have also recently launched comprehensive privacy policies which other websites are copying.
Unfortunately, drafting a privacy policy is like navigating a mine field—it can be done, but it requires extreme care. Special attention must be paid both to the substance of the policy and the procedure by which it is deployed. There are at least 8 “gotchas” awaiting every website considering instituting a privacy policy:
Beware Incomplete Due Diligence. Drafting a privacy policy requires a thorough examination of the website’s current and expected practices about collecting and using personal data. The engineering, customer service, marketing and legal departments all have relevant practices that need to be considered and reflected in a privacy policy (or, on occasion, corrected!). Unless a comprehensive analysis is done, the announced privacy practices will likely be incomplete or wrong. Further, as discussed below, it is difficult to legally amend the privacy policy, so the due diligence must be done upfront to avoid being legally locked in an inaccurate privacy policy.
Beware One-Way Binding Obligations. For reasons that are not entirely clear, most companies that have announced privacy policies are posting the policy to the website but not trying to use industry-standard practices to form an agreement with users. While there remains some doubt about the enforceability of mandatory clickthrough agreements, it remains the preferred way to try to form a user agreement online.
In contrast, to the extent that a privacy policy is not a mandatory clickthrough, it probably will not be treated as an agreement. If the privacy policy is not an agreement, then it probably cannot be enforced against users or act as a successful disclaimer or delimiter of rights. Nevertheless, users probably can enforce the privacy policy against the website, under theories such as fraudulent misrepresentation, unfair or deceptive trade practices, or possibly unilateral contract. Thus, in the situations where the privacy policy is not a mandatory clickthrough, the website is presented with the anomalous situation that the policy is probably not enforceable against users but is enforceable against the website—in other words, it has one-way binding legal effect.
There are possibly situations where the marketing benefits from a one-way privacy policy outweigh the legal perils, but a one-way policy will always be inadequate to the extent that legally binding consent from users is required (such as the ECPA or under the European privacy directive; see below).
Beware Absolute Guarantees. For maximum marketing benefit, websites like to make absolute statements regarding privacy. However, there are at least 3 unavoidable situations that preclude such guarantees.
First, since no security system is perfect, users’ privacy can be breached by hackers. For example, in 1995 Kevin Mitnick hacked into Netcom and stole a database containing over 20,000 user credit card numbers. Had Netcom promised that these numbers would never be disclosed to a third party, Netcom would have been in breach of its promise.
Second, rogue or malevolent employees can deliberately disclose personal information.
Third, well-meaning employees can “inadvertently” disclose information, such as has happened at AOL at least twice within the last year. First, an AOL employee, apparently unaware of AOL’s privacy policy and certainly in breach of it, disclosed personally identifiable information about a user (Navy officer Timothy McVeigh) to the Navy. McVeigh v. Cohen, 983 F. Supp. 215 (D.D.C. 1998). Second, AOL employees have been “conned” into disclosing or changing account passwords without proper authentication, allowing third parties to hijack accounts <http://www.news.com/News/Item/0,4,22512,00.html>. Indeed, customer support personnel are notoriously underpaid and inadequately trained, and thus will make mistakes.
These risks create serious problems for a claim such as “we never willfully disclose individually identifiable information about our customers to any third party without first receiving permission.” While a security hack probably does not breach this promise, disclosures by rogue employees and clueless/gullible employees could be a breach.
Beware the ECPA. Many websites are or may be subject to the Electronic Communications Privacy Act (the “ECPA”), 18 U.S.C. §§ 2510-2521 and 2701-2710. Generally, the ECPA regulates the interception of private communications and the accessing and disclosure of stored communications and associated transactional information. The ECPA is a complicated and poorly drafted statute, making compliance difficult, and violations can lead to both civil and criminal remedies. Therefore, entities that might be subject to the ECPA usually attempt to contractually waive application of the statute.
While there are no clear rules on how to effectively waive users’ ECPA rights, generally the ECPA focuses on users’ expectations of privacy. Therefore, a privacy policy that creates or reinforces user expectations of privacy does not mitigate the application of the statute (if anything, it might create a more solid grounds for an ECPA claim). To actually disclaim expectations of privacy, the privacy policy probably must be a clickthrough.
Beware the Kids. To the extent that any trends regarding the protection of user privacy have emerged, we have clearly seen that collection of data from children will be given special attention. In addition to the FTC’s call on Congress to regulate this (as mentioned above), there have been at least 2 well-publicized incidents in this area.
First, in 1997, the FTC considered bringing an enforcement action against KidsCom, a children-oriented website that collected information from children. Although the FTC decided not to bring an enforcement action <http://www.ftc.gov/os/9707/cenmed.htm>, to avoid the enforcement action, KidsCom made the following changes: (a) it emails parents when children register at the site, providing notice of its collection practices, and it gives parents the option to opt out of aggregated information disclosure to third parties, (b) it does not disclose personally identifiable information to third parties without prior parental approval which has been faxed or sent by regular mail, (c) it discloses to users the purposes for which information is collected, and (d) it distinguishes more explicitly between editorial content and advertising.
More recently, the FTC entered into a consent order with GeoCities regarding GeoCities’ collection and use of personal information <http://www.news.com/News/Item/0,4,23130,00.html>. The FTC accused GeoCities of disclosing members’ personal information to third parties in contravention of its stated practices, of failing to disclose how it would use member information (including information from children), and of implying an affiliation with a children’s club operated by a GeoCities “community leader” which led children to believe that they were supplying their personal information to GeoCities and not the leader. To avoid further action, GeoCities agreed to: (a) notify users about GeoCities’ information and disclosure practices, (b) provide users the ability to delete their personal information from GeoCities’ databases, (c) clearly identify its affiliation with third parties that may collect information or sponsor activities on GeoCities, and (d) obtain parental consent before collecting and using personal information obtained by children under 13.
While children deserve special protection, effectuating this is problematic for at least 2 reasons.
First, it is impractical to segregate children because there are few good ways to authenticate for age. Most sites do little or no authentication of their users generally, and even fewer authenticate for age (except for the pornography-oriented sites, many of whom now have affiliated with a pay adult verification system such as AdultCheck). As the U.S. Supreme Court stated in 1997, while websites can verify age using a credit card number or an adult password, due to expense and hassle such verification was effectively unavailable to a substantial number of websites. American Civil Liberties Union v. Reno, 117 S. Ct. 2329 (1997). Therefore, in other contexts websites have not been forced by the government to authenticate for age, and it is no more reasonable to do so in the privacy context.
However, as part of a registration process, many websites ask members their age. While this information is not authenticated, users who self-report their age as being below 18 presumably should be given special treatment. Because categorizing users imposes extra costs on the website, some websites will probably choose not to ask users their age to avoid putatively knowing about minors on the site.
Second, children are not capable of forming a legally binding contract. Therefore, while a user agreement may contain restrictions on use by children, under contract law this contract is not enforceable against the child. Ironically, most government entities have sought greater website disclosure directed to children, although presumably these same children cannot enter into a contract that would restrict their behavior on the website.
So what should a non-children-oriented website say in its privacy policy? (Compliance procedures for children-oriented websites are beyond the scope of this article). Informing children of a specified age that they must get parental consent before disclosing information has an uncertain legal effect, but it may be enough to satisfy the FTC. Telling children in the user agreement that they are not welcome to use the site at all may be legally more defensible, but if users are not authenticated, this restriction still rings hollow. Indeed, given the current state of technology, there are no ideal solutions to the problems of dealing with children online. Each website should give special consideration to this problem in light of its particular offerings and practices.
Beware the Europeans. Although there are few U.S. privacy laws on the books, the European Union has adopted the Council Directive 95/46/EC of 24 October 1995 on the Protection of Individuals with Regard to the Processing of Personal Data and on the Free Movement of Such Data <http://www.privacy.org/pi/intl_orgs/ec/dp_directive_final.txt> (the “Privacy Directive”). The Privacy Directive, scheduled to take full effect in October 1998, places meaningful restrictions on the collection and use of personal data (not just online, but as collected from all sources) and effectively requires express user consent in most situations before websites can legally collect and use such data. Many U.S. companies have chosen not to try to comply with the Privacy Directive, considering themselves outside the scope of the law. However, any company that has a connection to the European Union (such as a physical presence or substantial business in Europe) must consider the effects of the law and, in most cases, should comply with the law enterprise-wide.
Beware of Amending a Policy. When a privacy policy is a one-way binding document, there is some ambiguity about how to update it in a legally-effective way against all users. For example, if a website wants to embark on a new secondary use of data it collected, it could either: (a) update its privacy policy, but there is no guarantee that any of the subject users will see or know of this update (and, indeed, since there will be users who never return, these users presumably will never see the updated policy), or (b) make secondary use only of data of users who opt-in, which severely restricts the number of applicable users. Signatories of TRUSTe’s License Agreement <http://www.truste.org/webpublishers/legal.html> must do the latter.
To try to mitigate this problem, some sites announce that changes to the policy are automatically effective against users under specified circumstances. As discussed above, this is probably not legally binding against users in the one-way binding situation, and it may not comply with TRUSTe’s rules either.
If the privacy policy is part of a properly formed agreement with users, then the user agreement can specify procedures for amendments. In some cases, the stated amendment procedure places the burden on users to check a specified URL periodically for changes. It seems entirely possible that courts might deem this procedure unreasonable, in which case the amendments might not be honored by a court. The more prudent course of conduct is to provide notice of amendments to users that is likely to actually be seen (such as by email or through a mandatory clickthrough) and allow users to terminate their relationship if they disagree.
In any respect, if the website is a TRUSTe licensee, as mentioned above the website can only expand its use of personally identifiable information with user consent. Assuming that some users will not consent (either because they say no or because they do not respond), a website faces the prospect of having groups of users whose data must be treated in accordance with the “old rules.” This imposes significant costs on the website to track these users and retain multiple data use and disclosure rules. Therefore, before a website promulgates a “restrictive” privacy policy, the website must either ensure that it will never want broader rights or be prepared to incur the costs of having multiple classes of users in the future. Alternatively, a website has significant incentive to initially promulgate a “permissive” privacy policy, since it will be easier to make the policy more restrictive in the future than to make it more permissive.
Beware Contrary Statements on the Website. Whether a privacy policy is done as a one-way binding policy or as a user agreement that is intended to be an integrated agreement, the website should centralize all privacy-related provisions in one place and remove other statements that are sprinkled throughout the website. Contrary statements elsewhere on the site could be express representations that are actionable. This is especially true if the contrary statements are more restrictive than the privacy policy. Therefore, it is a good idea to do a comprehensive scrub of the website when launching a privacy policy and remove or conform all inconsistent statements.
Conclusion. There are great marketing benefits associated with announcing a privacy policy, and the associated consumer goodwill can reinforce a website’s relationship with its customers. Further, if collectively the web industry can show sufficient progress towards self-regulation, industry may be able to forestall the imposition of unfavorable regulation.
However, considerable thought and care must be devoted to preparing a privacy policy that does not create enormous liability for the website. Drafters should proceed with caution to ensure that the website meets both its short-term marketing objectives and long-term risk management and business development objectives.
About the author: Eric Goldman (formerly Eric Schlachter) is an attorney practicing cyberspace law with Cooley Godward LLP, Palo Alto, CA. He also is an adjunct professor of Cyberspace Law at Santa Clara University School of Law. Cooley Godward’s web page is located at http://www.cooley.com, and Eric’s personal home page is located at http://eric_goldman.tripod.com/. Eric can be reached at ericgoldman@onebox.com.