Summary

  • Balsam obtained a USD 1.125 million default judgment after alleging 1,125 unlawful commercial emails, but he could not identify or collect from the operator behind the domain.
  • The Ninth Circuit held that RAA paragraph 3.7.7.3 was a term registrars had to place in a separate registration agreement, while paragraph 5.10 denied third parties an enforcement right under the RAA itself.
  • The judgment resolved Balsam's third-party-beneficiary theory. It did not decide that disclosure was undesirable, that the proxy clause had been performed, or that ICANN lacked authority to enforce its own contract.

A judgment without a usable target

The awkward fact at the centre of Balsam v Tucows was not the absence of a legal win. Daniel Balsam already had one. The Ninth Circuit's opinion records that he claimed to have received 1,125 unsolicited commercial emails between October 2005 and May 2006. In March 2008, a federal court entered a USD 1,125,000 default judgment against Angeles Technology.

The judgment did not make Angeles easy to find or the award easy to collect. The registration database had initially listed Tucows as registrar and Angeles as the registered holder of adultactioncam.com. The appellate opinion says that Angeles apparently later opted into Tucows's Contact Privacy feature. Balsam alleged that the privacy arrangement left Tucows or its affiliate in the public record while the customer retained use of the name.

That description matters, but so does its procedural status. It was Balsam's account of the proxy arrangement, recited on review of a dismissal. The Ninth Circuit did not conduct a trial into the service's complete technical design or decide every fact about who held which credential.

Balsam nevertheless saw an apparently direct route in the Registrar Accreditation Agreement between ICANN and Tucows. Paragraph 3.7.7.3 addressed a registered holder that licensed use of a name. In broad terms, it said that the holder accepted liability for wrongful use unless it promptly identified the licensee after receiving reasonable evidence of actionable harm.

With a default judgment in hand, Balsam demanded that Tucows identify the operator or pay the judgment. The economics of the demand were simple. The privacy system held the information he needed; the judgment remained with him; and the contract appeared to attach a consequence to non-disclosure.

The legal architecture was not simple at all.

One clause required another contract

The proxy language did not sit in the RAA as a freestanding promise by Tucows to every injured outsider. Paragraph 3.7.7 told the registrar to require each registered holder to enter a separate registration agreement containing specified provisions. Paragraph 3.7.7.3 was one of those required downstream provisions.

The distinction is easy to lose when one sentence is quoted without its parent clause. The RAA imposed a drafting obligation on the registrar: put this allocation of responsibility into the registrar–holder contract. The Ninth Circuit held that paragraph 3.7.7.3 was not itself an independent obligation binding ICANN or Tucows to Balsam under the accreditation agreement.

The court also read the instrument as a whole. Paragraph 5.10 was explicit: the agreement did not create an obligation by ICANN or the registrar to a non-party, including a registered holder. The ICANN archive identifies the 17 May 2001 RAA as the historical agreement form relevant to pre-2009 accreditations. A scanned copy is also preserved in ICANN's Pool.com litigation filing.

Balsam argued that the specific proxy clause should control over the general no-beneficiary clause. The court disagreed. It found no evidence that ICANN and Tucows intended the downstream-language requirement to give outsiders rights under the RAA. The disclaimer therefore did the work its wording promised: it kept non-parties from converting accreditation duties into their own contract claim.

There was a further limit. Balsam had acknowledged that all four causes of action—breach of contract, negligence, civil conspiracy and declaratory relief—depended on his status as a third-party beneficiary. Once that premise failed, the complaint had no independent route left. Dismissal with prejudice was affirmed.

What the opinion did not decide

The result is often compressed into the phrase “no disclosure duty.” That is too broad. The court did not hold that a registered holder could ignore paragraph 3.7.7.3. It held that Balsam could not enforce the RAA as a third-party beneficiary on the theory he pleaded.

The court noted that Balsam did not allege Tucows had failed to enter the required separate agreement with the registered holder. It therefore did not construe the complete downstream agreement, identify its intended beneficiaries, or decide whether its terms had been performed. A claim based on that separate contract would need its own text, parties, governing law and standing analysis.

Nor did the opinion strip ICANN of contractual power. ICANN was a party to the RAA; Balsam was not. A decision denying Balsam standing does not logically deny ICANN the rights it held under its own agreement. Whether ICANN should have acted, what evidence it possessed, and which compliance remedy was available were not adjudicated in this appeal.

The decision was also not a general judgment against protected identity services. It did not say disclosure was always harmful or always required. It did not decide that a default judgment against Angeles automatically established Tucows's liability. It decided who could invoke this agreement in this case.

ICANN's May 2010 draft advisory shows why that distinction mattered institutionally. The draft described the liability-or-identification structure but acknowledged that the RAA did not define “reasonable evidence of actionable harm” or “prompt” identification. It contemplated a court or arbitrator making those judgments.

The advisory was a draft, not binding law and not a finding against Tucows. Its discussion of a possible five-business-day guide must not be turned into a rule the Ninth Circuit adopted. What it does establish is that even ICANN's contemporaneous policy work recognised the missing decision layer between receiving evidence and assigning liability.

The enforcement gap was designed into the chain

The case placed cost and authority on different sides of the contract. Balsam bore the cost of unwanted email, litigation and non-collection. Tucows controlled registrar service and, on Balsam's allegations, the privacy-facing identity record. ICANN held accreditation enforcement rights. Courts controlled standing and compulsory process.

None of those positions was fictional. The problem was the hand-off. The clause appeared to address the injured party because it referred to evidence supplied by such a party. Yet the accreditation agreement did not appoint that person as an enforcer. A reader could be named in the operating logic of a rule while remaining outside the legal mechanism that made the rule enforceable.

That architecture protects legitimate interests. A registrar cannot safely reveal customer data whenever a claimant sends a threatening letter. Privacy customers need a threshold, notice and review. The no-beneficiary clause also protects ICANN's contractual system from thousands of private suits that could produce inconsistent interpretations.

But centralising enforcement has a price. ICANN and the registrar do not bear the claimant's uncollected judgment. If the authorised institution declines to act, delays, or provides no reasoned route for a third party to present evidence, the formal allocation of liability may exist without producing accountability for the person whose harm triggered it.

A bounded claimant procedure

The credible alternative is not automatic unmasking. It is a limited procedure that connects evidence to an authorised decision. A claimant would submit specified proof of actionable harm. The service would preserve relevant records, authenticate the request, and notify the customer unless notice created a documented preservation risk.

A short clock would lead to one of four outcomes: protected disclosure to an authorised recipient, refusal with reasons, a temporary preservation measure, or escalation to ICANN, a regulator or a court. The customer would have a defined opportunity to contest. The claimant would know which institution owned the next decision.

This design would not give outsiders a private cause of action under the RAA. It would make the institution that retains enforcement authority operate a reviewable channel. Privacy would remain a protected interest rather than becoming a procedural void.

Sources