# Дыра — несущая конструкция **Deck:** Шесть дней назад Калифорния начала выдавать каждому зарегистрированному брокеру данных список людей, которые попросили себя стереть. Идентификаторы хешированы, без соли, и ноутбук превращает такой хеш обратно в номер телефона примерно за сорок три секунды. В ходе разработки правил криптографы предложили ведомству решение. Оно отказало — письменно, потому что это решение лишило бы брокеров возможности подавлять вас вечно. **By:** редакция URnetwork **Dateline:** Сан-Франциско — 7 августа 2026 года **Category:** Новости / Аналитика --- ## Реестр тех, кто попросил исчезнуть Люди в этом списке попросили исчезнуть — те, кто пережил сталкинг (навязчивое преследование) и домашнее насилие, судьи, пациенты клиник репродуктивного здоровья, все, у кого есть причина стереть свой след. С января они подают заявления по калифорнийскому Delete Act («Закону об удалении», SB 362) — это одно окно, через которое можно потребовать стереть себя у каждого брокера данных в штате, то есть у каждой компании, которая скупает и перепродаёт сведения о людях, полученные не от них самих. Шесть дней назад включилась вторая половина механизма: с **1 августа 2026 года** §1798.99.86(c)(1) Гражданского кодекса Калифорнии требует, чтобы каждый зарегистрированный брокер *"access the accessible deletion mechanism … at least once every 45 days."* — «обращался к доступному механизму удаления … не реже одного раза в 45 дней». Теперь реестр расходится наружу, по системам сотен брокеров — той самой отрасли, от которой эти люди прятались, — и первый обязательный цикл закрывается около **15 сентября**. Идентификаторы хешированы, и это звучит как защита. На одном ядре ноутбука калифорнийский номер телефона из этого списка снова становится номером телефона примерно за **сорок три секунды**. Ведомство, построившее эту машину, — Калифорнийское агентство по защите приватности (California Privacy Protection Agency, CPPA, публично выступающее как CalPrivacy) — брокеров всё-таки предупредило: в записи его блога от 10 июля сказано, что *"starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records."* — «с 1 августа брокеры данных обязаны скачивать хешированные запросы на удаление и сверять их с персональной информацией в своих записях». А вот о самом риске раскрытия оно не сказало ни слова. В его новостной ленте, перепроверенной 7 августа, самая свежая запись по-прежнему датирована 4 августа и посвящена Вермонту; включение 1 августа получило инструкцию для брокеров — и ни единого предупреждения тем, кто в этом списке. ## Хеш снимается за секунды В списке шесть видов идентификаторов, и только один из них назван в регламенте: **MAID** (mobile advertising ID — мобильный рекламный идентификатор). Остальные пять — обозначения из технической спецификации DROP: **NDZ** (имя, фамилия, дата рождения, почтовый индекс ZIP), **Email** (адрес электронной почты), **Phone** (номер телефона), **NameVIN** (имя, фамилия и VIN — идентификационный номер автомобиля) и **CTVID**, идентификатор подключённого к интернету телевизора. Прежде чем что-либо хешировать, правило уплощает входные данные — нижний регистр, знаки пунктуации удалены, диакритика сведена к базовым буквам, — так что собственный пример регулятора превращает *"Björn O'Connor-López"* в *"bjornoconnorlopez."* Даты становятся восемью цифрами, телефон — последними десятью, а пункт «на всё остальное» предписывает брокеру *"implement any other standardization that the data broker knows will increase the likelihood of a match."* — «применить любую иную стандартизацию, о которой брокеру данных известно, что она повысит вероятность совпадения». Каждый шаг выбрасывает энтропию, а энтропия — единственное, что стоит между хешем и значением, из которого он посчитан. Мы пересчитали два разобранных примера из технической спецификации самого штата. Все хеши отдельных полей и оба составных хеша получаются идентичными, бит в бит, как обычный SHA-256 по UTF-8 с выводом в Base64 — без соли, без ключа, без чего-либо, чего не содержали бы уже опубликованные документы. Хеш без ключа, посчитанный от значения с низкой энтропией, — не маскировка; это задача, которую ноутбук решает перебором всех вариантов, а SHA-256 отвечает примерно на **7,1 миллиона попыток в секунду на одном ядре процессора**, без всякой видеокарты. | Что есть в списке | Сколько возможных вариантов | Время на одном ядре ноутбука | |---|---|---| | Калифорнийский номер телефона | 304 000 000 | **~43 секунды** | | Любой номер США или Канады | 6 400 000 000 | ~15 минут | | Имя, дата рождения и ZIP, сверенные с файлом избирателей Калифорнии | ~22 000 000 | **~3 секунды** | | Короткий идентификатор подключённого телевизора | 2,8 × 10¹² | ~4,6 суток | | Мобильный рекламный идентификатор | 2¹²⁸ | практически неосуществимо | Список телефонов не псевдонимен. Это открытый текст плюс один лишний шаг. А списку «имя — дата рождения — ZIP» перебор не нужен вовсе: вы хешируете того единственного человека, которого ищете, и спрашиваете, есть ли результат в списке, — оракул «да/нет», и хеш снова становится именем. Даже рекламный идентификатор, который действительно взломать нельзя, взламывать и не требуется: это ключ связывания (join key), который рекламно-технологическая компания прогоняет по своим собственным устройствам, чтобы узнать, какие из них принадлежат людям, пытающимся себя стереть. Первая очевидная мысль — просто добавить к хешам соль — здесь не работает. Соль (случайная добавка к хешируемому значению) защищает сохранённые пароли потому, что проверяющая сторона уже держит тот секрет, который пользователь только что ввёл. У DROP (Delete Request and Opt-out Platform — государственная платформа приёма запросов на удаление) устройство обратное: брокер сверяет со списком штата *свои собственные* записи, которых Калифорния никогда не видела, поэтому обе стороны должны независимо прийти к одному и тому же хешу — а соль, выданная каждому зарегистрированному брокеру в стране, никакой не секрет. ## Калифорнии предложили решение — и она отказала письменно Вот часть, о которой никто не написал. Ещё в ходе разработки правил криптографы предупредили ведомство, что так и будет. В приложении A к Final Statement of Reasons (итоговому обоснованию правил) авторы комментариев предложили **private set intersection** — «пересечение приватных множеств», протокол, который позволяет двум сторонам узнать только то, что у них общего, и ничего больше, — или сверку внутри **trusted execution environment**, доверенной среды исполнения. Они честно назвали цену, признав, что это помешает *"data brokers from suppressing identifiers in the future,"* — «брокерам данных подавлять идентификаторы в будущем», — и доказывали, что обмен того стоит. Ведомство отказало, и его обоснование — это и есть вся история: > "The Agency notes the alternatives to hashing suggested by commenter, but the Agency has determined that > hashing is a widely used, secure, and accessible method of protecting data, and that **any method that > prevents the ongoing suppression of identifiers by data brokers fails to adequately implement the law**." > > Русский перевод: «Ведомство принимает к сведению предложенные комментатором альтернативы хешированию, > однако ведомство пришло к выводу, что хеширование — широко применяемый, безопасный и доступный метод > защиты данных и что **любой метод, препятствующий продолжающемуся подавлению идентификаторов брокерами > данных, не обеспечивает надлежащего исполнения закона**». Прочитайте вторую половину медленно. Delete Act не просит брокера один раз о вас забыть; он требует, чтобы брокер продолжал вас подавлять — то есть постоянно блокировал ваши данные у себя, с этого момента и впредь. Чтобы подавлять вас вечно, брокер обязан держать что-то долговечное, что означает *вас*, — а хеш именно таков: долговечный, заново вычисляемый токен. Каждая схема, предложенная криптографами, работает именно за счёт того, что *не* оставляет брокеру такого токена, — потому ведомство их и отвергло. Дыра в приватности не дефект, который конструкция не сумела закрыть. Это механизм, ради которого конструкцию и построили. А §7620(c) замыкает круг: *"By submitting a deletion request, a consumer consents to disclosure of their personal information to a data broker for purposes of processing their deletion request."* — «Подавая запрос на удаление, потребитель даёт согласие на раскрытие своей персональной информации брокеру данных в целях обработки его запроса на удаление». Ограничение цели здесь реальное, и это лучший ответ, какой есть у такой конструкции: согласие не безгранично. Но оно определяет, что брокеру позволено *делать* с раскрытыми данными, а не то, чем само раскрытие *является*. Просьба к Калифорнии сделать вас забытым всё равно означает, что вас внесут в список, который скачивают брокеры. ## Позиция ведомства сильнее, чем допускают его критики Ничто из этого не делает ведомство небрежным. Оно отвергло прямое шифрование, потому что тогда у брокеров оказались бы ключи расшифровки, — это заведомо хуже. Оно ужесточило правило сверки до **совпадения на 100 %** — настоящая защита от удаления данных не тех людей. Списки **сегментированы**: брокер, у которого есть только адреса почты, никогда не получит список с именами и датами рождения; загрузки после первой — **инкрементные**, то есть содержат только изменения; а доступ стоит **6000 долларов** ежегодной регистрации под именованной учётной записью. Рассылать имена и номера открытым текстом сотням фирм было бы хуже любого из этого. А самый трудный пункт — вообще не вина ведомства. §1798.99.86(b)(3) — предписание, которое написал легислатор, а не ведомство, — требует механизма, который позволяет брокеру определить, подавали ли вы запрос, и который *"shall not allow the disclosure of any additional personal information … unless otherwise specified in this title."* — «не должен допускать раскрытия какой-либо дополнительной персональной информации … если иное не предусмотрено настоящим разделом». Отложите эту заключительную оговорку в сторону — и останется задача о пересечении приватных множеств, вручённая ведомству штата и профинансированная как выгрузка CSV-файла. И всё же защитные аргументы держатся хуже, чем выглядят. Инкрементная выдача не помогает, если первая загрузка — это весь корпус, а копию его хранит каждый брокер; сегментация полагается на честность брокеров при объявлении своих идентификаторов; а защиты §7616 — юридические, а не технические: ничто не мешает брокеру *вычислить* по списку что угодно, правило запрещает лишь *использовать* результат. ## Один пункт мог бы закрыть дыру до конца первого цикла Рычаг есть, и чтобы его нажать, легислатор не нужен. §7601(c) позволяет самому списку на удаление указывать собственный алгоритм хеширования; SHA-256 ведомство одобрило в ответе на комментарий, но вписать в правило отказалось. Оно может вместо этого предписать Argon2id — функцию хеширования, специально сделанную медленной и требовательной к памяти, — обычным нормотворческим порядком, и сорокатрёхсекундная атака за одну ночь станет неосуществимой: тот же список, другая функция, никакого законопроекта. Под этим лежат два честных ограничения. Мы описываем регламент и спецификацию, а не работающую систему: регламент разрешает любой алгоритм, а живой брокерский API закрыт логином, так что мы не можем подтвердить, что именно выдаёт развёрнутый DROP сегодня. И многократно повторяемое «300 000+» — это собственный подсчёт ведомства от 2 июня: люди, а не запросы, и с тех пор не обновлявшийся. Что мы подтвердить можем — это конструкцию, а конструкция и есть суть. ## Машина, построенная, чтобы помнить вас вечно Уберите всё остальное — останется одно противоречие. Система, которая обязана узнавать вас вечно, чтобы продолжать вас защищать, должна хранить нечто, означающее вас, — а всё, что означает вас, можно превратить обратно в вас. Единственный выход — вообще не быть опознаваемым для этой машины. Это не техническая деталь; это решение о том, кто делает работу, — брокеры или люди, пытающиеся от них исчезнуть. Калифорния приняла его в ходе разработки правил, имея работающую альтернативу перед собой, и выбрала брокеров. --- ## Источники - **Cal. Civ. Code § 1798.99.86** — `leginfo.legislature.ca.gov` — (b)(3), предписание, создающее оракул принадлежности; (c)(1), *"Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism … at least once every 45 days."* — «С 1 августа 2026 года брокер данных обязан обращаться к доступному механизму удаления … не реже одного раза в 45 дней». Закон: §1798.99.80 и далее (SB 362); полномочия — §1798.99.87. Получено 7 августа 2026 года. - **11 CCR §§7601–7622**, "Data Broker Registration and Accessible Deletion Mechanism" («Регистрация брокеров данных и доступный механизм удаления»), вступили в силу 1 января 2026 года — `cppa.ca.gov/regulations/pdf/data_broker_drop_reg.pdf`, 16 с. §7601(c) (алгоритм передаётся вместе со списком); §7612(c) (инкрементные загрузки); §7613(a)(1)(A) (стандартизация, включая пример *Björn O'Connor-López → bjornoconnorlopez*) и (a)(1)(A)(vi); §7613(a)(2)(A) (хешировать каждое поле, сцепить хеши "without adding spaces or other characters" — «не добавляя пробелов или иных символов», — хешировать снова); §7616 (ограничения на использование); §7620(b)–(c) (MAID; согласие на раскрытие). **Исправления, 10 августа**; все три нашли переводчики, сверявшие цитаты с источником. (1) В основном тексте все шесть видов идентификаторов были отнесены к §7613; в регламенте назван только `MAID`, а остальные пять — обозначения технической спецификации, как и было указано ниже, в пункте о самой технической спецификации DROP. (2) §7620(c) цитировался с обрывом на "to a data broker" — без продолжения "for purposes of processing their deletion request." Ограничение цели — самый сильный контраргумент к тому прочтению, которое на этой цитате строилось, поэтому теперь она приводится целиком и разбирается, а не обрезается. (3) §1798.99.86(b)(3) приводился как "no additional personal information", и утверждалось, что это дословная формулировка; в законе сказано "shall not allow the disclosure of any additional personal information … unless otherwise specified in this title", и оговорка теперь показана. Исправление (3) внесено и в hot takes — в абзац о законодательном доводе и во вводный абзац. - **Final Statement of Reasons, Appendix A** (итоговое обоснование правил, приложение A), 53 с. — `cppa.ca.gov/regulations/pdf/drop_fsor_45day.pdf`. Комментарии 117–122 с предложением private set intersection и доверенной среды исполнения и ответ ведомства, приведённый выше полностью; комментарий 196 и обмен репликами о SHA-256 при §7613(a)(1)(B); комментарии 73–75 (шифрование отвергнуто, потому что ключи оказались бы у брокеров); ответ на комментарий 216 (сегментированные списки); комментарий со ссылкой на FTC и ответ ведомства "will also monitor the DROP" («ведомство будет также наблюдать за DROP»). Также `cppa.ca.gov/regulations/pdf/drop_fosr.pdf` и `cppa.ca.gov/regulations/drop.html`. - **Техническая спецификация DROP** — `privacy.ca.gov/drop-for-data-brokers/technical-specifications/working-with-data/`, v1.2.0, "Last updated July 2026" («последнее обновление — июль 2026 года»), получено 7 августа 2026 года. Правила хеширования ("SHA-256 using UTF-8 input encoding" — «SHA-256 с входной кодировкой UTF-8», "Output as Base64" — «вывод в Base64»), шесть типов списков и два разобранных примера, пересчитанных этой редакцией. - **Воспроизведение и замеры, эта редакция, 7 августа 2026 года.** Разобранные примеры спецификации пересчитаны с помощью `hashlib.sha256` и Base64: совпали 7 из 7 хешей отдельных полей и 2 из 2 составных хешей. Пропускная способность измерена локально через `openssl speed sha256` (113 894,45 кБ/с на блоках по 16 байт ≈ 7,1 млн хешей/с на одном ядре) и через цикл на Python `hashlib` (3 413 611 хеш/с). Пространства поиска посчитаны по форматам самого регламента: телефон — 6,4 × 10⁹ для полного плана NANP и 3,04 × 10⁸ для калифорнийских кодов зоны; CTVID — 36⁸ при минимуме в 8 символов; MAID — 32 шестнадцатеричные цифры. `grep -ci 'salt\|pepper'` = 0 и по регламенту, и по FSOR. - **Новостная лента CalPrivacy** — `privacy.ca.gov/about-us/newsroom/`, перезагружена 7 августа 2026 года и повторно 10 августа: последняя запись — 4 августа 2026 года (Вермонт присоединяется к консорциуму регуляторов), предыдущая — 21 июля ("California Privacy Protection Agency Launches First Sectoral Audit, Targets Gig Economy Platforms" — «Калифорнийское агентство по защите приватности начинает первый отраслевой аудит и берётся за платформы гиг-экономики»; подтверждено 10 августа по карте сайта `privacy.ca.gov/sitemap.xml`, которую отдаёт сам сервер, поскольку индекс самой новостной ленты отрисовывается через JavaScript); **записи об обязанности брокеров от 1 августа в новостной ленте нет**. **Исправление, 10 августа:** в первой версии этой статьи говорилось, что ведомство «о включении не сказало ничего». Сказало — но в своём *блоге*, а не в новостной ленте: `privacy.ca.gov/2026/07/drop-data-broker-deletions-how-do-they-work/`, 10 июля 2026 года, где брокерам сообщают "starting on August 1, data brokers must download the hashed deletion requests and compare them against the personal information in their records." — «с 1 августа брокеры данных обязаны скачивать хешированные запросы на удаление и сверять их с персональной информацией в своих записях». Теперь в тексте сказано то, что верно на самом деле, — утверждение более узкое и более тяжёлое: ведомство проинструктировало брокеров и ни разу не предупредило людей из списка. Цифра «300 000+» взята из релиза от 2 июня 2026 года "Privacy Momentum Builds: 300,000+ Californians Sign Up for DROP as Registered Data Brokers Hit a Record High" («Импульс приватности нарастает: 300 000+ калифорнийцев зарегистрировались в DROP, а число зарегистрированных брокеров данных достигло рекорда»), полученного целиком (HTTP 200); в нём также зафиксирован 581 зарегистрированный брокер данных. - **Не установлено, сообщается как пробелы:** какой алгоритм выдаёт развёрнутая система DROP (документация брокерского API на `databroker.drop.privacy.ca.gov` закрыта логином; песочница существует, но её документация оказалась недоступна); любой опубликованный CPPA подсчёт *запросов* на удаление; и любая цифра свежее, чем от 2 июня.