Резюме

  • 26 августа 2008 года федеральный суд обязал eNom вернуть solidhost.com компании Solid Host и предписалNamecheap, Inc.сотрудничать. Как зафиксировано вболее позднем постановлении суда, eNom восстановила технический контроль в тот же день; Namecheap раскрыла личность клиента, скрытого за услугой конфиденциальности, адвокатам 4 сентября. Восстановление и раскрытие были разными средствами защиты, которые применялись разными участниками в разные даты.
  • Майское постановление 2009 годане устанавливало, что предполагаемая кража произошла или что Namecheap несёт ответственность. Суд отклонил прямой иск по Закону о защите потребителей от киберсквоттинга из-за отсутствия недобросовестного умысла в отношении конкретного знака, но разрешил продолжить разбирательство по теориям о содействии киберсквоттингу и о нижестоящих договорных обязательствах на этапе ходатайства о прекращении дела. Позднее решения Девятого округа резко ограничили оба пути:Balsam v. Tucowsустановил, что Соглашение об аккредитации регистраторов само по себе не даёт частным истцам прав, защищаемых в судебном порядке, аPetronas v. GoDaddy.comустановил, что ACPA не создаёт ответственности за содействие киберсквоттингу.
  • Дело остаётся институционально важным, поскольку утверждалось, что Namecheap одновременно занимала три позиции: отображаемый регистрант, хранитель личности клиента и посредник, способный помочь обратить утрату контроля. Работоспособный режим уведомлений о краже должен привязывать обязанности к этим возможностям, сохранять доказательства до их исчезновения, использовать обратимые приостановки до необратимого раскрытия информации или передачи домена и создавать одно мотивированное решение, обязательное для реселлера и спонсирующего регистратора.

Два средства защиты с разницей в девять дней

26 августа 2008 года федеральный суд обязал eNom вернуть solidhost.com компании Solid Host, предписал Namecheap сотрудничать и сделал Namecheap запасным передающим лицом, если eNom не выполнит требование. eNom восстановила контроль над доменом в тот же день. Namecheap раскрыла личность клиента, скрытого за услугой конфиденциальности, адвокатам Solid Host 4 сентября. Эти события, изложенные вмайском постановлении 2009 года Центрального округа Калифорнии, не были единым средством защиты. Первое изменило то, кто может управлять именем. Второе показало, кого скрывала служба конфиденциальности. Они произошли с разницей в девять дней, через разные полномочия и после разных форм принуждения.

Эта последовательность — самый полезный вход в спор, потому что слово «раскрытие» может создать впечатление, будто дело было спором о конфиденциальности, в котором решался лишь вопрос, должен ли провайдер назвать клиента. Личность имела значение. Она могла помочь с формулированием иска, вручением документов, взысканием и привлечением к ответственности. Но она не вернула домен в руки Solid Host. Техническое средство защиты появилось из приказа, направленного на точку контроля, обращённую к регистратору. Именно eNom, а не само раскрытие, изменила операционное состояние.

Это различие предотвращает и противоположную ошибку: считать Namecheap не имеющей значения лишь потому, что, по утверждениям, она не была спонсирующим регистратором solidhost.com. Согласно иску в изложении суда, сервис Namecheap WhoisGuard фигурировал в публичной регистрационной записи, хранил за ней данные клиента, взаимодействовал с лицом, контролирующим имя, и мог сотрудничать при передаче домена. Суд не принял, что ярлыки «реселлер» и «сервис конфиденциальности» закрывают вопрос.

Суд спросил, какие функции, по утверждениям, выполняла Namecheap и выводили ли эти функции её за пределы основной деятельности регистратора, защищённой положениями о безопасной гавани.

Официальный судебный архивсохраняет это производство как дело об институциональном пересечении, а не как простой двусторонний спор о праве собственности. Solid Host утверждала, что имя было похищено. Неизвестный пользователь утверждал, что приобрёл его законно. Namecheap находилась между истцом и пользователем. eNom находилась между уровнем реселлера и реестром. Договор об аккредитации ICANN содержал формулировки о зарегистрированных держателях, которые лицензируют использование имени другим лицам, но договор также лишал третьих лиц права требовать исполнения. В этой записи федеральный суд был институтом, способным издать приказ, которому соответствующие частные участники были обязаны подчиняться.

Поэтому главный управленческий вопрос не в том, должен ли каждый сервис конфиденциальности раскрывать каждого клиента при обвинении. Он в том, может ли посредник накапливать видимое право на имя, скрытую личность и путь к техническому восстановлению, но при этом считать каждую функцию чужой ответственностью, когда поступает уведомление о краже, подтверждённое под присягой. Solid Host пыталась сделать такое накопление юридически значимым. Окружной суд разрешил продолжить часть этой попытки, но сделал это на промежуточной стадии, на основе заявленных утверждений, до того, как Девятый округ сузил доступные доктрины.

Предполагаемый угон и созданное им статус-кво

Фактические обстоятельства оставались утверждениями, а не выводами суда по итогам разбирательства.Майское постановление 2009 годагласило, что Solid Host, хостинг-компания из Нидерландов, утверждала, что использовала solidhost.com в своей деятельности и что имя было зарегистрировано через eNom. Согласно иску, 4 августа 2008 года неизвестное лицо получило логин и пароль от соответствующей учётной записи eNom, перенесло домен в другую учётную запись eNom и изменило настройки системы доменных имён так, что посетители попадали на страницу, контролируемую этим неизвестным лицом. После этого владелец Solid Host не мог изменять настройки интернет-протокола имени.

Предполагаемый злоумышленник не просто скрылся.В иске, как его пересказал суд, говорилось, что это лицо предложило продать домен обратно за 12 000 долларов банковским переводом. Это утверждение имело значение для заявленной теории киберсквоттинга, поскольку давало возможный мотив получения прибыли, связанный с именем. Оно также создавало острую проблему непрерывности. Чем дольше контроль оставался у другого лица, тем дольше адрес бизнеса, трафик клиентов и репутация оставались открытыми для решений другого оператора. Поэтому спор о краже домена касается не только права собственности. Он касается того, какая сторона несёт операционные потери, пока институты решают, чья версия правдива.

Адвокаты Solid Host связались с Namecheap 8 августаи попросили предоставить личность клиента и помощь в восстановлении домена. В постановлении говорится, что адвокаты Namecheap запросили доказательства, что Solid Host предоставила материалы, включая заявление владельца под присягой, и что Namecheap связалась с клиентом. Клиент, как сообщалось, утверждал, что домен был куплен законно. Solid Host отрицала какую-либо продажу. Затем Namecheap заявила, что останется нейтральной, и отказалась добровольно раскрыть личность.

Нейтральность в такой ситуации не была отсутствием решения. Она сохраняла состояние, возникшее в результате спорного переноса учётной записи. Это могло быть оправдано как осторожность против частного вынесения решения на неполных доказательствах. Но это всё равно был выбор относительно того, кто сохранит выгоду от статус-кво. Когда у сервиса нет полномочий изменить этот статус-кво, нейтральность может просто описывать неспособность.

Когда он может связываться с клиентом, сохранять журналы, накладывать блокировку учётной записи, предоставлять информацию в рамках законной процедуры или сотрудничать со спонсирующим регистратором, нейтральность описывает, как эти полномочия будут использованы или удержаны.

Публичная запись не содержит полного внутреннего файла доказательств Namecheap. Она не показывает каждый документ, предоставленный Solid Host, каждую проверку истории учётной записи или полный ответ клиента. Она не устанавливает, была ли блокировка передачи технически или договорно доступна до вмешательства суда. Она также не показывает, получил ли клиент значимую возможность оспорить доказательства до раскрытия. Эти пробелы не второстепенны. Они не позволяют задним числом заключить, что Namecheap должна была принять версию Solid Host 8 августа.

Институциональная критика уже: доступный процесс оставил истца без мотивированного и обязательного решения, а реселлер и регистратор могли оставаться в отдельных процедурных отсеках, пока суд не объединил их.

Solid Host добивалась такого объединения через ходатайство о временном запретительном приказе, поданное в порядке ex parte. Суд удовлетворил ходатайство 26 августа. Его приказ требовал от eNom передать домен обратно, обязывал Namecheap сотрудничать и предписывал Namecheap осуществить передачу, если eNom не выполнит требование. eNom исполнила приказ в тот же день. Namecheap предоставила личность клиента 4 сентября. В январе 2009 года последовал согласованный предварительный судебный запрет. К тому времени, когда окружной суд рассматривал ходатайство Namecheap о прекращении дела в мае, немедленный кризис непрерывности был разрешён, но юридическое распределение ответственности — нет.

Эта хронология расставляет средства защиты в правильном порядке. Суд сначала остановил операционный вред, обязав действовать в точке технического контроля. Затем последовало раскрытие, которое поддержало возможность истца установить предполагаемого нарушителя. Согласно постановлению, Solid Host не стала изменять иск, чтобы заменить раскрытое лицо в качестве ответчика. Публичная запись не объясняет почему. Этот выбор подкрепляет необходимость не считать раскрытие самоцелью. Раскрытое имя может быть полезным, но не привести к взысканию, судебному решению или восстановлению. Подотчётность требует пути от информации к обязательному последствию.

Шесть позиций в одной цепочке контроля

Спор становится яснее, если рассматривать доменную экосистему как цепочку отдельных позиций, а не как единые отношения с «регистратором».

Solid Host занимала позицию заявленного бенефициарного владельца и исторического оператора. Она утверждала прежнее право на имя, обладала доказательствами его использования в бизнесе и историей учётной записи и могла добиваться экстренной судебной защиты. Однако после предполагаемого переноса учётной записи она утратила практический контроль. Её доказательства могли поддержать иск; сами по себе они не могли обновить авторитетные настройки домена.

Неизвестный пользователь занимал позицию непосредственного бенефициарного контролёра. Согласно утверждениям, это лицо контролировало учётную запись, в которую был перенесён домен, и могло направить имя на другой адрес. У пользователя также была информация, необходимая для объяснения передачи как покупки или кражи. Однако публичная регистрационная запись не показывала эту личность. Схема конфиденциальности отделяла фактическое использование от публичной атрибуции.

eNom занимала позицию регистратора, обращённого к реестру, для этого домена. Эта роль давала самые прямые технические рычаги. Спонсирующий регистратор может подавать изменения через канал реестра, вести учётную запись регистратора и исполнять судебный приказ о передаче. Решающий наблюдаемый результат прост: когда был издан временный запретительный приказ, eNom восстановила домен в тот же день. Это не доказывает, что eNom вызвала или небрежно допустила спорный перенос. Но это показывает, что eNom была участником, способным выполнить немедленное техническое средство защиты.

Namecheap занимала более сложную позицию. В иске не утверждалось, что она действовала как аккредитованный регистратор solidhost.com. Утверждалось, что сервис Namecheap WhoisGuard фигурировал как зарегистрированный владелец или регистрант, лицензировал использование домена клиенту и подставлял собственные контактные данные в публичную запись. Namecheap также знала личность клиента, могла передавать сообщения, оценивала доказательства Solid Host и была назначена запасным передающим лицом в приказе суда. Эти возможности не равнялись регистраторскому контролю eNom. Но они помещали Namecheap внутрь цепочки реагирования на инциденты.

WhoisGuard, как описано в процессуальных документах, не был просто пустым экраном над полем базы данных. По утверждениям, схема делала сервис держателем записи, а клиент осуществлял использование. Эта юридическая форма важна, потому что держатель записи может нести договорные обязанности, которые не возникают у простого ретранслятора сообщений. Она важна и экономически. Сервис, продающий анонимность, может привлекать клиентов, поскольку посторонние не могут сразу связать домен с бенефициарным пользователем.

Та же конструкция создаёт предсказуемый класс споров, в которых сервис становится единственным легко идентифицируемым посредником, способным связаться с пользователем.

ICANN занимала позицию установления правил и аккредитации, но не позицию частного арбитра в этом инциденте. Её Соглашение об аккредитации регистраторов устанавливало условия между ICANN и аккредитованными регистраторами и требовало определённых положений в договорах регистратора с клиентами. Эта архитектура могла влиять на то, как формулировалась ответственность прокси-держателя ниже по цепочке. Она не давала Solid Host автоматического частного средства защиты против Namecheap или eNom. Это различие позже стало явным в Девятом округе.

Федеральный суд занимал позицию принуждения. Solid Host могла участвовать в частном процессе уведомления, отправляя заявления и аргументы. Namecheap могла их рассматривать и передавать. eNom могла обладать технической возможностью. Ни один из этих фактов сам по себе не создавал для истца исполнимого результата. Суд соединил юридическую власть с конкретным средством защиты и назвал участников, обязанных его реализовать. Он превратил оспариваемое утверждение во временное распоряжение, не решая окончательно вопрос по существу.

Эти шесть позиций — заявленный владелец, бенефициарный контролёр, спонсирующий регистратор, отображаемый регистрант и хранитель личности, создатель правил аккредитации и суд — показывают, почему общие слова о «провайдере» затемняют ответственность. Каждый участник владел разным объектом контроля: доказательствами, доступом к учётной записи, командами реестра, идентификационными данными, договорными стандартами или юридическим принуждением. Центральная институциональная проблема дела возникла потому, что эти объекты не совпадали с единым процессом принятия решений.

Почему позиция отображаемого регистранта имела значение

Публичные регистрационные данные не раскрывали бенефициарного пользователя, но указывали на субъекта, обращённого к ответственности. В этом точка напряжения. Сервис конфиденциальности может описывать свои публичные данные как щит от спама, преследования или нежелательного раскрытия. Однако для внешнего истца отображаемый регистрант — это также адрес, по которому приходит уведомление. Сервис получает выгоду от доверия как замещающее лицо регистрации. Он не может сделать эту замену значимой для конфиденциальности и одновременно бессмысленной для подотчётности.

Это утверждение не означает, что отображаемое имя является бенефициарным владельцем для всех юридических целей. Прокси-схемы и схемы конфиденциальности намеренно разделяют эти понятия. Оно не означает и того, что сервис должен разрешать спор о праве собственности на основе заявления истца.

Оно означает как выбор институционального дизайна, что отображаемая позиция должна нести определённые процедурные обязанности: принимать и маршрутизировать уведомления, сохранять релевантные доказательства, связываться с клиентом, определять правильного технического ответственного, не способствовать дальнейшей передаче, пока оценивается достоверное заявление о краже, и объяснять, какой порог управляет дальнейшими действиями. Майское постановление 2009 года само по себе не устанавливало весь этот список как юридическую обязанность.

Анализ окружного судачастично опирался на это функциональное различие. Namecheap ссылалась на защиту ACPA для регистраторов и других регистрационных органов. Суд признал, что Конгресс ограничил ответственность за обычные функции регистрации и обслуживания. Суд не признал полный иммунитет для каждой услуги, которую может предоставлять аккредитованный регистратор. Постановление рассматривало eNom как регистратора домена, а Namecheap — как провайдера анонимности, который, по утверждениям, стал регистрантом записи. Поэтому юридический вопрос зависел от того, в каком качестве действовала Namecheap, а не просто от того, имела ли Namecheap аккредитацию где-то в своём бизнесе.

Такой подход, основанный на качестве, институционально важен. Крупные посредники часто действуют одновременно в нескольких юридических ролях: регистратор, реселлер, хостинг-провайдер, сервис конфиденциальности, торговая площадка, платёжный процессор или контакт для жалоб. Ответственность и полномочия по восстановлению могут меняться в зависимости от роли. Правило, следующее за корпоративным ярлыком, позволяет организации переносить иммунитет из одной функции в другую. Правило, следующее за действием, спрашивает, что организация контролировала в спорной операции.

Современный анализ Finneganназвал это новой чертой постановления: суд не стал автоматически распространять защиту регистратора на поведение за пределами базовой регистрации и допустил ответственность за содействие там, где провайдер, по утверждениям, осуществлял необычный контроль. Этот обзор полезен как современное прочтение, но главным ограничением остаётся сам приказ. Суд решал, могут ли заявленные правовые теории продолжаться, а не объявлял окончательное правило о том, что сервисы конфиденциальности несут ответственность всякий раз, когда их клиентов обвиняют.

Следует также помнить практическую разницу между контактом для конфиденциальности и прокси-регистрантом. Ретранслятор, который публикует альтернативные контактные данные, но оставляет клиента юридическим регистрантом, может иметь меньше формальных полномочий, чем субъект, который становится держателем записи и лицензирует использование обратно клиенту. В процессуальных документах 2008 года утверждалась именно вторая схема. Это утверждение было необходимо для попытки возложить ответственность. Современные структуры провайдеров могут распределять роли иначе, и современные описания нельзя проецировать назад как доказательство договора 2008 года.

Что на самом деле решило майское постановление 2009 года

Постановление окружного суда от 19 мая 2009 годаотклонило ходатайство Namecheap о прекращении дела, но его аргументация не подтвердила все теории, которые выдвигала Solid Host. Суд разделил прямую установленную законом ответственность, ответственность за содействие и договор. Каждый путь имел разный юридический объект и разную слабость.

Прямая ответственность по ACPA не прошла на стадии заявления иска

Какизложил окружной суд установленный законом тест, Закон о защите потребителей от киберсквоттинга возлагает прямую ответственность на лицо, которое с недобросовестным умыслом получить выгоду от чужого знака регистрирует, продаёт или использует доменное имя, тождественное или сходное до степени смешения с защищённым знаком. Solid Host утверждала, что неизвестный пользователь забрал имя и требовал оплату. Она также пыталась возложить прямую ответственность на Namecheap.

Суд отклонил эту прямую теорию, поскольку требуемый умысел — это не общая недобросовестность. Это недобросовестный умысел получить выгоду от деловой репутации знака. В иске утверждалось, что Namecheap зарабатывала деньги на сервисе анонимности и отказалась раскрыть клиента. Но не было достаточно заявлено, что Namecheap намеревалась использовать знак Solid Host или получить выгоду от его деловой репутации. Плата за конфиденциальность не была достаточной. Это различие не позволяет автоматически считать коммерческие отношения провайдера с предполагаемым нарушителем собственным киберсквоттингом провайдера.

Неудавшийся прямой иск важен, потому что он обозначает предел объединения ролей. Появление в качестве регистранта и хранение идентификационных данных не делало Namecheap предполагаемым похитителем. Прямая ответственность по ACPA по-прежнему требовала собственного умысла Namecheap в отношении знака. Институциональная близость к событию злоупотребления — это не то же самое, что содержательное участие в лежащем в основе нарушении.

Ответственность за содействие киберсквоттингу временно сохранилась

Более амбициозной теорией Solid Host была ответственность за содействие киберсквоттингу. Закон прямо не предусматривал такого основания иска.Окружной суд, тем не менее, использовал принципы ответственности за содействие нарушению товарного знакаи спросил, знала ли Namecheap о предполагаемом нарушении и имела ли достаточный контроль над средством, использованным для его совершения.

Постановление рассматривало контроль как нечто большее, чем просто возможность зарегистрировать имя. Согласно утверждениям, Namecheap была указанным регистрантом, могла отслеживать отношения с клиентом, хранила идентификационные данные и имела роль в передаче домена. Суд счёл эти факты достаточными, чтобы отличить обычного регистратора, пассивно обрабатывающего имена, от посредника, осуществляющего более широкий контроль над оспариваемым средством.

Сложнее было со знанием. Суд не сказал, что любое обвинение создаёт ответственность или обязанность раскрытия. Требование владельца товарного знака обычно даёт позицию только одной стороны. Провайдеры не могут безопасно передавать домены всякий раз, когда заявитель утверждает право собственности; это подвергло бы добросовестных регистрантов дешёвой форме частного изъятия. Поэтому суд говорил об исключительных обстоятельствах и достаточных доказательствах.

Он рассудил, что у поставщика услуг может возникнуть обязанность провести проверку, если представлены доказательства, достаточно сильные, чтобы предполагаемое нарушение стало очевидным, причём объём проверки ограничен тем, насколько сложна верификация.

На стадии ходатайства о прекращении дела утверждение Solid Host о том, что она предоставила заявление под присягой и подтверждающие материалы, было достаточным для продолжения. Это не было выводом о том, что доказательства действительно доказывали кражу, что проверка Namecheap была недостаточной или что заявление неизвестного пользователя о покупке было ложным. Эти вопросы требовали более полной записи. Публичное дело, указанное всудебном архиве, не содержит окончательного судебного решения, разрешающего их.

Различие между уведомлением и знанием имеет центральное значение. Уведомление — это вход: сообщение поступило. Знание — это юридический вывод о том, что получатель понял или должен был понять после рассмотрения достоверных доказательств. Система уведомлений может быть прозрачной в отношении получения жалоб, но не предлагать никакого подотчётного способа превращения доказательств в мотивированное решение. Теория Solid Host пыталась сделать юридически значимым неспособность преодолеть этот разрыв там, где посредник, по утверждениям, обладал необычным контролем.

Договорная теория сохранилась только через нижестоящее соглашение

Solid Host также опиралась на формулировки, связанные с Соглашением об аккредитации регистраторов ICANN. Пункт, процитированный окружным судом, соответствуетRAA от 17 мая 2001 года— соглашению об аккредитации, действовавшему во время событий 2008 года. Раздел 3.7.7 требовал от аккредитованного регистратора включить определённые условия в договор с каждым держателем зарегистрированного имени. Раздел 3.7.7.3 касался держателя, который лицензировал использование имени другому лицу: держатель оставался зарегистрированным держателем записи и принимал ответственность за вред, причинённый неправомерным использованием, если только он не раскрывал незамедлительно личность лицензиата стороне, предоставившей разумные доказательства причинения вреда, за который возможен иск.

Архитектура пункта важнее расплывчатого утверждения, что ICANN «требовала раскрытия». Пункт требовал от регистратора включить формулировку в нижестоящее регистрационное соглашение. Текст 2001 года говорил о личности лицензиата; более поздняя версия RAA добавила актуальные контактные данные. Окружной суд анализировал более раннюю формулировку и предполагаемое соглашение между eNom и Namecheap, а не общее право любого истца принуждать к раскрытию напрямую из договора об аккредитации.

Сначала Solid Host попыталась рассматривать сам RAA как договор, исполнимый пострадавшими третьими лицами. Суд отклонил этот путь. Раздел 5.10RAA 2001 годалишал третьих лиц прав выгодоприобретателей по соглашению об аккредитации. Положение о лицензировании к тому же находилось внутри требования к регистратору включить условия в отдельное регистрационное соглашение. Само по себе оно не было обещанием ICANN или регистратора каждому потенциальному истцу.

Суд, однако, разрешил сохраниться более узкой договорной теории. Solid Host утверждала, что отдельное соглашение между eNom и Namecheap включило положение о лицензировании и раскрытии и что лица, пострадавшие от неправомерного использования клиентом, были задуманными выгодоприобретателями этого обещания. Это нижестоящее соглашение не было представлено суду при рассмотрении ходатайства. Принимая утверждения как истинные, судья счёл преждевременным отклонять возможность того, что Solid Host могла требовать исполнения отдельного договорного условия.

Это не было окончательным выводом о том, что Solid Host являлась выгодоприобретателем. Соответствующий договор не был изучен, его целостность и намерение не были установлены, и никакое окончательное решение не разрешило вопрос. Разница решающая: RAA мог требовать от регистратора включить условие в другой договор, не давая постороннему лицу основания иска по RAA. Любое частное средство защиты зависело от формулировок и предполагаемых выгодоприобретателей нижестоящего соглашения.

Иск по законодательству штата следовал за сохранившимися теориями

Иск Solid Host о недобросовестной конкуренции по законодательству Калифорнии сохранился, поскольку иск по-прежнему утверждал незаконное поведение через теории содействия и договора. Это не создало независимого фактического вывода. На этом этапе его жизнеспособность была производной. Поэтому общий отказ окружного суда в удовлетворении ходатайства означал, что разбирательство может продолжиться, а не что Namecheap признана ответственной за предполагаемый угон.

Майское постановление лучше всего понимать как карту возможной ответственности в условиях неопределённых фактов. Прямая ответственность по ACPA требовала собственного недобросовестного умысла Namecheap и не прошла. Ответственность за содействие зависела от контроля и знания и временно сохранилась. Договорная ответственность не могла возникнуть из RAA как частное право, но могла возникнуть из отдельного соглашения. Суд оставил последние пути открытыми достаточно долго, чтобы доказательства имели значение.

Девятый округ сузил сохранившиеся пути

Два более поздних решения Девятого округа изменили то, какую часть аргументации окружного суда можно переносить дальше. Одно ограничило частную опору на формулировку RAA о раскрытии. Другое полностью отвергло содействие киберсквоттингу по ACPA.

Balsam: договорная формулировка без частного средства защиты по RAA

В делеBalsam v. Tucowsистец получил заочное судебное решение на 1,125 млн долларов против Angeles Technology, утверждая получение 1125 незаконных коммерческих электронных писем, но не смог его исполнить. Публичная база регистрационных данных первоначально указывала на Angeles; после того как Angeles, по-видимому, включила функцию Contact Privacy компании Tucows, Balsam заявил, что больше не может найти Angeles или установить оператора домена. Он потребовал, чтобы Tucows раскрыла оператора или выплатила сумму решения, и утверждал, что может требовать исполнения положения RAA о лицензировании как выгодоприобретатель.

Девятый округ оставил в силе прекращение дела. Суд прочитал RAA в целом: раздел 3.7.7 требовал от регистратора включить определённые положения в отдельное соглашение с регистрантом, а раздел 5.10 лишал третьих лиц прав выгодоприобретателей по самому RAA. Поэтому положение о лицензировании не создавало самостоятельного обещания, исполнимого каждым лицом, заявляющим о вреде, за который возможен иск.

Подход апелляционного суда не стёр различие, проведённое в деле Solid Host. Он укрепил его. Прямая теория на основе RAA не прошла; иск, основанный на отдельном соглашении между регистратором и регистрантом или между регистратором и реселлером, должен был опираться на собственные формулировки этого соглашения и применимое право. В деле Solid Host нижестоящий договор был заявлен, но отсутствовал в материалах ходатайства. Пробел исследования остаётся: публичная судебная запись не содержит окончательного решения о том, что Solid Host была задуманным выгодоприобретателем этого соглашения.

Balsam демонстрирует разницу между формальным правилом и исполнимым средством защиты. Договор может содержать формулировку, которая, казалось бы, распределяет ответственность за неправомерное использование. ICANN может требовать от регистраторов включить эту формулировку ниже по цепочке. Но ни тот, ни другой факт не даёт постороннему лицу права подавать иск по соглашению об аккредитации, когда тот же документ лишает третьих лиц прав. Прозрачность правила не отвечает на вопрос, кто может его применить, в каком форуме, против какой стороны и для какой защиты.

Petronas: по ACPA нет основания иска за содействие киберсквоттингу

Доктринальный удар по теории содействия нанесло делоPetronas v. GoDaddy.com. Дело достигло Девятого округа после упрощённого судебного решения и ограниченного раскрытия доказательств, касавшихся сервиса перенаправления доменов GoDaddy. Petronas обжаловала только вопрос о содействии киберсквоттингу.

Девятый округ постановил, что ACPA не создаёт основания иска за содействие киберсквоттингу. Суд рассудил, что Конгресс принял отдельное установленное законом основание иска с указанными элементами и не добавил вторичную ответственность. Суд отказался выводить тест «исключительных обстоятельств» из традиционной доктрины товарных знаков. Он также предупредил, что требование к нейтральным поставщикам услуг выводить субъективный недобросовестный умысел клиента из конкурирующих заявлений создаст ложные срабатывания и давление на посредников, побуждая отключать законные регистрации.

В решении цитировалась линия окружных судов, начатая Solid Host, и она была отвергнута как основа ответственности по ACPA. В Девятом округе майская теория 2009 года о содействии поэтому больше не даёт жизнеспособного основания иска по ACPA. Это более позднее решение не следует переносить задним числом в процедурную ситуацию окружного суда: в мае 2009 года окружной судья разрешил продолжить теорию при тогда ещё неустоявшемся праве. К декабрю 2013 года округ заявил, что закон её не предусматривает.

Petronas было и уже, чем общее решение об иммунитете. Оно не устанавливало, что регистраторы, реселлеры или сервисы конфиденциальности никогда не могут нести прямую ответственность по ACPA, обычным искам о товарных знаках, договорным искам, искам по законодательству штата или обязанностям, созданным судебным приказом. Оно установило, что сам ACPA не поддерживает содействие киберсквоттингу. Процедурная обстановка — апелляция на упрощённое судебное решение по сервису перенаправления — также отличалась от спора Solid Host на стадии ходатайства о прекращении дела о прокси-регистранте и предполагаемом уведомлении о краже.

Вместе Balsam и Petronas оставляют более узкий институциональный урок. Формулировка RAA о раскрытии не является частным основанием иска. ACPA не предусматривает ответственности за содействие в Девятом округе. Ответственность поэтому следует искать в другом месте: в собственном прямом поведении и умысле провайдера, отдельно исполнимом договоре, другом применимом правовом требовании, политике регистратора, создающей рабочий процесс, или приказе компетентного суда. Тот факт, что посредник занимает место в цепочке контроля, остаётся операционно важным, даже когда самые широкие правовые теории не проходят.

Читаемость WHOIS не была подотчётностью

Публичная регистрационная запись в августе 2008 года выполнила одну полезную функцию: она дала Solid Host видимый субъект для связи. Это была читаемость. Она не раскрыла лицо, осуществляющее бенефициарный контроль, не установила, была ли передача санкционирована, не обязала провайдера сохранять доказательства и не создала право на восстановление.

Это различие важно за пределами дела, потому что споры о публичных регистрационных данных часто смешивают несколько целей. Публикация может сделать видимым формальный контакт домена. Правила точности могут требовать поддержания данных. Системы ретрансляции могут позволить посторонним отправлять сообщения. Механизмы раскрытия могут показывать непубличные данные на оговорённых условиях. Ни один из этих механизмов сам по себе не решает спорное право и не гарантирует средство защиты.

В деле Solid Host отображаемая запись, возможно, даже усилила институциональную зависимость от посредника. Поскольку WhoisGuard, по утверждениям, фигурировал как держатель записи, посторонние не могли обойти его, чтобы связаться с клиентом. Сервис стал воротами, через которые должны были проходить уведомление, личность и, возможно, сотрудничество при передаче. Такая роль привратника создавала рычаг, но не обязательно юридически исполнимую обязанность использовать его предпочтительным для Solid Host образом.

Судебный приказ дал то, чего не давал WHOIS: власть, названного исполнителя и конкретное операционное распоряжение. Он обязал eNom восстановить домен, требовал сотрудничества Namecheap и создал запасной механизм. Приказ также ограничивал защиту. Он не присуждал окончательно убытки и не объявлял предполагаемую кражу доказанной. Судебный контроль оказался эффективным здесь, потому что создал исполнимое временное средство защиты в точке контроля, а не просто потому, что судья мог проверить процесс провайдера.

Таким образом, дело разделяет четыре институциональных понятия. Участие означало, что Solid Host могла подать доказательства, а Namecheap могла связаться со своим клиентом. Прозрачность означала, что публичная запись показывала прокси, а суд позже описал позиции сторон. Подотчётность требовала, чтобы лицо, принимающее решение, приводило причины и несло ответственность за результат. Средство защиты означало, что участник с полномочиями мог изменить техническое состояние домена. Только последнее остановило немедленную потерю непрерывности.

Современный политический компаратор, а не реконструкция 2008 года

Текущие документы провайдера показывают, как Namecheap, Inc. теперь описывает свой процесс, но они не могут установить, что происходило внутри в 2008 году.Политика Namecheap в отношении судебных приказов и повесток, последний раз пересмотренная 23 апреля 2026 года и изученная для этой статьи 31 июля 2026 года, гласит, что компания обычно не раскрывает информацию о клиентах или учётных записях, кроме ограниченных обстоятельств или случаев, когда этого требует применимое право и надлежаще вручённый процессуальный документ. В ней говорится, что Namecheap может оценить запрос на обслуживание, запросить подтверждающие документы, уведомить клиентов в некоторых обстоятельствах и оспорить требование. Политика также содержит отказ от создания прав третьих лиц.

Та же политика гласит, что запросы непубличной информации о регистрантах оцениваются в соответствии с применимыми требованиями ICANN, реестра и законодательства о конфиденциальности. Она описывает «Withheld for Privacy» как отдельного исландского провайдера, которому не передаются данные клиентов или регистрантов Namecheap и который не контролирует домен, его контент или связанные услуги; политика направляет запросы в Namecheap. Namecheap также заявляет, что, за исключением особых обстоятельств по её усмотрению, она не будет решать споры о праве собственности третьих лиц и считает компетентный суд надлежащим форумом.

Текущаядокументация о конфиденциальности доменовговорит, что соответствующие критериям клиенты получают анонимизированные публичные контактные данные и уникальный адрес электронной почты, через который сообщения могут фильтроваться и пересылаться. В качестве поставщика услуги указан Withheld for Privacy. Это нынешние описания провайдера, а не независимый аудит и не доказательство схемы WhoisGuard 2008 года.

Тем не менее сравнение показательно. Жалоба 2008 года утверждала, что сам сервис конфиденциальности стал зарегистрированным держателем, знал клиента и мог участвовать в восстановлении. Описание политики 2026 года отделяет публичного провайдера конфиденциальности от хранения данных клиента и контроля домена. Такая конструкция может прояснить, какой субъект должен получать юридические документы, но она также может удлинить путь, который должен пройти истец. Ответственность не исчезла; она была распределена.

Распределённая модель работает только тогда, когда передачи ответственности явно определены. Публичный сервис должен надёжно маршрутизировать уведомления. Реселлер должен сохранять доказательства о клиенте и учётной записи. Спонсирующий регистратор должен иметь возможность накладывать блокировки и исполнять приказы. Каждый участник должен знать, кто владеет инцидентом, а клиент должен получить справедливую возможность ответить, если уведомление не создаст дополнительного вреда.

В противном случае разделение становится методом процедурного уклонения: каждый субъект правдиво говорит, что недостающая возможность находится у другого, а ни одно решение не связывает цепочку.

Текущая политика также показывает пределы доступа. Истец может подать запрос и подтверждающие документы. Компания может их рассмотреть. Суд может издать процессуальный документ. Ни один из этих шагов не гарантирует раскрытия. Провайдер сохраняет юридические возражения; клиент может оспаривать; законодательство о конфиденциальности может ограничить раскрытие. Это уместно для добросовестных пользователей, чьи личности могли бы подвергнуть их возмездию или мошенничеству. Это подкрепляет необходимость различать право просить и право получать, а также решение о раскрытии и решение о восстановлении.

Протокол уведомления о краже, построенный вокруг обратимого контроля

Контрфактический сценарий для Solid Host — это не правило, требующее немедленной передачи домена всякий раз, когда истец подаёт заявление. Такое правило превратило бы системы конфиденциальности и регистраторов в частные службы изъятия. Лучший контрфактический сценарий — это процесс с фиксацией времени, который сохраняет варианты, пока доказательства наиболее свежие, и заставляет реселлера и спонсирующего регистратора отвечать через один журнал инцидента.

1. Запустить отсчёт времени и сохранить запись.Истец, заявляющий о захвате учётной записи, должен получить идентификатор инцидента и точный список необходимой информации. В тот же момент реселлер и спонсирующий регистратор должны сохранить журналы аутентификации, записи о переносе учётной записи, записи о передаче регистратора, изменения DNS и серверов имён, изменения контактных данных, события оплаты, сообщения поддержки, данные IP-сессий, события двухфакторной аутентификации и соответствующие сообщения клиента. Сохранение должно происходить до решения вопроса по существу. Утраченные журналы — необратимый сбой; их временное сохранение обычно обратимо и подлежит проверке.

2. Проверить истца, не считая проверку доказательством права собственности.Провайдер должен проверить доступ к историческим адресам электронной почты, платёжным записям, прежним запросам в поддержку, истории реестра и другим артефактам учётной записи. Прохождение этих проверок устанавливает, что истец имеет отношение к прежней учётной записи. Оно не доказывает окончательно, что продажи или санкционированной передачи не было. Это различие не позволяет превращать проверку личности в тихое решение о праве собственности.

3. Передать уведомление и создать короткое окно для ответа.Текущий контролёр должен получить обвинение и защищённое резюме доказательств с коротким сроком для предоставления договора купли-продажи, платёжного следа, разрешения или иного объяснения. Уведомление можно отложить, если существует достоверный риск уничтожения доказательств или дальнейшей передачи, но это исключение должно быть задокументировано. Публичная запись в деле Solid Host не показывает полную возможность ответа, которую получил клиент; протокол должен сделать этот шаг проверяемым.

4. Ввести узкую блокировку передачи.Если объективные признаки указывают на возможный захват учётной записи — недавний сброс учётных данных с последующим внутренним переносом учётной записи, резкая смена серверов имён, несоответствие платёжных данных, требование обратной продажи или расхождение с историческими контактами, — регистратор должен предотвратить дальнейшие передачи регистратора или учётной записи на короткий определённый период. Блокировка не должна передавать домен истцу и не обязательно изменять текущий DNS. Её цель — остановить рассеивание активов, сохранив спорное состояние. Она должна истекать, если не продлена мотивированным решением или судебным приказом.

5. Создать одно мотивированное решение через границу между реселлером и регистратором.Назначенный ответственный за инцидент должен один раз собрать доказательства и выдать письменный результат, обязательный и для реселлера, и для спонсирующего регистратора: восстановить, сохранить блокировку до разрешения спора, снять блокировку или запросить дополнительные доказательства. В решении должно быть указано, какие факты приняты, какие остались спорными, какой договорный или политический порог применялся и какой путь пересмотра существует. Отдельные организации могут сохранять отдельную правосубъектность, но клиент или истец не должен получать несовместимые ответы об одном и том же событии контроля.

6. Отделить защищённое раскрытие личности от технического восстановления.Личность может быть раскрыта проверенным адвокатам, суду, согласованному нейтральному лицу или другому защищённому получателю, когда достигнут применимый порог. Публичное раскрытие не должно быть вариантом по умолчанию. Восстановление должно решаться на основе доказательств о контроле и праве, а не на основе того, узнал ли истец имя клиента. Solid Host показывает, почему эти два трека должны оставаться раздельными: eNom восстановила домен 26 августа; Namecheap раскрыла личность 4 сентября.

7. Передавать необратимые шаги органу, способному связать цепочку.Постоянная передача и раскрытие личности могут причинить вред, который нельзя полностью отменить. Когда доказательства остаются действительно спорными, протокол должен сохранить домен и журналы, направляя стороны в суд или к согласованному арбитру. Экстренные приказы должны называть спонсирующего регистратора, реселлера, провайдера конфиденциальности и любого участника реестра, необходимого для исполнения. Приказ по делу Solid Host был эффективен, потому что назвал eNom первым исполнителем, требовал сотрудничества Namecheap и предусмотрел запасной механизм.

8. Закрыть с журналом аудита и ограниченным пересмотром.Файл инцидента должен фиксировать временные метки, полученные доказательства, уведомления клиента, блокировки, решения, раскрытия и исполнение. Пересмотр должен проверять, соблюдалась ли заявленная политика, не были ли проигнорированы релевантные доказательства и соответствовало ли средство защиты решению. Пересмотр не должен становиться бессрочной приостановкой, оставляющей домен неиспользуемым. Непрерывность требует сроков в той же мере, в какой процедурная справедливость требует причин.

Этот протокол привязывает обязанности к возможностям. Публичный прокси принимает и передаёт. Хранитель личности сохраняет и, где разрешено, раскрывает. Спонсирующий регистратор замораживает или восстанавливает. Нейтральный орган решает сложные споры о праве. Один ответственный за инцидент не даёт цепочке распасться. Ни один участник не становится ответственным лишь потому, что находится рядом; каждый отвечает за объект, который контролирует.

Экономика поддерживает такое распределение. Сервисы конфиденциальности и реселлеры могут снижать трение при регистрации и зарабатывать на объёме. Расследования краж дороги, нерегулярны и конфликтны. Без обязывающего процесса у каждого провайдера есть стимул минимизировать собственное расследование и перенаправить истца в другое место, а истец несёт расходы на поиск правильной стороны и получение приказа. Протокол с фиксацией времени встраивает часть этих издержек в дизайн сервиса, создающего непрозрачность. Он также защищает добросовестных клиентов, заменяя импровизированное раскрытие определёнными порогами и проверяемой записью.

Что запись не может установить

Пределы публичной записи — часть дела, а не неудобство, которое нужно сгладить. Окружной суд излагал утверждения для целей ходатайства о прекращении дела. Он не сделал окончательного вывода по итогам разбирательства о том, что перенос учётной записи 4 августа произошёл точно так, как заявлено, что у неизвестного лица не было действительной покупки или что Namecheap сознательно содействовала киберсквоттингу.

Запись, доступная черезархив Центрального округа Калифорнии, не раскрывает полный внутренний файл доказательств Namecheap, точные технические журналы, доступные в августе 2008 года, или полную возможность клиента ответить до раскрытия. Она не объясняет, почему Solid Host не заменила раскрытое лицо как ответчика. Она не предоставляет окончательного решения по предполагаемому договору между eNom и Namecheap и не устанавливает, что Solid Host была задуманным выгодоприобретателем.

Эти пробелы не позволяют вынести вердикт об окончательной ответственности провайдеров. Они не мешают анализу цепочки контроля. Наблюдаемые факты уже и твёрже: суд издал экстренный приказ; eNom восстановила контроль в тот же день; Namecheap раскрыла личность позже; окружной суд рассматривал предполагаемую прокси-роль Namecheap как юридически отличную от регистраторской роли eNom; а более поздние апелляционные решения закрыли широкие пути через RAA и содействие по ACPA.

Поэтому ограниченный вывод является институциональным. Конфиденциальный посредник не приобретает общей обязанности раскрывать клиентов лишь потому, что истец отправил уведомление под присягой. Но когда посредник фигурирует как регистрант, хранит личность бенефициарного пользователя, оценивает доказательства и может сотрудничать в восстановлении имени, он вошёл в цепочку контроля. Его обязанности должны следовать за этими полномочиями: сохранять, передавать, приостанавливать, где оправдано, решать с указанием причин, раскрывать через защищённый канал, когда разрешено, и координироваться со спонсирующим регистратором.

Вышестоящий регистратор не может поглотить всю ответственность лишь потому, что исполняет команду реестра. И провайдер конфиденциальности не может отказаться от всей ответственности лишь потому, что не исполняет её.