Domain Name Privacy Protection Services Not Liable for Failure to Disclose Identity of Alleged Spammer — Balsam v. Tucows
[Post by Venkat]
Balsam v. Tucows, No. 09-17625 (9th Cir.; Dec. 16, 2010)
Prolific spam litigant Dan Balsam sued the registrant of [adultactioncam.com] under California’s spam statute for allegedly sending Balsam thousands of pieces of spam. Balsam obtained a default judgment in the amount of $1,125,000 (!) against Angeles Technology, Inc., who was listed as the registrant of [adultactioncam.com]. Balsam was ultimately unable to recover against Angeles and then sued Tucows. His beef with Tucows was that Tucows refused to turn over the identity of the registrant of [adultactioncam.com] (when he conducted his initial search, apparently, Angeles was the registrant, but at some point later, Angeles opted into Tucows’ privacy protection services). He demanded that Tucows disclose the identity of the registrant “or pay the default judgment.” Tucows predictably refused, and Balsam sued, trying to hold Tucows liable. I should note that the court’s description of the facts is much better than mine, although it’s somewhat charitable to Balsam. The court concludes its recitation of facts by saying that “[a]lthough [Balsam’s] approach is novel and creative, it cannot survive a motion to dismiss.”
Balsam’s main argument is that Tucows as the registrar is bound by the ICANN registrar accreditation agreement, which contains the following provision (Sec. 220.127.116.11):
A Registered Name Holder licensing use of a Registered [domain] Name . . . shall accept liability for harm caused by wrongful use of the Registered Name, unless it promptly disclosed the identity of the licensee to a party providing the Registered Name Holder reasonable evidence of actionable harm.
As the court notes, Balsam’s claim against Tucows depends on his status as a third party beneficiary to the RAA agreement between ICANN and Tucows. The court concludes that Balsam is not a third party beneficiary because among other things, the agreement contains an explicit “no third party beneficiary clause,” and because the agreement itself does not contain terms applicable to ICANN or any registrar – it merely provides that a a registrar must include certain terms (including this one) in its domain name registration agreements. Balsam responded that the “no third party beneficiary” clause does not relieve Tucows of its obligation as a registrant (which it or one of its affiliated entities is in name when it provides privacy protection services) but the court rejects this argument as well. Tucows entered into the agreement as a registrar, and didn’t agree to bind itself as a registrant.
Balsam has an uphill battle arguing that the RAA creates third party rights. See Register.com v. Verio, 356 F.3d 393 (2d Cir. 2004.) (Interestingly, Register v. Verio dealt with the use of WHOIS information where Verio sent unsolicited emails to Register registered domain names advertising Verio’s services.) However, more relevant to the court’s discussion is a recent case involving proxy registration services – Solid Host v. NameCheap – where the court found that NameCheap could be held liable for contributory cybersquatting based on the actions of the registrant-in-fact. Here’s Prof. Goldman’s post on the muddled ruling in that case: “Contributory Cybersquatting and the Impending Demise of Domain Name Proxy Services?–Solid Host v. NameCheap.” As he mentions in that post, it’s important to be clear about who is the registrar and registrant (and in what capacity a particular entity is acting when it’s providing services). He raises the issue of whether registrars will shy away from providing privacy protection services. I don’t know the answer to that, and although it may be early to assess the fallout (if any) of the NameCheap case, this case seems to indicate that proxy registrars don’t roll over and readily disclose registrant information absent a court order.
In any event, I don’t think Balsam had a strong argument here since Angeles’s utilization of the privacy protection services did not contribute in any way to the alleged harm. Although the facts aren’t crystal clear, it seemed like Balsam obtained a judgment (after having determined that Angeles was the registrant) and only then did Angeles opt in to the privacy protection feature. The damage (if any) was done by the time the privacy protection feature entered into the picture. Additionally, as the district court’s order notes, the Angeles lawsuit was pending at the time Tucows declined to reveal the underlying registration info – Balsam had an obvious solution (which he failed to take advantage of). He could have issued a subpoena seeking the registrant information and could have easily obtained it. There may be some set of facts under which a refusal to reveal the registrant information could support a claim, but those facts were not present here.
This also raises the issue of the appropriate response from a company who provides private registration services. The registrars have an interest in not freely disclosing registrant information absent a court order, but NameCheap suggests that in some cases, a failure to disclose may result in liability to the provider of privacy protection services. (NameCheap raised the issue of whether the registrar was acting in its capacity as registrar or in another capacity – in its capacity as registrar, it may be able to take advantage of an ACPA safe harbor. As I mentioned in my previous post about this case, Tucows may have been able to take advantage of a Section 230 defense, although ultimately it didn’t end up needing to invoke the protections of Section 230, given the court’s ruling.) This case indicates that courts are reluctant to freely impose liability on a registrar who provides proxy registration services, which isn’t necessarily a bad thing from the standpoint of protecting registrant anonymity and privacy. A finding of possible liability in this case could have resulted in registrars getting more nervous when they receive requests for the identity of the underlying registrant.