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

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

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

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

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

Пишут, что под Android браузерные скрипты “Метрики” от “Яндекса” и Pixel от Facebook (принцип тот же) идентифицируют посетителя веб-страницы, обмениваясь токенами с собственным приложением на localhost. Приложение, понятно, должно быть “родственным”: либо от Facebook, либо от “Яндекса” (для каждой корпорации – своё).

Механизм: приложение слушает номер порта на localhost, куда браузерный скрипт отправляет данные и получает ответ, идентифицирующий пользователя. Браузеры доступ не блокируют (дефект, по нынешним временам), а решение “Яндекса” использует ещё и технический домен, который с адресом 127.0.0.1 в A-записи – такой вот половинчатый “DNS rebinding” (это, впрочем, не редкость).

Немного странно, конечно, что этот метод авторы вообще обозначают как “novel tracking method” (то есть, “новый, оригинальный метод отслеживания”). Но, очевидно, подобное блокировать должны именно браузеры (у “Яндекса”, впрочем, есть собственная сборка Chrome/Chromium, которая, как пишут, тоже слушает дополнительный номер порта).

(via)

Отмечу отдельно некоторые записки, которые вышли на dxdt.ru в мае 2025 года:

• Переворот английских глаголов и пьесы Шекспира
• Тавтологические формулировки как капчи
• Спутниковые сети и их преимущества
• Шимпанзе на дереве и вертолёты вокруг
• Отслеживание и геолокация чипов GPU

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

Сервис ТЦИ audit.statdom.ru, позволяющий в онлайн-режиме проверять настройки интернет-узлов, теперь не в бета: новая версия – v.1.0. И в новой версии добавлено, кроме прочего, отображение данных по SCT-меткам в TLS-сертификатах веб-узлов: выводится таймстемп, оператор лога, название лога, данные о криптосистеме.

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

А как такая технология отслеживания могла бы работать? Напрашивается вариант, когда сама условная “видеокарта” устанавливает соединение с удалённым сервером через Интернет. Независимые и от ОС, и даже от прочего оборудования в том же компьютере-носителе, системы удалённого доступа давно известны: IPMI и пр., с выделенной операционной системой и независимой “одноплатной” аппаратурой (SoC). В случае с видеокартой – если доступа к центральному серверу нет, то прошивка не работает. Токены, разрешающие работу, можно привязывать ко времени, например. Дальше возникает вопрос, как на стороне сервера определить положение чипа, прошивка которого прислала запрос. Можно встроить в чип приёмник GNSS (GPS) и передавать координаты. Однако приём сигнала спутниковых систем не отличается надёжностью, компьютер с видеокартой может быть установлен в подвале. Хотя, это уже проблемы потребителя – пусть он антенну выставляет на окно, что ли. Впрочем, координаты возможно подспуфить (но не всегда). С другой стороны, в качестве GNSS можно использовать сети спутников связи по типу Starlink, что понадёжнее.

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

Всё же, более эффективен какой-то гибридный метод, учитывающий и GNSS, и сетевые задержки, и, скажем, локальную электромагнитную обстановку: кто сказал, что не стоит добавить сюда WiFi и базовые станции GSM?

Давно собирался написать о том, как ИИ/LLM может сыграть в условиях Нового Средневековья, способствуя замещению знаний о технологиях представлениями (в стиле выдачи LLM) о ритуалах, связанных с этими технологиями. Вчера опубликовал текст по этой теме на “Хабре”.

Опубликовал на “Хабре” небольшую статью с разбором примера того, как современные мощные LLM успешно обрабатывают хитрые транслитерации: в качестве иллюстрации я там использую ChatGPT и “промпт”, в котором на английском запрашивается перевод фразы с итальянского на русский, но всё записано греческими буквами.

Очередной пример усиленной сегментации этих вот интернетов: пишут, что Google заблокировал в своём удостоверяющем центре всю DNS-зону spb.ru, ссылаясь на штатовские санкционные списки. Это, в частности, приводит к тому, что TLS на “веб-фронте” Cloudflare перестал работать для адресов в spb.ru. Со списками – не очень понятно: официальное объяснение найти пока не удалось, но на форуме Cloudflare пишут, что, возможно, это из-за названия “СПБ Биржи” (SPB Exchange). Если так, то ситуация совсем печальная: мало того, что активно отключают доступ к веб-узлам, используя TLS и “исторически сложившееся” исключительное положение хорошо известных УЦ в браузерах и CDN-провайдерах, так ещё и Google адреса путает.

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

Google сообщает, что после 30 мая 2025 года “системы, использующие шифр 3DES для SMTP-соединений, не смогут доставлять электронную почту на аккаунты Gmail”. Про 3DES и SMTP-соединения – это буквально так и написано в исходном сообщении (“systems using 3DES for SMTP connections”). Но, насколько можно судить по прочим деталям, имеется в виду всё же TLS, а не непосредственно SMTP.

3DES – это схема использования очень старого симметричного шифра DES с подмешиванием дополнительных ключей, что повышает общую оценку стойкости до 112 бит (оригинальный DES – это 56 бит максимум; практически ничего, по современным меркам). Естественно, схема эта устаревшая, и безальтернативное её использование в 2025 году выглядит странно. Каких-то суперэффективных атак, полностью убивающих 3DES, пока не публиковалось, но 112 бит – это всего лишь 112 бит. И тем не менее, в почтовой системе может быть применена реализация TLS на уровне “хоть какой-то”, это всё равно лучше, чем передача в открытом виде.

С другой стороны – насколько это вообще критично для электронной почты, с точки зрения входных почтовых релеев сервиса Google? TLS для SMTP нужен, кто бы сомневался. Но, во-первых, то, что почту на сервер Gmail кто-то принёс через TLS, совсем не означает, что эта почта и на предыдущих этапах ходила только в защищённом виде. Во-вторых, сообщения всё равно обрабатываются в открытом виде на стороне Google. Тут важен баланс рисков. Так что единственная причина, которую можно придумать, это то, что исключается необходимость поддерживать устаревшие реализации элементов TLS на стороне Google, тем самым оптимизируется технологический стек. Это весьма логично. Однако те, кто не сумел поправить на своей стороне, больше не смогут доставлять почту в Gmail. То есть, теперь доставка почты отключается даже не только по наличию TLS (без TLS Gmail и так уже не принимает сообщения; точнее – не всегда принимает), но по наличию устаревшего шифра. Строгость растёт.

Есть и иной аспект. Если посмотреть на опубликованный список шифров, которые поддерживаются в конфигурации TLS на почтовых серверах Gmail, то станет ясно, что там, за вычетом 3DES, остаётся только AES и ChaCha20. При этом, если не использовать TLS 1.3, то остаётся единственный вариант – AES.