iCloud Private Relay раскрывает ваш настоящий IP-адрес

Вы включили iCloud Private Relay ровно по одной причине: чтобы сайты, которые вы посещаете, перестали видеть, откуда вы подключаетесь. В этом вся суть предложения. Apple пропускает трафик Safari через два узла, так что ни одна сторона — ни ваш интернет-провайдер, ни сайт — не может связать вашу личность с местом назначения. Для определённого класса запросов это обещание не выполняется.

4 августа 2026 года исследователи в области безопасности Томми Миск (Tommy Mysk) и Талал Хадж Бакри (Talal Haj Bakry) опубликовали результаты, показывающие, что сайт может получить ваш настоящий IP-адрес при включённом и нормально работающем Private Relay. 5 августа тему подхватила пресса — среди прочих MacRumors, 9to5Mac, TechCrunch и The Hacker News. Каналов утечки три, механически они друг с другом не связаны, и самый острый из них затрагивает passkeys — технологию входа, которую Apple годами продвигает как более безопасную замену паролям.

В этой статье разбираем, что Private Relay на самом деле обещает, что продемонстрировали исследователи, как работает каждая из трёх утечек, как проверить собственный Mac и что действительно стоит с этим делать. Прежде всего — замечание о масштабе: речь об утечке вашей сетевой идентичности, а не содержимого просмотра и не ваших учётных записей. Никто не читает ваш зашифрованный трафик. Никто не получает доступ к вашему iCloud. Утекает IP-адрес, и насколько это важно, целиком зависит от того, кто вы и кто на вас смотрит.

Ключевые выводы

• Три отдельных вектора, один результат. Миск и Хадж Бакри показали, что церемонии WebAuthn/passkeys, предзагрузка DNS и WebTransport по отдельности способны раскрыть сайту ваш настоящий IP-адрес при включённом Private Relay. Это независимые баги, которые просто сходятся в одном и том же отказе.
• Для утечки через passkey сам passkey не нужен. Исследователи выяснили, что сайту достаточно лишь начать церемонию — запрос могут спровоцировать как сайты, реально использующие passkeys, так и те, что лишь притворяются. Вам не нужно ни на что нажимать и не нужно завершать вход.
• Это утечка IP, а не взлом. Зашифрованное содержимое вашего просмотра не раскрывается, ни одна учётная запись не скомпрометирована, идентификатор CVE не присвоен. Раскрывается сетевая идентичность: ваш настоящий адрес и, в случае с DNS, ваш настоящий резолвер.
• Apple разбирается, исправления сегодня нет. Apple сообщила 404 Media, что изучает отчёт. По данным 9to5Mac, статусное сообщение Apple исследователям указывало на намерение устранить проблему, а целевой срок исправления — осень 2026 года. MacRumors охарактеризовал проблему как заложенную в саму работу WebKit.
• Отключать Private Relay — неверная реакция. Он по-прежнему делает реальную работу против пассивных наблюдателей в вашей сети. Разумное усиление при настоящей модели угроз — полноценный VPN, с честным компромиссом: вы переносите доверие с Apple на поставщика VPN.

Что такое iCloud Private Relay на самом деле и что Apple обещает

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

iCloud Private Relay — функция iCloud+, то есть она поставляется с платным тарифом хранилища iCloud, а не с операционной системой. Позиционирование Apple последовательное и довольно узкое: функция создана, чтобы скрывать ваш IP-адрес и активность просмотра от сетевых провайдеров и от сайтов, которые вы посещаете. Это и есть обещание. Не «мы зашифруем всё на вашем Mac» и не «мы сделаем вас анонимным».

Двухузловая архитектура

Архитектура — самая интересная часть, и продумана она действительно хорошо. Когда Private Relay активен, запрос из Safari не идёт напрямую к серверу назначения. Он проходит через два прокси последовательно.

Первый узел, входной прокси (ingress proxy), управляется Apple. Apple знает, кто вы, — вы ведь вошли в учётную запись iCloud, а ваше устройство подключилось из конкретной сети. Чего Apple не получает, так это адреса назначения. Адрес сайта, который вы открываете, зашифрован так, что входной прокси не может его прочитать.

Второй узел, выходной прокси (egress proxy), управляется сторонним партнёром по доставке контента, а не Apple. Именно этот прокси реально разговаривает с сайтом назначения. Он знает, куда вы идёте. Он не знает, кто вы, потому что никогда не видел ни вашего исходного IP-адреса, ни вашей идентичности в iCloud, — запрос он получил от входного прокси Apple.

Результат — намеренное разделение знания. Ни одна сторона не держит обе половины чувствительной пары. Apple знает «кто», но не «куда». Партнёр знает «куда», но не «кто». Сайт в конце цепочки видит адрес выходного прокси, а не ваш, и вдобавок Apple предлагает настройку грубой локации, чтобы видимый сайту адрес всё же примерно совпадал с вашим регионом, — это удобно для местного поиска и новостей и при этом не указывает на вас точно.

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

Ключевая рамка: это не VPN

Вот часть, которая важна для понимания утечки. Private Relay — не VPN, и Apple никогда его так не описывала.

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

Private Relay работает в гораздо более узком периметре. Он покрывает:

• Трафик просмотра в Safari. Это главный сценарий использования.
• Разрешение DNS. Ваши DNS-запросы должны идти через реле, чтобы ваш резолвер не превращался в журнал всех мест, где вы бывали.
• Часть незашифрованного трафика приложений. Незащищённые HTTP-запросы, которые делают приложения, затягиваются в реле как мера усиления защиты.

Это и есть периметр. Трафик Chrome через него не идёт. Трафик вашего почтового клиента через него не идёт. Зашифрованный трафик сторонних приложений через него не идёт. Если приложение открывает собственное соединение через собственный сетевой стек, Private Relay не находится на этом пути и никогда не заявлял обратного.

Это различие не формальность — это вся рамка для оценки новых находок. Две из трёх найденных исследователями утечек в каком-то смысле представляют собой случаи, когда запрос выходит за периметр, который очерчивает Private Relay. Баг не в том, что периметр существует. Баг в том, что запросы, порождённые тем, что пользователь воспринимает как «просмотр в Safari», оказываются за его пределами — незаметно, без единого сигнала о том, что что-то покинуло туннель.

Что обнаружили исследователи

Томми Миск и Талал Хадж Бакри занимаются этим не впервые. У них длинный послужной список разбора заявлений о приватности на платформах Apple — и часто выясняется, что разрыв между маркетинговым описанием и реализацией шире, чем кто-либо ожидал. Их подход последователен: собрать демонстрацию, опубликовать её и позволить артефакту говорить за себя, а не пресс-релизу.

Их находки по Private Relay датированы 4 августа 2026 года. Публикации появились на следующий день, 5 августа, в MacRumors, 9to5Mac, TechCrunch и The Hacker News, среди прочих изданий.

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

Три вектора таковы:

1. WebAuthn / passkeys. Сетевой запрос, который делает вход по passkey, выпускается службой учётных данных операционной системы, а не Safari, поэтому он никогда не попадает на проксируемый путь.
2. Предзагрузка DNS. Функция ускорения, добавленная в поколении OS 26, которая раскрывает настоящий DNS-резолвер пользователя.
3. WebTransport. Более новый транспортный API, добавленный в поколении 26.4, который может открыть прямое соединение HTTP/3 в обход прокси.

Уязвимы Safari и просмотр на базе WebKit. На iOS, где в большинстве юрисдикций всё ещё требуется, чтобы любой браузер использовал WebKit под капотом, это означает, что затронуты и альтернативные браузеры: переход с Safari на другой браузер для iPhone не меняет движок, который выполняет работу. На Mac ситуация иная: экспозиция сосредоточена на Safari и на приложениях, встраивающих WebKit для внутреннего просмотра, тогда как браузеры не на WebKit — Chrome и Firefox — используют собственные движки и собственные сетевые стеки. Для пользователей Mac это существенная разница, и мы ещё вернёмся к тому, что она даёт, а что нет.

Ответ Apple, по сообщениям: компания сообщила 404 Media, что изучает отчёт. 9to5Mac сообщил, что статусное сообщение Apple исследователям указывало на планы устранить обозначенную ими проблему, а целевой срок исправления — осень 2026 года. Этим ограничивается всё, что публично приписывается Apple. Конкретный релиз не назван, дата выхода Apple публично не подтверждена, и ни одному из трёх векторов не присвоен идентификатор CVE.

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

Вектор passkey, разобранный как следует

Из трёх именно этот стоит понять в деталях. Он самый неожиданный, от него труднее всего уклониться, и у него самое неприятное следствие.

Что такое церемония WebAuthn на самом деле

Passkeys построены на WebAuthn — веб-стандарте аутентификации с открытым ключом. Ментальная модель, которую держат в голове большинство людей, в целом верна: вместо отправки пароля на сервер ваше устройство хранит закрытый ключ, сервер хранит соответствующий открытый ключ, а вход означает доказательство того, что вы контролируете закрытый ключ, подписав вызов. По проводу не передаётся ничего повторно используемого. Фишинг passkey не работает так, как фишинг пароля, потому что подпись привязана к источнику (origin).

Последовательность шагов, которая всё это выполняет, называется церемонией. JavaScript сайта обращается к браузеру, браузер просит платформу создать или проверить учётные данные, вы аутентифицируетесь локально через Touch ID или код-пароль устройства, и обратно приходит подписанное утверждение. На платформах Apple сами учётные данные хранятся в приложении Passwords и синхронизируются через iCloud Keychain. Если вам нужен более широкий контекст того, как Apple развивает эту сторону, мы разбирали её в материале о приложении Passwords и автоматической смене паролей.

О чём почти никто не думает: церемония не является чисто локальной. Её часть подразумевает получение данных по сети — конфигурации проверяющей стороны (relying party), ассоциативных данных, связывающих домен сайта с учётными данными, которым разрешено его обслуживать. Кто-то должен сделать HTTPS-запрос, чтобы это получить.

Кто делает запрос

Вот здесь всё идёт не так. Цитируя изложение объяснения исследователей:

WebKit передаёт церемонии WebAuthn службе учётных данных операционной системы, которая сама выпускает HTTPS-запрос — напрямую с устройства и не зная ни о каком прокси, настроенном хост-приложением.

Читайте внимательно, потому что здесь работает каждое придаточное. WebKit не выполняет церемонию сам; он делегирует её системной службе, владеющей учётными данными. Эта служба затем делает собственный исходящий HTTPS-запрос. И, что критично, она не знает ни о каком прокси, настроенном хост-приложением: служба учётных данных не знает и не интересуется тем, что Safari настроен маршрутизировать свой трафик по двухузловому пути Private Relay. Это другой процесс с другой сетевой конфигурацией, делающий то, для чего он был спроектирован.

Следствие, снова по сообщениям:

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

Итак, запрос уходит напрямую с вашего устройства, с вашего настоящего IP-адреса, на сервер, которым управляет сайт. Сайт видит соединение. Он записывает адрес. Private Relay всё это время работал и просто не был на этом пути.

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

Самый острый момент: passkey вам не нужен

Вот деталь, которая превращает это из любопытной заметки об архитектуре в реальную проблему приватности.

Исследователи отмечают, что это срабатывает на сайтах, которые используют passkeys или лишь притворяются, что используют. Сайт может запустить церемонию, а вы при этом не завершаете никакой вход. Вам не нужно иметь passkey для этого сайта. Вам вообще не нужна учётная запись. Не нужно нажимать кнопку входа, подтверждать запрос Touch ID или с чем-либо взаимодействовать.

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

Это переворачивает смысл функции. WebAuthn существует, чтобы сделать аутентификацию безопаснее. В такой конфигурации сам факт вызова механизма аутентификации становится триггером деанонимизации, который любая страница может дёрнуть молча, при загрузке. Трекеру не нужно ничего компрометировать. Ему нужно включить фрагмент кода, запускающий церемонию, которую никто никогда не завершит, — и он соберёт настоящие IP всех пользователей Private Relay, открывших страницу.

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

Вектор предзагрузки DNS

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

Для чего нужна предзагрузка

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

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

Данная конкретная реализация появилась в поколении OS 26 — релизах эпохи Tahoe на всех платформах Apple.

Что она раскрывает

Исследователи обнаружили, что эти предзагрузочные запросы раскрывают настоящий DNS-резолвер пользователя.

При нормальной работе Private Relay DNS должен входить в то, что реле покрывает. Это сделано намеренно и это важно: если бы ваши запросы уходили к резолверу провайдера в открытом виде, у провайдера был бы список всех доменов, которые вы искали, с отметками времени, а это практически полная история просмотра — независимо от того, насколько хорошо зашифрован сам трафик. Private Relay во многом существует именно для того, чтобы разорвать эту связь.

Когда предзагрузочные запросы выходят за пределы этого пути, они идут к тому резолверу, который ваше устройство реально настроено использовать, — как правило, к выданному вам по DHCP в текущей сети, а это обычно означает вашего провайдера, вашего работодателя или оператора того Wi-Fi, к которому вы подключены.

Здесь утекает нечто более узкое, чем «сырой» IP-адрес. Наблюдатель узнаёт, каким резолвером вы пользуетесь, а это сильный сигнал о том, в какой вы сети и часто — какой провайдер вас обслуживает. В сочетании с другими сигналами это вносит вклад в отпечаток. Это также означает, что оператор резолвера видит обращения, которые должны были быть от него скрыты.

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

Вектор WebTransport

Третья утечка связана с самой новой из трёх технологий и лучше всего иллюстрирует структурную суть проблемы.

Для чего нужен WebTransport

WebTransport — современный веб-API для двунаправленной связи с низкой задержкой между браузером и сервером. Считайте его преемником WebSockets, построенным поверх HTTP/3 и QUIC, а не поверх TCP.

Он существует потому, что заметному классу веб-приложений нужно нечто лучшее, чем схема «запрос/ответ». Многопользовательские игры должны постоянно проталкивать состояние и переносят случайные потерянные обновления лучше, чем задержку. Приложениям для живого видео и аудио нужно то же самое. Совместные редакторы, инструменты удалённого рабочего стола, панели телеметрии в реальном времени — всем им нужен постоянный канал с низкими накладными расходами и возможность отправлять ненадёжные датаграммы, когда надёжность не стоит платы задержкой.

WebTransport обеспечивает это, работая поверх QUIC — транспорта на базе UDP со встроенным шифрованием и без блокировки начала очереди между потоками. Это действительно хорошая инженерия для той задачи, которую она решает.

Реализация Apple появилась в поколении 26.4.

Почему прямое соединение HTTP/3 обходит прокси

Проксирование Private Relay построено вокруг обычного веб-трафика — тех шаблонов запросов, которые порождает штатный сетевой путь Safari. Они идут по двухузловой цепочке ingress/egress.

Исследователи обнаружили, что WebTransport может открыть прямое соединение HTTP/3 в обход прокси. Как только такое соединение установлено напрямую от устройства к серверу назначения, сервер видит настоящий адрес устройства — точно так же, как при любом непроксированном соединении.

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

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

Как проверить собственный Mac

Исследователи собрали публичный инструмент для тестирования, и с точки зрения читателя это самое полезное во всём раскрытии. Вам не придётся верить никому на слово.

Инструмент находится по адресу https://leaks.psylo.app/.

Как проводить тест

1. Сначала убедитесь, что Private Relay включён. Нет смысла тестировать утечку, если реле не работает. Откройте System Settings, нажмите на свой Apple Account вверху боковой панели, выберите iCloud, затем Private Relay и убедитесь, что он включён. Если не уверены, перейдите сразу к разделу о проверке статуса Private Relay — он отключается сам чаще, чем большинство людей думает.
2. Запомните, как должен выглядеть ваш адрес через реле. Любой сервис «какой у меня IP», открытый в Safari с включённым реле, покажет адрес, принадлежащий выходному партнёру Apple, а не ваш собственный. Это и есть базовая точка отсчёта: адрес, который сайт должен видеть.
3. Откройте тестовую страницу в Safari. Используйте именно Safari, поскольку на macOS векторы специфичны для WebKit. Инструмент выполнит свои проверки и сообщит, что ему удалось наблюдать относительно вашего соединения.
4. Сравните результаты. Чистый результат означает, что адреса, которые инструмент наблюдал через каждый проверенный вектор, совпадают с вашим адресом через реле — прокси устоял. Результат с утечкой означает, что как минимум один вектор выдал адрес, не принадлежащий реле, и этот адрес ваш.
5. Тестируйте в каждой сети, которая для вас важна. Результаты могут различаться между домашней сетью, корпоративной сетью и публичным Wi-Fi — отчасти потому, что и сама доступность Private Relay в них разная.

Честная оговорка

Тестовый инструмент сообщает вам о тех векторах, которые в нём реализованы. Он не сообщает обо всех возможных векторах.

Это важнее обычной дисклеймерной формулировки — из-за структурного соображения выше. Если базовая проблема в том, что новые подсистемы WebKit могут открывать сетевые соединения за границей прокси, то набор векторов не фиксирован: это то, что обнаружено на данный момент. Чистый результат на инструменте, проверяющем три вещи, означает, что эти три вещи не дали утечки в том тесте, в той сети, в тот момент. Это заметно лучше, чем не знать. Но это не сертификат анонимности.

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

Что реально можно сделать прямо сейчас

Исправления, которое можно установить, нет. Ниже — примерный порядок по степени реальной пользы, и для каждого пункта указано, чего он вам стоит, потому что мера защиты с неозвученным компромиссом — это рекламный питч, а не совет.

1. Используйте полноценный VPN, если ваша модель угроз это оправдывает

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

Компромисс реален, и его стоит проговорить вслух прежде, чем действовать: вы переносите доверие с Apple на поставщика VPN. Двухузловая архитектура Private Relay специально устроена так, чтобы ни одна сторона не видела одновременно и вашу личность, и ваши направления. У обычного одноузлового VPN этого свойства нет. Ваш VPN-провайдер видит и то, и другое. Вы ставите на его политику логирования, его юрисдикцию, его операционную безопасность и его честность — и, в отличие от архитектуры Apple, эта ставка обеспечивается не устройством системы, а обещанием в политике конфиденциальности.

Это не аргумент против VPN. Это аргумент за осознанный выбор: независимо проаудированный, ясный по юрисдикции, с бизнес-моделью, которая не зависит от ваших данных. Если пойдёте этим путём, рассчитывайте потратить время на особенности настройки; наше руководство по устранению неполадок VPN в macOS разбирает сценарии отказов, на которых люди спотыкаются именно в macOS.

2. Не выключайте Private Relay

Это самый частый порыв, и он в корне неверен.

Private Relay по-прежнему делает реальную работу против пассивных наблюдателей. Ваш провайдер по-прежнему не может собрать журнал просмотра из ваших DNS-запросов по всему, что действительно идёт через реле. Оператор Wi-Fi в кофейне по-прежнему не может наблюдать, какие сайты вы открываете. Подавляющее большинство трафика Safari по-прежнему проксируется и по-прежнему скрывает ваш адрес от сайтов, которые вы посещаете. Утечки — это конкретные пути, которые ускользают, и они требуют активных действий от сайта: страница должна вызвать церемонию passkey, или использовать WebTransport, или спровоцировать поведение предзагрузки.

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

3. Осознанно относитесь к тому, каким сайтам вы позволяете начать церемонию

Этот совет слабее, чем звучит, и стоит честно объяснить почему.

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

Что у вас остаётся — это контроль над тем, какие страницы вы вообще открываете. Если вы делаете что-то, где раскрытие IP действительно имеет значение, помните: любая открытая вами страница — включая ту, на которую вы попали по ссылке, включая встроенный веб-просмотр внутри приложения — это страница, которая может задействовать вектор. Это довод в пользу разделения на отсеки: вести чувствительный просмотр в намеренно выбранной среде, а не в той же сессии, что и всё остальное. Это не довод в пользу чек-листа сайтов, которых надо избегать, потому что сайты, которые стали бы этим пользоваться, о себе не объявляют.

4. Поймите, что здесь делает Lockdown Mode, а чего не делает

Lockdown Mode — это экстремальный режим защиты Apple для пользователей, находящихся под риском целевой атаки. Он отключает длинный список веб-технологий, включая JIT-компиляцию JavaScript и различные сложные функции, исходя из того, что поверхность атаки, которой у вас нет, нельзя проэксплуатировать.

Его стоит рассмотреть, если вы относитесь к той аудитории, для которой Lockdown Mode создавался, — весь его подход состоит в удалении функциональности, а не в патче конкретных багов, а удалённые функции не могут дать утечку. Но будьте осторожны с рассуждением: Lockdown Mode — это оборонительная поза общего усиления, а не адресное исправление этих трёх векторов, и ни одна публикация не подаёт его как средство против этой проблемы. Считайте его разумным вариантом для оценки, если вы уже подходите под его аудиторию, а не ответом на эту конкретную проблему. Он к тому же ломает очень многое в обычном веб-просмотре — это сделано намеренно, и потому Apple не рекомендует его для повседневного использования.

5. Знайте, что даёт смена браузера — и где она не даёт ничего

Здесь важна платформа.

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

На Mac ситуация действительно другая. Браузеры не на WebKit используют собственные движки и собственные сетевые стеки, поэтому в отношении этих конкретных векторов, происходящих из WebKit, они ведут себя иначе. Но обратите внимание, что это даёт, а что нет: Private Relay изначально не проксирует трафик браузеров, отличных от Safari. Переход на Chrome или Firefox в macOS не ставит вас за реле — он выводит вас за его пределы целиком. Вы не устранили утечку; вы отказались от защиты. Это улучшение только в том случае, если вы сочетаете переход с VPN, покрывающим всё. Если вы проводите большую часть времени в Safari и хотите выжать из него больше, наше руководство по Safari для продвинутых пользователей — лучшее применение вашего внимания, чем миграция на другой браузер, предпринятая по неверной причине.

Не давайте себе завышенных обещаний ни по одному из пунктов. Варианты со 2-го по 5-й снижают экспозицию или не дают сделать хуже. Только вариант 1 работает с векторами на том уровне, где они действуют, и делает это, заменяя одно доверительное отношение другим.

Кого это действительно должно волновать

Истории о приватности вознаграждают истерику и наказывают за чувство меры, так что давайте точно определим, кого это затрагивает и насколько.

Для большинства людей это эрозия, а не чрезвычайная ситуация

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

Подумайте, что именно утекает. Ваш IP-адрес — сайту, который целенаправленно за ним пошёл. У большинства сайтов уже есть куда более качественные идентификаторы для вас: вы вошли в аккаунт, у вас есть cookie, у вас есть отпечаток браузера, который различает вас заметно лучше, чем IP-адрес, меняющийся при переходе между сетями. Для рекламной экосистемы IP-адрес — вспомогательный сигнал, а не главная драгоценность. Компании, которые этим пользуются (если такие есть), — это те, кто уже отслеживает вас всесторонне средствами, которые Private Relay всё равно не собирался останавливать.

Что вы теряете — это уровень эшелонированной защиты, в наличии которого у вас были основания быть уверенным. Это законная претензия. Но это не повод менять образ жизни.

Кому стоит действовать

Всерьёз отнестись к этому стоит тем, чья модель угроз реально включает деанонимизацию по IP. Конкретно:

• Журналистам, работающим с источниками, где связь между репортёром и местом или сетью сама по себе является чувствительной информацией.
• Активистам и организаторам в средах, где сетевой адрес отображается на реальную личность, что несёт риск.
• Людям, которые скрываются от конкретного человека — преследователя, бывшего партнёра, склонного к насилию, кого-то, у кого есть технические средства и мотивация запустить сайт или ссылку и смотреть, кто к ним подключается. Это тот случай, когда IP-адрес по-настоящему опасен, потому что он позволяет приблизительно определить местоположение и подтвердить, что конкретный человек перешёл по конкретной ссылке.
• Людям, чей работодатель или учреждение не должны знать, что они изучают, особенно в сети, которую это учреждение контролирует.

Если вы в одной из этих групп, правильной позицией никогда не был один только Private Relay. Ею были грамотно выбранный VPN или Tor, надлежащее разделение на отсеки и допущение, что любая функция для удобства может отказать. Это раскрытие — напоминание об этом принципе, а не его изменение. Наше руководство по безопасности и приватности Mac глубже разбирает построение многослойной конфигурации, а если вы думаете о более широком снижении своей экспозиции, то запуск ИИ-инструментов локально, а не в облаке следует той же логике применительно к другой части стека.

Промежуточный случай

Между «вас это не касается» и «от этого зависит ваша безопасность» находятся все остальные, и разумная позиция там — калибровка, а не действие. Поймите, что покрытие Private Relay уже, чем ментальная модель, которую держит в голове большинство. Перестаньте считать его VPN, потому что он им не является, а теперь у вас есть конкретная демонстрация разницы. Оставьте его включённым, поскольку он по-прежнему помогает против тех наблюдателей, для которых был создан. И если вы обнаружите, что делаете нечто, где идентификация действительно имела бы значение, возьмите инструмент, созданный именно для этой задачи, а не полагайтесь на тот, который просто уже включён.

Как проверить, включён ли вообще Private Relay

Есть немалая вероятность, что прямо сейчас Private Relay выключен как минимум в одной сети, которой вы пользуетесь, и вы об этом не подозреваете. Он отключается сам в нескольких ситуациях без особых церемоний, так что прежде чем беспокоиться об утечках, стоит убедиться, что реле вообще работает.

Основная настройка

На Mac:

1. Откройте System Settings.
2. Нажмите на свой Apple Account вверху боковой панели.
3. Выберите iCloud.
4. Найдите в списке Private Relay и откройте его.
5. Убедитесь, что переключатель включён. Заодно проверьте настройку IP Address Location: вариант «Maintain General Location» сохраняет работу регионального контента, а «Use Country and Time Zone» ещё сильнее размывает ваше видимое местоположение.

Если Private Relay вообще не отображается, обычное объяснение — вы не на платном тарифе iCloud+. Это функция iCloud+, и на бесплатном уровне хранилища она не появляется.

Переключатель для каждой сети, о котором почти никто не знает

Вот на чём люди спотыкаются постоянно. У Private Relay есть отдельное состояние вкл/выкл для каждой отдельной сети Wi-Fi, независимое от глобальной настройки.

Чтобы проверить: откройте System Settings, перейдите в Wi-Fi, нажмите Details рядом с подключённой сетью и найдите там опцию Private Relay. Для этой конкретной сети она может быть выключена, пока глобальная настройка включена.

Это действительно полезное поведение — так вы держите реле включённым в целом, отключая его для той единственной корпоративной сети, которая без этого ломается, — но оно означает, что «я включил Private Relay» и «Private Relay работает прямо сейчас» — два разных утверждения. Проверяйте настройку на уровне сети в любой сети, где тест показывает неожиданные результаты.

Ситуации, в которых он молча отключается

Помимо двух переключателей, несколько условий отключают реле без заметного предупреждения:

• Неподдерживаемые сети. Некоторые сети блокируют протоколы или конечные точки, от которых зависит Private Relay. Когда это происходит, macOS обычно предлагает выбор: пользоваться сетью без реле или не подключаться, — и тот выбор, который вы сделали тогда, сохраняется.
• Корпоративные и управляемые сети. Предприятия часто отключают Private Relay намеренно, потому что прокси, скрывающий адреса назначения, принципиально несовместим с фильтрацией и мониторингом контента на уровне сети. На управляемых устройствах он может быть отключён профилем конфигурации вообще без доступного пользователю переключателя.
• Ограничения по странам и регионам. Private Relay доступен не везде. Apple подтвердила, что он недоступен в ряде юрисдикций, и в этих регионах функция просто не работает независимо от ваших настроек.
• Конфигурации сотовых операторов. Некоторые операторы поставляют конфигурации, отключающие его в своих сетях.
• Конфликтующие настройки VPN или DNS. Запущенный системный VPN обычно означает, что Private Relay отходит в сторону, поскольку трафик первым забирает VPN. Пользовательские настройки DNS и некоторые профили DNS-фильтрации тоже могут его отключить.

Общая черта в том, что Private Relay отказывает «открыто», а не громко. Он перестаёт работать, а вы продолжаете просматривать сайты. Для функции, ориентированной на удобство, это защитимое проектное решение — альтернатива в том, чтобы ломать людям интернет, — но оно означает, что периодическая проверка остаётся единственным способом узнать своё реальное состояние.

Как должно выглядеть исправление

Стоит подумать, что Apple на самом деле придётся построить, потому что это объясняет, почему заявленные сроки измеряются месяцами, а не точечным обновлением.

Поверхностное исправление — пропатчить каждый вектор по отдельности. Научить службу учётных данных знать о настройке прокси хост-приложения и маршрутизировать свои запросы церемонии соответственно. Вернуть предзагрузочные DNS-запросы внутрь DNS-пути реле. Направить QUIC-соединения WebTransport через цепочку прокси или отказываться устанавливать их напрямую, пока реле активно. Три точечных изменения, три закрытые дыры.

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

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

Третий компонент, и, пожалуй, самый ценный, — видимый пользователю: какой-то сигнал о том, что запрос покинул реле. Сейчас функция полностью молчит о собственном покрытии. Вы не можете определить, была ли страница, на которой вы находитесь, проксирована полностью, частично или вовсе нет. Именно эта непрозрачность превратила три пробела в реализации в историю о нарушенном обещании, потому что у пользователей не было способа заметить разницу между «работает» и «не работает».

На что смотреть в осенних релизах 2026 года

Судя по сообщению 9to5Mac о статусном сообщении Apple исследователям, исправление нацелено на осень 2026 года. Это то, о чём сообщается: Apple публично не обязалась ни к конкретному релизу, ни к дате, и воспринимать это как гарантию не стоит.

Если и когда что-то выйдет, проверять стоит следующее:

• Устранены ли все три вектора или только passkey. Вектор passkey попал в заголовки. Два других тише и вполне могут быть отложены.
• Точечное исправление или структурное. В примечаниях к релизу об этом редко пишут прямо, но исследователи, скорее всего, перепроверят и сообщат, а их тестовый инструмент даёт всем остальным способ проверить независимо.
• Появилось ли что-то видимое пользователю. Любая индикация покрытия реле на уровне отдельной страницы была бы существенным улучшением по сравнению с нынешним молчанием.
• Не переописана ли область действия Private Relay. Если Apple ужесточит формулировки о том, что покрывает функция, это тоже информативно: это будет означать, что решение отчасти касается ожиданий, а не исключительно кода.

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

Устранение типичных проблем

Private Relay неактивен или отсутствует вовсе

Проблема: вы заходите в System Settings, свой Apple Account, iCloud — и либо Private Relay в списке нет, либо переключатель не реагирует.

Решение: пройдите по причинам по порядку. Во-первых, убедитесь, что вы на платном тарифе iCloud+ — на бесплатном уровне Private Relay не существует, и это самое частое объяснение его отсутствия. Во-вторых, проверьте регион: функция недоступна в ряде стран и не отображается там, где не предлагается. В-третьих, если Mac управляется работодателем или учебным заведением, загляните в System Settings в раздел General, затем Device Management, и поищите профиль конфигурации — организации регулярно отключают Private Relay, потому что он мешает сетевой фильтрации, а ограничение на уровне профиля нельзя переопределить локально. В-четвёртых, проверьте, что вы вошли в iCloud с той учётной записью, к которой привязана подписка iCloud+, а не с дополнительной. Если все четыре пункта в порядке, а переключатель по-прежнему не реагирует, выйдите из iCloud и войдите снова, затем перезагрузитесь.

Private Relay постоянно отключается сам в одной конкретной сети

Проблема: реле работает дома, но стабильно выключено в офисе, в определённом кафе или в конкретном отельном Wi-Fi.

Решение: сначала проверьте переключатель на уровне сети, поскольку почти всегда причина в нём. Откройте System Settings, перейдите в Wi-Fi, нажмите Details рядом с этой сетью и найдите там настройку Private Relay. Она не зависит от глобального переключателя, и если вы когда-нибудь закрыли уведомление «эта сеть блокирует Private Relay», выбрав продолжить без него, выбор запомнился для этой сети. Включите его обратно и посмотрите, работает ли соединение. Если сеть действительно блокирует реле, вы снова получите запрос — и в этот момент вы точно знаете, что блокировка находится выше по цепочке, а не является устаревшей настройкой. Корпоративные сети особенно склонны блокировать его намеренно на файрволе, и обходного пути на стороне клиента нет: если вам нужна приватность адреса в такой сети, единственный маршрут — VPN, при условии, что сеть его допускает.

Тестовый инструмент показывает утечку, и вы хотите знать, что делать

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

Решение: во-первых, не интерпретируйте это как компрометацию. Результат с утечкой означает, что сайт мог узнать ваш IP-адрес; он не означает, что что-то украли, к чему-то получили доступ или что-то взломали, и нет ни учётной записи, которую нужно защитить, ни пароля, который нужно менять. Во-вторых, убедитесь, что результат касается именно векторов, а не выключенного реле: проверьте глобальную и посетевую настройки Private Relay и повторите тест, потому что отключённое реле покажет ваш настоящий адрес по всем путям — это совершенно другая проблема с простым решением. В-третьих, если реле точно включено, а утечка сохраняется, вы воспроизвели описанное поведение, и исправления на стороне пользователя не существует. Решайте исходя из своей модели угроз: для большинства правильная реакция — принять к сведению и жить дальше, а для тех, кому приватность адреса действительно нужна, доступная мера — VPN с описанным выше компромиссом доверия. Повторите тест после любого обновления осени 2026 года.

Сайты блокируют вас или ломаются из-за того, что вы используете Private Relay

Проблема: банковский сайт отказывается загружаться, стриминговый сервис утверждает, что вы в неправильной стране, оформление заказа в магазине срывается или сайт постоянно предлагает вам CAPTCHA.

Решение: это происходит потому, что сайт видит адрес выходного прокси, а не ваш, и либо не распознаёт адрес как принадлежащий жилому сектору, либо адрес геолоцируется в неожиданном месте, либо он принадлежит общему диапазону, который был помечен. Начните с настройки локации: в панели Private Relay переключите IP Address Location на «Maintain General Location», если сейчас выбран более широкий вариант на уровне страны, — это устраняет большинство географических несоответствий. Если этого мало, отключите реле с помощью посетевого переключателя только в этой сети, а не глобально, или используйте для конкретного сайта другой браузер, помня, что браузеры, отличные от Safari, в macOS и так находятся вне реле. Отключать реле глобально ради одного упрямого сайта — избыточная реакция, которую вы забудете отменить.

VPN и Private Relay конфликтуют друг с другом

Проблема: вы подключаете VPN, и Private Relay сообщает о себе как о неактивном, либо оба вместе приводят к сломанному DNS, неудачным соединениям или невыносимо медленному просмотру.

Решение: прежде всего поймите, что это во многом ожидаемо. Системный VPN перехватывает трафик на сетевом уровне до того, как его увидел бы Private Relay, поэтому macOS обычно отводит реле в сторону, когда VPN активен, — это не баг и это не оставляет вас без защиты, поскольку VPN теперь покрывает строго больше трафика, чем покрывало реле. Практический совет — выбрать что-то одно и позволить ему владеть путём. Если вы запускаете VPN по причинам, обсуждаемым в этой статье, отход реле в сторону является правильным исходом. Если вы наблюдаете реальные поломки, а не просто сообщение о неактивности реле, обычные виновники — конфликтующая конфигурация DNS, VPN-клиент, который перехватывает трафик лишь частично, или оставшееся сетевое расширение от ранее установленного VPN. Удалите старые профили конфигурации VPN в System Settings, прежде чем продолжать отладку, поскольку на устаревшие профили приходится непропорционально большая доля таких проблем.

Часто задаваемые вопросы

Значит ли это, что моя история просмотра была раскрыта?

Нет. Утекает ваш IP-адрес — сетевая идентичность, а не содержимое. Зашифрованное содержимое вашего просмотра остаётся зашифрованным, и эти векторы не раскрывают ничего о том, какие страницы вы читаете, помимо самого факта, что вы подключились к сайту, который и так пытался вас идентифицировать. Учётные данные аккаунтов не задействованы, и ни одна учётная запись не скомпрометирована.

Стоит ли мне из-за этого перестать пользоваться passkeys?

Нет. Passkeys остаются существенно более безопасными, чем пароли: они устойчивы к фишингу, и по сети не передаётся ничего повторно используемого. Утечка — не слабость самой аутентификации по passkey; дело в том, что сетевой запрос, обслуживающий церемонию, обходит Private Relay. Отказ от passkeys обменял бы реальный выигрыш в безопасности на незначительный выигрыш в приватности.

Присвоен ли этому идентификатор CVE?

Ни одному из трёх векторов CVE не присвоен. Находки опубликованы Миском и Хадж Бакри 4 августа 2026 года, пресса написала о них на следующий день. Apple сообщила 404 Media, что изучает вопрос. Относитесь с осторожностью к любому источнику, который приводит конкретный идентификатор CVE для этой проблемы, поскольку ни один не публиковался.

Решит ли проблему использование Chrome или Firefox на моём Mac?

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

Отличается ли ситуация на моём iPhone от ситуации на Mac?

Да. На iOS большинство юрисдикций требуют, чтобы все браузеры использовали WebKit, поэтому каждый браузер на устройстве разделяет одну и ту же экспозицию, и смена приложения ничего не меняет. На Mac затронуты только Safari и приложения, встраивающие WebKit, поскольку другие браузеры поставляются с собственными движками. Сами векторы ведут себя одинаково на обеих платформах.

Когда Apple это исправит?

9to5Mac сообщил, что статусное сообщение Apple исследователям указывало на планы компании устранить проблему, а целевой срок исправления — осень 2026 года. Публично Apple не обязалась ни к конкретному релизу, ни к дате, помимо подтверждения 404 Media, что изучает вопрос. Исправления сегодня нет, а MacRumors описал проблему как заложенную в саму работу WebKit.

Заключение

Находки Миска и Хадж Бакри реальны, они хорошо задокументированы, и Apple стоит исправить их как следует, а не залатать узко. Три отдельные подсистемы WebKit — служба учётных данных, обрабатывающая церемонии passkey, предзагрузка DNS и WebTransport — каждая способна выставить ваш настоящий IP-адрес перед сайтом, который за ним пришёл, пока Private Relay сидит рядом и сообщает о себе как о включённом. Вектор passkey самый острый из трёх, потому что сайту достаточно начать церемонию, а не завершить её, и от вас при этом не требуется вообще ничего.

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

Чем это является: наглядной демонстрацией того, что покрытие функции уже, чем ментальная модель большинства, и что граница не обеспечивается нигде, где новым возможностям платформы пришлось бы её соблюдать. Если ваша модель угроз действительно включает того, кто узнаёт ваш IP-адрес, ответом всегда был инструмент, созданный именно для этой задачи, с понятым и принятым компромиссом доверия. Если нет — примите это к сведению, оставьте реле включённым, запустите тест, если любопытно, и посмотрите, что выйдет осенью.

Дополнительное чтение: Руководство по безопасности и приватности Mac 2026