Реестр тех, кто попросил исчезнуть
Люди в этом списке попросили исчезнуть — те, кто пережил сталкинг (навязчивое преследование) и домашнее насилие, судьи, пациенты клиник репродуктивного здоровья, все, у кого есть причина стереть свой след. С января они подают заявления по калифорнийскому 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 июня.