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

Домен t.me, похоже, разделегирован. Этот домен широко используется в инфраструктуре вокруг Telegram, в качестве носителя “коротких ссылок”.

(Update, 14/07/2026: делегирование вернули, спустя, примерно, 16 часов.)

Ковёр из Байё (или гобелен – как больше нравится, потому что ковры тоже на стену вешают) – недавно доставили в Великобританию из Франции. Знаменитый ковёр будет выставляться в Лондоне, в Британском музее (первая партия билетов уже распродана).

Ковёр представляет собой летопись нормандского завоевания Англии, и эта летопись изложена в оригинальных картинках, начиная с подготовки экспедиции и заканчивая описанием битвы при Гастингсе – всего около 70 метров иллюстрированной ленты исторических событий. Техника изображения тоже редкая: аппликация с “контурной” вышивкой.

Скорее всего, ковёр изготовили в Англии, более девяти столетий назад, – то есть, это была другая Англия, не современная, – а потом достаточно быстро перевезли во Францию, где он, в основном, и находился все эти долгие годы.

А теперь ковёр вернулся на землю страны своего происхождения. Считается, что временно. Во Франции многие были против того, чтобы столь уникальный ковёр отправлять к истокам. Тем более, что ковёр прямо посвящён важнейшему для истории Англии событию 1066 года. Потому что – ну, правда, мало ли что может приключиться? Ковёр очень старый, уже ветхий, может испортиться в ходе поездки. Хуже того, ветхость ведь может послужить и основанием для задержки возвращения ковра, потому что в Лондон-то ковёр, вроде, доехал без видимых проблем, но ведь каждая поездка – это большой риск.

Что ж, этого следовало ожидать: пишут, что вот и серверные IP-адреса хостинги должны будут раздавать через ЕСИА. Ну, будет очередной повод закрыть остатки сайтов, которые я поддерживаю. Похоже, что и с электронной почтой будет трудновато. Часть сайтов, кстати, что были в .RU/.SU, я уже и так закрыл; но dxdt вот пока перенёс на dxdt.blog. Однако, скорее всего, следующим шагом будет обязательное размещение какого-нибудь JS-кода счётчика на веб-страницах и тому подобные штуки. Поэтому, видимо, не долго-то осталось, так или иначе.

Хотя, в принципе, Интернет уже закончился и так.

Пишут (англ.), что SpaceX запустили сегодня в ближний космос полусекретный проект, но с секретным возвращаемым блоком (см. картинку), который блок должен быстро доставлять “груз” в произвольную точку на поверхности Земли. Всё под говорящим названием Starfall.

(Размеры возвращаемого блока или спускаемого аппарата. Credit: SpaceX.)

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

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

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

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

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

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

Этот уровень приложений, как ни странно, очень технологичен. Но речь тут вовсе не про “используй фреймворк “Имярек”, чтобы лучше адаптировать агентов типа John Doe”. Нет. “Фреймворк и агенты” – это технологии, но не технологичность. Технологичность скрывается за процессом контроля над способом применения технологий. Если на примере инфраструктуры УЦ: сейчас кругом только и слышно, что про ACME и его использование – это про протокол автоматического заказа и получения TLS-сертификатов. Но реально ли речь всегда идёт о протоколе? Оказывается, нет. ACME – весьма заумный и развесистый протокол. Мало кто читал спецификацию, мало кто его понимает. Оказывается, что в большинстве случаев использовать хотят не протокол, а некий готовый продукт, популярную утилиту или библиотеку на основе ACME. Например, хотят не ACME, а чтобы работали certbot или acme.sh, а также и какой-нибудь ещё фреймворк. Вот эта зависимость – и есть технологичность, а не просто технологии.

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

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

Использование хеш-деревьев в TLS-инфраструктуре веба, в TLS-сертификатах, обусловлено переходом на постквантовые криптосистемы цифровой подписи. Тоже хороший пример. Возможно, что в некоторый момент ведущие разработчики браузеров скажут, что браузеры больше не считают стойкими и надёжными сертификаты, выпущенные без постквантовой криптосистемы, а соответствующие веб-сайты – будут отображаться “как небезопасные”. Сложно ли такое представить? Конечно нет. Это вполне логично – устаревшие технологии в какой-то момент оказываются слабыми, браузер должен их блокировать тоже – какие могут быть возражения? Такое уже несколько раз происходило, и с DSA, и с SHA-1, и с длительностью действия сертификатов, и так далее, и тому подобное.

Ещё раз подчеркну – хитрость в том, что, действительно, устаревшие криптосистемы теряют стойкость, это без всякого сарказма. А вот уже с длительностью действия сертификатов – есть разные точки зрения, как говорится. Но Google в браузере Chrome даже не собирается поддерживать постквантовые криптосистемы подписи сертификатов, кроме как в варианте с хеш-деревьями (MT-сертификаты). Так что токены доступа – станут токенами доступа, и эта роль не зависит от типа носителя.

Нужен ли практический квантовый компьютер для того, чтобы объявить имеющиеся “не-постквантовые” криптосистемы подписи нестойкими? Нет, не нужен. Достаточно описания алгоритма Шора и непрекращающегося потока публикаций из тех же ведущих технологических корпораций о том, что необходимый прогресс на пути к квантовому компьютеру – велик и неуклонен.

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

Пишут (id: 65656, между прочим), что Let’s Encrypt добавили в своё соглашение пользователя пункт о соблюдении санкционного режима США (и других “подходящих” стран). Из исходного документа очевидно, что ограничения распространяются так же просто на “рядовых жителей” (ordinarily resident) подсанкционных территорий. Это не то чтобы совсем “новелла”, но для Let’s Encrypt выглядит неожиданно. Но в соответствующем подпункте, который про жителей, речь пока только о территориях и странах, находящихся под полным “эмбарго” США – comprehensive U.S. sanctions. Занятно, что термин “ordinarily resident” – обозначает всякого, кто фактически проживает на заданной территории, то есть, это очень широкое понятие.

Кроме того, в правила добавлены явные и бесспорные упоминания подсанкционных “компаний и субъектов” – им нельзя сертификаты и нельзя “в их интересах действовать”. Санкции сейчас раздаются очень массово, так что, в принципе, с использованием сертификатов “свободного УЦ” Let’s Encrypt возникают большие трудности. Но не у всех, понятно – ибо сам-то этот УЦ позиционируется как “для всех”: “Encryption for Everybody” – написано на первой странице сайта очень большими буквами, но тут нужно понимать, что и кто именно составляют множество этих body. (Оговорка: на dxdt.blog используется TLS-сертификат от УЦ Let’s Encrypt, поскольку это пока что единственный вариант из “хорошо известных УЦ”, который мне всё ещё доступен; долго ли ещё будет доступен? что отберут раньше – домен или сертификаты? Пока что нет ответа.)

Занятно и то, что многие пересказывают версию, по которой, мол, Let’s Encrypt (LE) тут просто “закрепил в правилах уже действовавшую практику” – нет, это не так: раньше в LE отказывали в выпуске сертификатов для конкретных имён, прямо указанных в конкретных списках, поскольку в США установили специальное исключение из санкционного режима, касавшееся “этих ваших интернетов” – в узких кругах соответствующий юридический “казус” известен как “поправка имени Cisco”. Новое дополнение в правилах LE – позволяет применять расширенные основания для “ковровых” отказов и отзыва сертификатов. Естественно, просто так подобные изменения в правила не вносят. Если бы LE стремились бы сами что-то такое применять, то вписали бы раньше. Но раз вписали сейчас, то, очевидно, с целью прямого применения, потому что были какие-то внутри возражения, сомнения, зацепки. Посмотрим. (Есть небольшой шанс, что откатят, но реально небольшой.)

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

И действительно, это, оказывается, не шутка: в исходной публикации присутствует гистограмма, на которой показан прирост количества кода (в строках), в восемь раз (8x). Надо сказать, там же, прямо под гистограммой, сказано, что, мол, показатель этот – количество строк кода, – не идеален, и он “точно преувеличивает реальный рост производительности (инженеров)”, но всё же показатель растёт, а поэтому – используем. Цитата с объяснением причины роста:

В Anthropic, вознаграждение сотрудникам рассчитывается не по количеству строк кода, которые они написали; напротив, участники команды выдают больше кода просто потому, что они используют ИИ-системы, чтобы писать больше кода. (At Anthropic, we don’t reward people for how many lines of code they write; rather, team members are producing more code simply because they’re using AI systems to write more code.)

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

Казалось бы – во всякой распределённой информационной системе, работающей под высокой нагрузкой, резкое увеличение скорости роста кодовой базы – однозначно плохой знак: зачем, для чего весь этот дополнительный код? кто будет его разгребать? Риторические вопросы.

Рассмотрим простой код на языке Python:

digital = list(map(lambda t: t, range(1, 11)))
print (digital)

Программа распечатает массив от 1 до 10. Другой вариант, более разумный, но чуть меньше кода:

digital = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
print (digital)

Тот же результат на печати, но мало строк! Воспользуемся кодо-генератором и сделаем иначе:

# Use bracket comprehension to declare an empty list
digital = []

# Append basic unit at zero index
digital.append(1)
# Create the second number
digital.append(digital[0] + digital[0])
# Create the next number
digital.append(digital[1] + digital[0])
# Create the number four
digital.append(digital[2] + digital[0])
# Create more numbers
digital.append(digital[3] + digital[0])
digital.append(digital[4] + digital[0])
digital.append(digital[5] + digital[0])
digital.append(digital[6] + digital[0])
digital.append(digital[7] + digital[0])
digital.append(digital[8] + digital[0])
# Print it out
print (digital)

Ну вот, результат – вроде бы тот же, однако совсем другое дело в коде: количество строк возросло в несколько раз, выглядит солидно. (Обратите, кстати, внимание, что этот вариант – он ещё и строит начало натурального ряда почти что в аксиоматике ZFC.)

Это, конечно, юмористический пример. Однако исходная публикация – вполне реальная, как ни странно. Так что ИИ-хайп действует. Посмотрим, что дальше.

Очередная декларация – The Leiden Declaration, – на тему проблем “влияния ИИ”, в этот раз – проблем влияния на социальные аспекты теоретической математики. Речь там про “коммерческие системы LLM”, продвигаемые ведущими корпорациями (типа, когда публикуют очередной пресс-релиз, что “GPT решили старую задачу Эрдёша”).

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

В Калифорнии (США) продвигают местный закон (статья в The Register, англ.), который, если его примут, обяжет встроить в процесс подготовки моделей для 3D-печати некий “детектор моделей огнестрельного оружия” – то есть, чтобы автоматически запрещалась печать на 3D-принтере, если пользователь “что-то не то” пробует распечатать. Естественно, речь пока про огнестрельное оружие идёт из-за того, что, мол, можно напечатать условный “призрачный револьвер”. Но логика запрета построена на совсем другом моменте: предлагается вести некий центральный реестр запрещённых к печати моделей; а программное обеспечение (ПО), подготавливающее модель к печати, должно с базой сверяться, получать разрешение на подготовку.

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

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

Кстати, занятно: ещё в 2016 году SpaceX обещали, что не позднее 2018 года доставят тяжёлый аппарат на Марс, в качестве первого шага марсианской программы SpaceX.

Это, конечно, и тогда-то выглядело очень сомнительно (о чём и написано в записке по ссылке). Десять лет прошло с 2016 года, но что-то именно в SpaceX марсианскую программу не развили совсем, аппаратов-роботов от этой корпорации на Марсе нет и сейчас, что уж там говорить про 2018 год. Зато сильно развили в SpaceX военную спутниковую низкоорбитальную группировку – Starshield, – которая работает на базе Starlink. Оно и понятно: от мифического строительства городов на Марсе толку нет, кроме как при использовании в качестве схемы прикрытия.

В СМИ подтверждают (англ., со ссылкой на US Space Force), что SpaceX со Starshield/Starlink официально достался контракт на запуск спутниковой сети обмена данными для военных применений. Естественно, такая сеть работает на низкоорбитальных космических аппаратах. Процитирую прошлогоднюю записку по этой теме:

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