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

Кстати, в продолжение недавней заметки про то, что тип float – это не про числа, тем более, не про действительные числа. С точки зрения рекомендаций разработчику ПО.

Вообще, если получается, то никаких float и тому подобных инструментов лучше не использовать. Совсем. Тем более, в воплощении различных sin, cos и прочих. Заменять нужно таблицами целых (в смыcле int) значений и целочисленными, со строго фиксированной справа точкой, арифметическими операциями. Особенно, если речь о программировании систем управления и микроконтроллеров.

Если же не получается совсем отказаться, то есть эффективный способ правильно думать про float. Нужно переменные с типом данных float понимать как алгоритмы, и сравнение таких переменных интерпретировать как сравнение алгоритмов. Это помогает избежать многих ошибок (см. ниже).

Например, во float нет дистрибутивности. В алгоритмической интерпретации это означает, что выражения L := b*(c + d) и L := b*c + b*d – присваивают переменной L разные алгоритмы. И действительно, запись, в которой сперва вычисляется сумма (c + d), а потом результат умножается на b, это другой алгоритм, нежели вариант, когда сперва b умножается на d и b умножается на с, а потом вычисляется сумма результатов (обратите, кстати, внимание, что тут ещё и порядок играет важную роль: сначала b*c или сначала b*d? если с точки зерния параллельных вычислений эти операции могут быть выполнены “независимо” разными потоками, то с точки зрения компилятора, имеющего дело с вполне себе последовательной записью, всё может выглядеть сильно иначе – но это явно тема для другой записки).

Если не упускать этот алгоритмический момент из виду, то оступиться становится сложнее. Так, алгоритмическое восприятие float позволяет отбросить сомнения, что в двух описанных выше случаях из L можно достать разное битовое значение при одних и тех же входных переменных – алгоритмы-то там разные. Естественно, сравнивать алгоритмы сложно, но тут понятие об алгоритме – это лишь средство обобщения, мыслительный гаджет, но такой гаджет, который верно работает.

Лирическое отступление. Это раньше к компьютерными вычислениями подходили с нужной тщательностью и пониманием того, что такое преобразование погрешностей. Сейчас, оказывается, времена ИИ и LLM. Поэтому сказку сильно сократили. К сожалению, уже на практике полагают, что во float – действительные числа, “просто с погрешностью” (“просто”, да). Соответственно, получается, что конкретный математический аппарат, служащий основой проектирования алгоритмов ПО, оперирует действительными числами, синусами и косинусами – здесь всё со всем пересекается, всё максимально гладкое, а поэтому выполняются нужные равенства и теоремы существования. Потом математический аппарат прямо переносят в программный код. После чего, в один не самый ожидаемый момент, вычисления ломаются и предположим, аппарат космический улетает совсем не туда, куда предписывала гладкая и непрерывная модель с синусами и дистрибутивностью.

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

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

Гораздо важнее, что LLM в принципе не может ничего выводить, никаких ответов или распоряжений. Эти ответы/распоряжения формирует даже не тот, кто контролирует веса и иерархию коэффициентов в памяти, а тот, кто контролирует программу чата. Вообще не важно, что там происходит внутри LLM – ответ в чат может написать администратор системы. Этот администратор – будет человеком, как раз по причине дееспособности, которая упоминается выше.

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

Мессенджер Signal внедряет платное централизованное хранение резервных копий сообщений на своих серверах. Занятно, что Signal позиционируется как “безопасный мессенджер”. Впрочем, вряд ли какое-то из этих новомодных приложений не позиционируется как “безопасное” или “самое безопасное”.

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

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

Кстати, я в прошлом году писал про особенности хранения копий сообщений мессенджеров.

В Cloudflare выпустили разбор ситуации с выпуском неавторизованных TLS-сертификатов для 1.1.1.1. Пишут, что в логах Certificate Transparency (CT) эти TLS-сертификаты не обнаружили потому, что не отслеживались сертификаты для IP-адресов, в мониторинг приходило слишком много сообщений из CT, а также и не для всех доменов/ресурсов настроили отслеживание сертификатов.

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

В продолжение предыдущей заметки, про подозрительные сертификаты для 1.1.1.1, выпущенные УЦ Fina RDC 2020: интересно, что, согласно crt.sh, соответствующие пресертификаты есть и в CT-логах (Certificate Transparency) Cloudflare. Выпускать такие “странные” сертификаты в данном УЦ начали ещё в прошлом году. То есть, получается, что либо Cloudflare вообще не следит за именами из сертификатов даже в тех CT-логах, в которых является провайдером, либо это всё же по согласованию с Cloudflare выпущено. Естественно, последний вариант – ну уж совсем маловероятен, а вот в то, что Certificate Transparency не отслеживается – поверить как раз нетрудно.

Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).

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

Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).

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

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

Интересно, что сейчас применение маскирования IP обещают по списку доменов, который доступен на Github; в этом списке, на момент написания записки, значится почти весь “официальный” веб от “Яндекса” (yandex.ru, mc.yandex.com, yandex.st и др.), а кроме того: vk.com, mail.ru и прочие, хорошо узнаваемые в Рунете, доменные имена.

Пишут (англ.), что Google собирается для всех разработчиков приложений под Android на google-сертифицированных устройствах потребовать регистрацию аккаунта и регистрацию ключей подписи. Регистрация, конечно, должна быть в корпорации Google. Иначе приложения невозможно будет устанавливать (механизм реализации запрета пока не описан, но это ведь детали). Разработчик должен регистрироваться и получать разрешение даже в том случае, если приложение не распространяется через Google Play, а публикуется каким-то сторонним сервисом. Фактически, всё идет к тому, что самостоятельно разработанное приложение нельзя будет без регистрации аккаунта разработчика установить на самостоятельно же приобретённое устройство (такое вот очередное подтверждение того, что “собственный” смартфон вовсе и не принадлежит, как система, купившему его пользователю).

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

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

В статье Ars Technica (по ссылке выше) пишут, что Google, якобы, не планирует проверять само приложение (как в случае с Google Play). Но это вряд ли, что оно так будет. По крайней мере, в сопроводительных документах Google написано, что для бесплатных аккаунтов введут ограничения и по количеству приложений, и по количеству установок. Дело в том, что, технически, цифровой подписью всегда подписывается конкретная сборка (нельзя подписать произвольный идентификатор, который автоматически привяжется ко всем возможным вариантам – такого не предусмотрено). Поэтому и провайдер системного сервиса проверки вполне может регистрировать в центральном репозитории тоже только конкретные сборки, по отпечатку. А это эквивалентно проверке кода приложения: по результатам – можно отключить и аккаунт, и сами приложения удалить с пользовательских устройств.

Пишут про очередной фишинг с “омоглифом” в доменном имени. Там даже не просто омоглиф, а “омоглиф-лигатура”: то есть, символ, не входящий в обычный DNS-набор, подменяет сразу и косую черту, и “букву”, что позволяет построить имитацию URL в зоне booking.com (но зона там другая). Это, к сожалению, всё давно известные эффекты желания использовать Unicode там, где использовать Unicode не нужно. Я ещё в 2009 году описывал принцип построения таких фишинговых ссылок, и в той же записке привёл полностью рабочий пример с именем, имитирующим домен “проверка.рф” в зоне .РФ (самого .РФ тогда ещё не было в корневой зоне). Вообще, браузеры и другие клиенты должны выводить DNS-лейблы, записанные смешанными алфавитами, только в Punycode, латиницей, но, впрочем, это тоже полумера.

Современное объединение вычислительных IP-сетей, ранее известное как “Интернет”, обладает интересными особенностями, которые прямо связаны с практической трактовкой термина “сетевая прозрачность” разработчиками приложений.

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

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

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

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

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

Насколько подобные дежурные утверждения, – опубликованные, видимо, в качестве ответа на волну в СМИ, – будут соответствовать непростой реальности – это ещё нужно посмотреть, конечно.