dxdt.blog: занимательный интернет-журнал

Немного занятной и техничной практики DNS. Если взять зону kommersant.ru, то нетрудно выяснить, что с этой зоной что-то сильно не так. Вот “покрасневший” скриншот из отчёта открытого сервиса audit.statdom.ru:

Почему тут указаны только “адреса”, которые отмечены как недоступные? Во-первых, это не адреса, а имена хостов (хостнеймы), которые выглядят похожими на IP-адреса, но намётанный глаз сразу обнаружит подвох: всё выдаёт крайняя справа точка, отделяющая корневой домен; это так называемый FQDN – Fully Qualified Domain Name (“полное имя домена”). Во-вторых, серверы имён, обозначенные таким образом, доступны быть не могут, поскольку в глобальной DNS нет имени первого уровня “20.” (две цифры – 2 и 0).

Между тем, если попробовать зайти на соответствующий апексу зоны веб-сайт kommersant.ru браузером, то, скорее всего, сайт откроется. Получается, что всё работает? Нет, далеко не всё. Но это лишь очередное подтверждение того, что DNS, как сервис и совокупность технологий, в сочетании с вебом, обладает очень высокой степенью устойчивости к ошибкам настройки (кроме, конечно, DNSSEC).

Посмотрим, как же настроена зона kommersant.ru на момент написания данной записки. В домене верхнего уровня RU зона делегрована на два сервера имён (NS) с именами ns.kommersant.ru. и ns5.kommersant.ru., что, скажем, подтверждается следующим фрагментом скриншота того же отчёта:

Поскольку это так называемые “субординатные” имена NS, – то есть, находящиеся в той же зоне, которая делегируется, – серверы зоны RU возвращают соответствующие glue-записи (в отчёте они не показаны). Glue-записи содержат IP-адреса для имён делегирования (ns.kommersant.ru. и ns5.kommersant.ru.). В DNS, glue-записи необходимы для того, чтобы исключить возможность бесконечной рекурсии. Представьте, что зона test.ru делегирована на ns.test.ru. Как же определить IP-адрес ns.test.ru? Ведь для его определения нужно знать адреса NS-ов зоны test.ru, а чтобы их знать, нужно опросить зону test.ru. Как найти адреса? Верный ответ – никак не найти, если бы только не было glue-записей, которые-то и приносят нужные адреса сразу.

Почему здесь вообще возникает такая проблема с аресами/именами? Потому, что в качестве значения DNS-записи NS могут быть указаны только имена хостов. Но соединение и обмен данными в глобальном Интернете происходят по IP. То есть, для отправки запросов и получения ответов нужны именно IP-адреса. Можно ли всё же указать IP-адреса в NS-записях? Нет, нельзя. Причина в том, что значения записей в DNS не могут подразумевать какой бы то ни было протокол обмена данными. Это очень важный и логичный момент: DNS превратилась бы в непонятную путаницу, если бы какие-то дополнительные сведения об установлении соединения “подразумевались” бы: в той же NS-записи – получаем то адрес, то хостнейм, то “какие-то минусы”, то “здесь админы рыбу заворачивали”. Заметьте, сюда ещё накладывается и тот занимательный факт, что вообще невозможно вне контекста отличить запись IPv4-адреса от хостнейма. В практике DNS есть много случаев, когда тот или иной протокол доступа, да ещё и с параметрами, прямо указывается, но корректно это делается только при помощи префиксов в самом имени, например: _443._tcp.name.test.ru. (обратите внимание: предыдущая DNS-строка – не хостнейм!).

Итак, NS-запись должна содержать имя хоста, соответствующее серверу имён. Для разрешения возможных циклов – предусмотрены glue-записи.

Однако доверенным источником полного списка серверов имён для зоны является не делегирующий сервер, не glue-записи, а ответ авторитативного сервера зоны на запрос NS. По этой причине сервис тестирования DNS-узлов получает список этих узлов с авторитативного сервера. Ну, или пытается получить. Серверы, указанные для kommersant.ru в списке делегирования, на запрос NS возвращают те самые “подложные” хостнеймы, сформированные из IP-адресов четвёртой версии. То есть, так указано в файле зоны. Указано неверно. Распространённая ошибка. Видимо, ничего не поделать. Отличить тут адрес от хостнейма программное обеспечение не может, поэтому DNS-сервер будет отвечать тем, что ему написано. А написаны, как уже указано выше, заведомо “неразрешимые” имена (нет, это не IP-адреса; IP-адреса нельзя указывать в NS-записях, поэтому резолвер никак и не может понять, что это, якобы, “IP-адреса”, потому что это хостнеймы).

Почему же работает веб-сайт? Вот почему. Для большинства сценариев доступа к вебу нужен IP-адрес, который передаётся в A-записи DNS. По IP-адресам из glue-записей для обсуждающейся зоны kommersant.ru отвечают серверы имён, которые возвращают A-записи, содержащие корректный и доступный IP-адрес, который указывает на веб-узел. И тут многое зависит от рекурсивного резолвера. Если этот резолвер использует непосредственно адреса из glue-записей для того, чтобы запросить A-записи, то всё сработает. Но glue-записи небезопасно кэшировать – кэшировать следовало бы хотя бы минимально проверенные значения NS, которые требуется достать с авторитативных серверов. Если резолвер попробует получить список NS корректным способом, то он обнаружит дефектные записи, после чего попробует отправить ещё несколько запросов и, скорее всего, всё же найдёт A-запись, чтобы вернуть её клиенту. То есть, резолвер, обычно, настроен так, чтобы хоть что-то достать из DNS (не всегда это правильный выбор, поскольку регулярно служит фундаментом для целевых атак). Так что, спрашивая и переспрашивая, игнорируя и как-то исправляя ошибки в зоне, но резолвер, в большинстве случаев, сможет найти IP-адрес, чтобы потом по этому адресу попробовал подключиться браузер, если только способ достать данный IP-адрес существует. Что же касается других функций DNS – ну, они в данной зоне просто недоступны (тем более, что упомянутые серверы имён не поддерживают современный EDNS-доступ вообще).

Вот. У подобной некорректной настройки DNS есть ещё много неприятных побочных эффектов, связанных с надёжностью и безопасностью. А ведь существует ещё и QNAME Minimization.

(Недавно я описывал другую занятную ошибку настройки DNS, из “дикой природы”, наблюдающуюся в куда более популярной зоне vk.com. Представьте, кстати, куда все эти интернеты прикатятся, если DNSSEC, – несравнимо более требовательная к уровню аккуратности технология, – вдруг получит максимальное распространение.)

(Update, 30.01.2026: в январе 2026 года настройки DNS для зоны kommersant.ru поменяли, и описанный выше эффект наблюдаться перестал; что, конечно, не отменяет важности описанных в этой заметке технических моментов.)

Google, периодически, даже для веб-интерфейса электронной почты, поддерживаемой в рамках GoogleApps, начинает спрашивать телефонный номер, который, якобы, нужен “для повышения безопасности”. Повышение безопасности планируется проводить отправкой кода на указанный телефонный номер (SMS, звонком, может, ещё как-то). В некоторых случаях без указания телефонного номера при создании Google-аккаунта вообще не обойтись, это понятно. Но отдельно печалит то, что даже при подключении с правильными реквизитами аккаунта к веб-интерфейсу почты “из других сетей”, кроме привычной “авторизатору” Google, в почту эта система больше через веб не пускает, а настойчиво требует указать телефонный номер. Конечно, там есть другие варианты (дополнительный email-адрес, ещё что-то), но почему-то эти методы не срабатывают и всё опять возвращается к телефонному номеру (возможно, кроме вмешательства технической поддержки, если она там есть – этот путь я не проверял).

Печально это вот почему: уж сколько лет говорится, что телефонный номер – это ресурс оператора связи, который никак не может принадлежать пользователю-абоненту; оператор связи совсем не обязан как-то дополнительно “защищать” конкретный абонентский телефонный номер и телефонный трафик (хоть и может, конечно). Более того, само наличие схем с отправкой простых кодов на телефонные номера нередко приводит к возникновению уязвимостей, вообще не имеющих отношения к телефонии.

Но ничего на этом направлении не меняется: понятно, что Google тоже нужно собирать телефонные номера.

Иногда можно прочитать, что радар работает “со скоростью света”, поэтому очень быстрый и, таким образом, любая РЛС будет всякую созданную руками современного человека “кинетическую” цель точно обнаруживать заранее и определять траекторию с большим запасом по времени, даже если скорость этой самой цели очень большая (ну, конечно, если та цель отражает радиоволны подходящим способом, но сейчас не об этом). Действительно, если рассматривать “сферический” “радар в вакууме”, то покажется, что зондирующий импульс преодолевает, скажем, 30 километров за, примерно, 0.1 мс (за десятую долю миллисекунды); чтобы сбегать в обе стороны – требуется 0.2 мс. Вроде бы, да, очень быстро.

Но представьте, что вы конструируете практический радар. В ходе конструирования довольно быстро выясняются всякие дополнительные особенности. Например, чтобы отличать собственные зондирующие импульсы среди принимаемого шума, извлекать информацию, нужно эти зондирующие импульсы особым образом модулировать. Модулирование – не только размывает импульсы “по частоте”, но и растягивает по времени. Для защиты от помех, для оптимизации рабочих параметров, требуется использовать довольно сложные схемы модуляции.

С одной стороны, для импульсного радара не очень хорошо, если уже нужно принимать сигнал, а у вас всё ещё передатчики работают, так что сильно “тянуть” зондирующий сигнал не всегда полезно (у радаров с непрерывным излучением – свои преимущества, но и свои особенности: там как раз различные утечки самым прямым образом мешают уменьшению задержек по времени). С другой стороны, оказывается, что для повышения чувствительности и разрешающей способности, для достижения устойчивой селекции сигналов – на приёме требуется некоторый дополнительный интервал времени для работы, условно говоря, разных корреляторов и схем преобразования (Фурье и др.), то есть принимаемый сигнал должен накапливаться, а неудачная обработка приводит к тому, что результат накопления отбрасывается – это потеря времени.

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

И при этом все устройства, входящие в состав радара, обладают задержкой. А в некоторых случаях, это прямо механическая задержка (поворот физической антенны, например, необходимый для определения направления на цель; да, есть чисто электронные способы, но они не всегда доступны, если наблюдать требуется широкий сектор – поэтому-то, между прочим, ставят наборы антенн, направленных в разные стороны).

В общем, даже формирование луча, которому соответствует серия зондирующих импульсов, потребует заметного времени. Если радар стоит на земле, а цель летит со скоростью “всего-то” 3000 м/с, то каждые десять миллисекунд задержки размазывают изображение этой цели на 30 (тридцать) метров. Это, конечно, не так много, если радар наблюдает космический спутник, пролетающий в тысяче километров. Но те же тридцать метров оказываются весьма существенной погрешностью, если вернуться к дистанции в 30 километров, упомянутой в начале записки: пока радар десять секунд “синтезирует и измеряет” траекторию, собирая размытые сигналы, цель уже прибыла в точку назначения.

Пусть скорость света и велика, но приравнивать к ней скорость работы радаров – неверно: особенности аппаратуры создают большие сложности при наведении на быстрые цели, даже если эти цели в сотни тысяч раз медленнее, чем зондирующий импульс. (Это, впрочем, не делает наведение невозможным.)

RU-CENTER не только увеличил цены, но и радикально переделал панель управления. Недавно некоторое сходство современного RU-CENTER с GoDaddy весьма верно подметили в комментариях. Удивительно, но теперь RU-CENTER даже и панелью сильно напоминает GoDaddy. Надо сказать, я довольно долго пользовался услугами GoDaddy, хоть и в небольших, всё время уменьшающихся, объёмах: так исторически сложилось, ещё с тех давнишних времён, когда тот GoDaddy был сильно другим, но всё равно странным. А потом в GoDaddy мой аккаунт забанили по традиционной теперь причине нахождения в России. Соответственно, оставшиеся ресурсы – отобрали.

Вот одна из интересных концепций, позволяющих оптимизировать взаимодействие интернет-узлов по разным сессионным протоколам: “при повторном подключении – сразу отправляем полезные данные для приложения”; это вместо сложного этапа установления соединения, требующего отправки и приёма нескольких сообщений, до того, как полезные данные станут доступны приложению.

То есть, если при первом соединении два узла должны выполнить некоторый обмен пакетами по схеме “запрос-ответ-подтверждение”, чтобы на обоих концах “сокета” сформировался синхронный контекст, то почему бы не запомнить контекст на стороне клиента и при повторных соединениях обойтись без дополнительных шагов для формирования нового контекста, а просто отправить вместе с начальным сообщением немедленно и полезные данные?

Пример уровня сетевого транспорта – TCP Fast Open, который, почему-то, известен мало: здесь клиент в рамках первого TCP-соединения, выполняемого по обычной схеме с созданием сессии, получает специальный идентификатор (cookie), чтобы при последующих соединениях сразу начать передачу полезных данных.

В TCP штатно используется схема установления соединения с тремя этапами согласования (SYN, SYN-ACK, ACK), когда передача данных приложению начинается только после завершения всех трёх этапов. И тут уже есть интересный момент, про который, бывает, забывают даже специалисты: вообще-то, данные между узлами в TCP начинают передаваться сразу же, с первым пакетом (SYN), так же, как, скажем, в UDP; потому что если бы данные не передавались (как минимум, заголовки с идентификаторами и параметрами), то и установить соединение было бы невозможно – это очевидно. То есть, с точки зрения возможности “отправить пакет в одну сторону”, TCP не слишком-то отличается от UDP на уровне, так сказать, NOC. Другое дело, что начальная информация TCP, составляющая обмен для установления сессии, не должна быть штатно доступна на уровне абстракции “сокета”. И вот тут-то начинаются отличия от того же UDP. Но сами по себе пакеты TCP вполне могут служить транспортом для “безсессионной” доставки данных.

Вариант Fast Open, если оставить за скобками детали, лишь обобщает эту возможность (о чём прямо написано в RFC), выводя её на уровень того самого “сокета”. Это делается при помощи дополнительной информации (cookie), подтверждающей, что сессия уже была установлена с соответствующими параметрами. Это и есть пример внедрения метода “сразу отправляем полезные данные”. Для реализации аналогичных логических схем в других протоколах используется, конечно, и UDP – посмотрите на WireGuard через Wireshark.

На уровне выше – тоже есть примеры: в TLS 1.3 имеется достаточно продвинутая сокращённая схема установления соединения 0-RTT (Zero Round-Trip Time), где клиент сразу же начинает передачу полезных данных в защищённом виде, если известна дополнительная информация о TLS-сервере, которую можно было получить в предыдущих соединениях (или как-то ещё).

Так что использование одной и той же полезной логической схемы самого верхнего уровня позволяет оптимизировать разные протоколы. Если задуматься, то сюда даже попадает port knocking. Вообще, если клиент и сервер заранее договорились о некотором секрете, то и обмен данными можно свести к отправке “случайных” пакетов со “случайным шумом” по случайным адресам. Пропускная способность, впрочем, будет не велика. Это работает далеко не только для Интернета.

Разумный “искусственный интеллект”, как обещают, всё ближе. При этом весьма размыто даже определение момента, с которого “искусственный интеллект” должен считаться разумным: кому-то и условие обыгрывания компьютером в шахматы человеческого гроссмейстера казалось достаточным, а кому-то – условие достижения неразличимости человека и компьютера в текстовом “чатике”.

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

Вообще, судя по некоторым признакам из окружающей действительности, “действительно разумным” “искусственный интеллект” станет тогда, когда об этом напишут основные СМИ (“мейнстрим-медиа”, как говорится). Естественно, не без участия соответствующих корпораций, регулирующих комиссий и авторизованных организаций, занимающихся “факт-чекингом” для противодействия “фейк-ньюс”.

В какой-то момент ведущие СМИ напишут, что вот, мол, разработка корпорации “Имярек” является “разумным ИИ”, это подтверждается и экспертами, и выкладками “факт-чекеров”, в которых выкладках объявлено, что раз газета такая-то и еженедельник такой-то выпустили статьи, называющие разработку корпорации “Имярек” “разумным ИИ”, то всё верно – это оно и есть: разумный ИИ. Вывод, кроме прочего, подтверждается выдачей всех верно настроенных вспомогательных ИИ-систем, а компьютер, как известно, не может ошибаться, поэтому “поверьте уже в науку”. А потом ещё определят, что предписания, генерируемые новым ИИ, который СМИ объявили разумным, обязательны к исполнению. Не сомневайтесь.

Немного аналоговой электроники. По ссылке на Youtube – видео (английский язык), где в ходе ремонта подробно разобран (буквально) предусилитель из самого высокого сегмента “хай-энд”, то есть, заявленной стоимостью в 25 тыс. фунтов (обратите внимание: двадцать пять тысяч фунтов – это стоимость полноценного автомобиля).

Устройство сильно пострадало при перевозке почтой (коробку, предположительно, “пинали по парковке”), но содержательная часть ремонта именно электроники – это “всего лишь” замена конденсатора, для выполнения которой, впрочем, автор видео провёл подробную “обратную разработку” устройства и даже сделал руководство. (Дефектный конденсатор, кстати, там обнаруживают весьма высокотехнологичным способом.)

Забавно выглядит уровень исполнения электроники усилителя (см. видео и картинку ниже): то есть, выглядит это действительно так, как самая что ни на есть “ручная работа”, и при этом маркировка на некоторых компонентах спилена (old-school). Огромных электронных ламп не просматривается, реализовано на полупроводниковых элементах и обычных проводках (проводки, похоже, почему-то без экранов).

(Скриншот из видео.)

Самый занимательный технический момент (ну, кроме общего исполнения) – это реализуемый данным устройством способ снижения уровня внутреннего шума, возникающего при слабом входном сигнале на выходе операционного усилителя: здесь использовано несколько параллельно включенных трактов, вывод которых должен снижать шум в результирующем сигнале путём усреднения шума. То есть, случайный шум на выходах разных элементов суммируется и, – местами, – амплитуда его уменьшается из-за того, что шумящие сигналы, генерируемые внутри каждого операционного усилителя, оказываются в противофазе. Такой вот способ увеличения “динамического диапазона” (известный).

(Скриншот из видео. Транзистор “обезличен”: вообще, все такие транзисторы заметно различаются по характеристикам, даже внутри одной партии; заметность этих различий, конечно, возрастает в “малошумящих схемах”.)

А вот предназначение множества микропереключателей, имеющихся на корпусе, в данном видео всё же не раскрыто.

(Найдено на Hackaday.)

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

Предположим, некоторые объекты, принадлежащие “персонам” (потому что “персональные данные”), для подсчёта отображают в одинаковые по размеру разноцветные шары, которые укладывают в урну. Персон-источников – трое. Каждому сопоставлен цвет, в который окрашиваются шары. Однако исследователям “данные предоставляются в анонимизированном, обезличенном виде”, поэтому таблица соответствия цветов персонам – уничтожается сразу, как только урна заполнена шарами.

Исследователи “обезличенных данных”, извлекая шары из урны, могу считать, сколько у “некоторой персоны” имеется объектов-шаров, но определить, кому именно из реальных персон принадлежат объекты в заданном количестве – не могут. Это действительно так. Более того, описанный метод, в разных версиях, очень широко используется и считается хорошим инструментом анонимизации данных.

В нашей учебной схеме – три персоны. Так что, предположим, в урне обнаружено 11 зелёных шаров, 13 синих, и 27 красных. Исследователи записывают эти данные. Заметьте, что исследователи могут различить все три персоны (A, B, C). Если бы это было не так, то и анонимизации с шарами не потребовалось бы – просто не возникало бы необходимости: весь смысл обезличивания тут в том, чтобы “отсоединить” данные от конкретных узнаваемых персон. Из-за обезличивания данных исследователи не имеют возможности ответить на вопрос, сколько у конкретной узнаваемой персоны объектов, обозначенных шарами. Ну, пока что не имеют такой возможности.

Теперь представьте, что начинается следующая итерация: персона A передаёт персоне B один свой объект. Можно считать, что передаёт шар, но при этом не раскрывается цвет шара. Тем не менее, факт обмена исследователям известен, поскольку именно для определения того, как “распределяются ресурсы”, подобные исследования и затеваются. Чтобы обновить данные – применяется всё тот же метод анонимизации. Соответствие цветов, конечно, выбирается новое, и информация о нём тоже уничтожается после распределения шаров.

Теперь в урне 10 красных шаров, 13 синих и 28 зелёных. Думаю, уже всё понятно.

Исследователи ведут архив. Так что у них теперь две выборки: до передачи шара и после. Поэтому-то вся “анонимизация” вдруг исчезла, так как в одной из выборок один шар поменял “цвет” (и не важно, что он мог его реально сохранить, поскольку применялась рандомизация цветов – сопоставить цвета между выборками нетрудно). Поменявший цвет шар – это и есть тот шар, который поменял владельца. А значит, исследователям теперь известно, кому из персон принадлежит каждая выборка шаров по цвету, в том числе, с историей. Ошибка схемы анонимизации тут в том, что обезличивалось владение объектом, но вовсе не факт смены владельца. Переход шара между выборками – никак в этой схеме не маскируется. Вот если бы в каждом цвете всегда было одинаковое количество шаров – но, погодите, а что бы тогда исследователям исследовать?

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

Ещё один хороший пример, регулярно всплывающий, это обезличивание “геопривязки”, о чём я писал ещё в 2009 году.

Как я уже в этом году упоминал, dxdt.ru – двадцать лет. В 2024 году. И как домену, и как веб-сайту. Опубликовано 3147 записок, если верить статистике WordPress.

С Интернетом я непосредственно столкнулся несколько раньше, чем запустили глобальный веб, так что есть и разработанные мной сайты постарше dxdt.ru. Некоторые из них выигрывали призы конкурсов, а некоторые я даже продолжаю поддерживать в доступности (да, и домены тоже есть постарше). Но вот только на dxdt.ru всё это время, в более или менее регулярном режиме, я продолжаю что-то сам публиковать. Что-то вроде блога всё это время более или менее здесь работает. Да, “более или менее” – тут не просто так: случались и достаточно длительные интервалы заморозки, но всё же.

Сайт dxdt.ru изначально, в 2004 году, выходил в другом формате: тут были небольшие заметки о разных научно-технологических новшествах или разработках, сопровождавшиеся картинкой. В принципе, я даже нашёл резервные копии – так что можно было бы добавить публикации в архив текущего сайта (естественно, что-то нетрудно обнаружить в глобальном веб-архиве, пока он ещё цел). Но, думаю, подобная модификация будет лишней: пусть действующий архив сайта так и идёт с 2006 года. А с 2006 года он идёт потому, что где-то в 2006 году я перенёс на dxdt.ru записки из своего блога в ЖЖ (“Живой Журнал”), сделав, в дальнейшем, dxdt.ru основным ресурсом для таких публикаций.

Двадцать – не самый интересный вариант, но для таких целей принято выбирать числа, записи которых оканчиваются нулями (в десятичной системе), а за прошедшее время многое изменилось, так что я что-то даже и не уверен, удастся ли мне сохранить dxdt.ru (как домен в глобальной DNS). Пока, так сказать, смотрим.

Лучшая записка за всё это время, по моему мнению, как автора: «О визире и слоне».

А есть и подборка других избранных записок.

Диалог.

– В разных частях города расположились пятьдесят четыре человека. Они тянут из хорошо перемешанной колоды игральных карт одну произвольную, случайную карту. Это обычная колода из пятидесяти четырёх карт. В ней два джокера. Какова вероятность, что хотя бы двое тянущих вытянут джокера?

– Сто процентов.

– То есть, примерно, сто процентов, так?

– Нет. Точно сто процентов. Единица.

– Почему?

– А это одна и та же колода. Её перевозит с места на место человек, который и предлагает вытянуть карту.

– В задаче про это ничего нет.

– Люди, тянущие карты, никак не связаны с сутью вопроса? Зачем тогда ставить такую задачу?

– Ладно. Сформулирую иначе: пятьдесят четыре человека в разных частях города одновременно тянут карту из колоды. Какова вероятность, что хотя бы двое вытянули джокера?

– Сто процентов. Единица.

– Опять?

– Они одновременно тянут карту?

– Да.

– Если одновременно, то значит события опять связаны. Иначе не было бы никакого смысла говорить, что “одновременно тянут”. Задача иначе получается бессмысленной. Так что это всё равно одна и та же колода, но у неё теперь много воплощений. По странному условию задачи. Видимо, подобную странность можно допустить – задача от этого станет более математической.

– Как может одна и та же колода быть в разных местах города одновременно?

– Но так сказано в задаче.

– Нет там ничего такого: в задаче сказано, что одновременно и в разных местах города.

– Вот. Я же говорю: колода одновременно в разных местах, по условию задачи.

– Не-е-т! Это же я такие условия добавил, чтобы исключить возможность перемещения колоды. Тут заведомо разное местоположение. И, следовательно, разные колоды.

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

– Но нигде не сказано, что из одной колоды!

– Как же не сказано? Всё сказано. Одновременно же тянут? Значит, это одна колода.

– Они тянут из разных колод.

– Какая тогда разница? Как можно говорить про одновременность и спрашивать про “общую” вероятность вытянуть карту, если это разные колоды? Что-то вроде: двое шли по дороге, один – через Мохаве, а второй – через Сахару. Какова вероятность, что в прошлом году они в четверг участвовали в санкт-петербургской лотерее?

– Какой-то абсурд.

– Поэтому-то колода – одна, хоть и виртуальная, взятая относительно всех событий вытягивания карт. В конце концов, именно так работает некий квантовый эксперимент с неравенствами Белла.

– Теперь ещё и квантовая механика. Нет. Тогда строго потребуем, чтобы колоды были разные. Не важно, виртуальные там, реальные. Разные. Карты тянут из разных колод, а мы хотим определить, какая такая вероятность, что хотя бы двух джокеров вытянули.

– В колоде пятьдесят четыре карты, верно?

– Да. В каждой колоде.

– Пятьдесят четыре человека?

– Да. У каждого своя колода. Каждый взял её со своей полки.

– Значит они вытянут все карты. Кому-то достанется джокер, и ещё кому-то – другой джокер.

– Не-е-т. У каждого. Своя. Колода.

– Это очень сложно понять. Допустим, если так, то двух джокеров никто не вытянет, потому что каждый вытянет только одну карту из своей колоды и они, соответственно, не могут одновременно тянуть карты, кроме того, нельзя сравнивать джокеров из разных колод.

– Уже лучше. А какая тогда вероятность, что один тянущий вытянет джокера с первой попытки?

– Одна пятьдесят четвёртая.

– Отлично. А теперь – одновременно тянут пятьдесят четыре человека из разных колод. Какая вероятность?

– Сто процентов: кому-то обязательно достанется джокер.

– Как так может быть?

– Ещё раз: из разных колод невозможно одновременно тянуть карты. Пятьдесят четыре человека могут одновременно что-то тянуть только из одной колоды. Им может казаться, что колоды разные. Вспомни про квантовую механику, эксперименты и неравенства Белла. Тут важно событие вытягивания карты: раз это, как бы, одновременное событие, то и колода может быть только одна. Это же очевидно. Одновременность подразумевает связь между событиями. Тем более, если это одновременность, установленная в противоположность перемещению в пространстве. Связь возможна тогда, когда колода одна и та же, но она только кажется разными колодами, потому что эти пятьдесят четыре человека так видят. Они так видят из-за того, что оказались в разных местах города. Или думают, что оказались в разных местах. Они, получается, видят только срез общего хода вещей – ну и вот им кажется, что это разные колоды. Но они не могут вытянуть одинаковые карты – свойство колоды такое, что каждому достанется своя уникальная карта. Хорошо, предположим, для уточнения локальной логики, что эти колоды ощущаются разными – такие вот “условные колоды”. Тогда то, что кто-то вытянул десятку пик, означает, что из всех остальных “условных колод” десятки пик исчезли. Уф! Так понятно?

– Но ведь стоит лишь посмотреть на карты, чтобы убедиться, что десятки в других колодах остались!

– Именно. Однако, как только кто-то из участников посмотрел в колоду карт, тем более, в условную чужую, задача стала совсем другой. Теперь исходная колода расщепилась на две, на два десятка, может, на большее количество колод. Но если они смотрят на карты в колоде, то как же можно говорить, что все эти пятьдесят четыре человека тянут случайную карту? Совсем другая задача: вытянули карту, чтобы посмотреть, какие остались.

– Не всё ли равно? Каждый и так может вычислить, какие карты остались в колоде, после того, как десятка пик ушла. Это нетрудно.

– Нет. Не всё равно. Раз задача про “общую” вероятность, то, выходит, в какой-то момент участники эксперимента должны показать карты из своих “условных колод”, сравнить и договориться, что именно они видят. Это уже задача про наблюдения и договорённости.

– Вернулись к тому, с чего начали. Пусть они тогда вытянут уже каждый свою карту из своей колоды, а потом встретятся, сравнят и посчитают те карты, которые в колодах остались. Какова вероятность, что не будет хватать хотя бы двух джокеров?

– Сто процентов. Единица.

Кстати, ECH для TLS я достаточно подробно, – но, вместе с тем, популярно, – описывал в отдельной статье на сайте ТЦИ в 2021 году. Описание там дано в контексте развития “этих интернетов”, начиная от ESNI, что, на мой взгляд, весьма полезно.