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

Сообщают, что “Яндекс” в своих навигационных приложениях начал как-то учитывать влияние спуфинга GPS, используя дополнительные данные (WiFi и пр.). Кстати, я в 2018 году писал, что “центральный сервер мог бы определять наличие GPS-спуфинга на основе анализа данных, поступающих от множества устройств”. Вообще, не ясно, занимается ли чем-то таким сервис “Яндекса”, но если у вас есть множество устройств и центральная точка сбора данных, то можно разные интересные вещи измерять.

Так, навигационное поле, формируемое гражданским сигналом GPS, можно достаточно точно рассчитывать для произвольной точки поверхности Земли, в том числе, с опережением или отставанием по времени. Для этого не нужно устанавливать приёмник в той точке, для которой выполняется моделирование. Да, тут необходимо подчеркнуть, что это всё за вычетом искажений, вносимых постройками и пр. – но, собственно, в этом и состоит интересная часть. К сожалению, от обычного смартфона не удастся получить детальной информации о сигнале GPS, как его видит приёмник, но, тем не менее, часть данных, коррелирующих с сигналом, всё же приходит. Смартфон может дополнительно собирать сведения о сигналах WiFi, о GSM, о передатчиках Bluetooh (и не только). Так вот, если у вас есть устройства “на местах”, которые приносят дополнительную информацию, а не только “координатные данные” GPS, то можно на центральном сервере выстраивать динамику изменения реального навигационного поля по сравнению с моделью, учитывающей только положение и состояние спутников. Это позволяет не просто получить корректирующую величину для всех участников системы, но также увидеть возникающие на местах пространственные дефекты и искажения с развёрткой по времени (то есть, не просто спуфинг), что весьма ценно.

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

На скриншоте ниже – результат работы нехитрой программы на языке Python, которая вычисляет в точке x == i (мнимая единица) значение функции, известной как j-инвариант – j(x).

j(x) – это модулярная функция, которая важна, например, в теории эллиптических кривых, но в настоящей заметке теоретические детали не играют существенной роли. Значение j(x) для мнимой единицы – это целое число 1728 (в каком-то смысле, по определению). А 1728 == 12^3, что тоже не является простым совпадением, так как 12 == 2^2 * 3. Можно j(x) записать в виде бесконечной суммы (разложение Фурье или q-expansion, если хотите, где q == exp(2*π*i*x)), что и используется в программе: j(x) == q^(-1) + 744*q^(0) + 196884*q^1 + 21493760*q^2 + 864299970*q^3 +… Коэффициенты – целые числа.

Поскольку модулярные формы имеют большое значение в арифметике, коэффициенты из разложения j-инварианта проявляются в математике довольно неожиданным образом, порождая даже отдельные направления (как в случае “Чудовищной бурды” – Monstrous Moonshine, самогон, который в русскоязычной “Википедии” едва не превратился в “Монструозный отблеск”). Но это тема для другой записки, более подробной. Здесь же отметим, что так как коэффициенты – целые числа, можно взять их побольше (например, 42) и посчитать значение j(x) “численными методами”, проверив, сойдётся ли, и насколько быстро, результат. Понятно, что если в выражение для q (см. выше) подставить x == i, вместо i*i получится -1, что и делает каждый очередной элемент суммы всё меньше и меньше, несмотря на увеличивающиеся коэффициенты.

Однако здесь есть хитрости. Если использовать обычные настройки Python, то точности для вычислений не хватает, результат не сходится. Если взять math.exp() и math.pi, точность по умолчанию, получаем 1728.000000000000014825929946, причём ещё на 13 шаге суммирования – не очень-то хороший результат: больше чем 1728. Увеличение точности само по себе тут не помогает, нужно использовать модуль decimal и ввести достаточно длинные значения для π и e, заменив math.exp() и math.pi на Decimal(E**(Decimal(-2)*Pi))**n, где E и Pi – значения со многими знаками после запятой. Точность в decimal устанавливается при помощи getcontext().prec. Результат со скриншота получен для prec = 81 в Python 3.5. Всё это хорошо иллюстрирует, что компьютеры не считают в действительных числах.

Исходный код (проверьте, что символы табуляции не были “съедены” так же, как и некоторые цифры десятичного разложения):

from decimal import Decimal, getcontext
getcontext().prec = 81
Pi =	Decimal('3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982')
E =	Decimal('2.718281828459045235360287471352662497757247093699959574966967627724076630353547594571382178525166427427')
M = [
1, 744, 196884, 21493760, 864299970, 20245856256, 333202640600,
4252023300096, 44656994071935, 401490886656000, 3176440229784420,
22567393309593600, 146211911499519294, 874313719685775360,
4872010111798142520, 25497827389410525184, 126142916465781843075,
593121772421445058560, 2662842413150775245160, 11459912788444786513920,
47438786801234168813250, 189449976248893390028800, 731811377318137519245696,
2740630712513624654929920, 9971041659937182693533820, 35307453186561427099877376,
121883284330422510433351500, 410789960190307909157638144, 1353563541518646878675077500,
4365689224858876634610401280, 13798375834642999925542288376, 42780782244213262567058227200,
130233693825770295128044873221, 389608006170995911894300098560, 1146329398900810637779611090240,
3319627709139267167263679606784, 9468166135702260431646263438600, 26614365825753796268872151875584,
73773169969725069760801792854360, 201768789947228738648580043776000, 544763881751616630123165410477688,
1452689254439362169794355429376000
]
j = Decimal(0)
n = -1
for c in M:
	j = j + Decimal(c) * Decimal(E**(Decimal(-2)*Pi))**n
	print("j = ", j)
	n = n + 1
print("j^(1./3) =", float(j)**(1./3))

На сайте ТЦИ опубликована моя статья о том, как и почему можно использовать “TLS по ГОСТ” и “обычный TLS” параллельно для веба.

“Демультиплексирование” на общем номере порта TCP протоколов более высокого уровня (TLS/XMPP/SSH и т.п.) при помощи сигнатур начальных пакетов, описываемых регулярными выражениями, имеет и особенности “в другую сторону”: всё, что можно на уровне сокета разобрать (статическим) регулярным выражением на стороне сервера, можно быстро разобрать регулярным выражением и на стороне системы DPI. Естественно, в модели, приписывающей существенный вес номеру порта TCP в классификаторе протоколов, такой программный демультиплексор на серверной стороне был бы достаточно эффективен, но в более широком понимании – метод слишком далёк от стеганографического.

Бывают контринтуитивные решения, бывают контринтуитивные в квадрате, но многое тут зависит от того, как преподносят модель “интуиции”. Пример из области, близкой dxdt.ru: вычисление общего секрета по протоколу Диффи-Хеллмана. Первый уровень контринтуитивности тут традиционно описывается так: нужно получить общий секретный ключ через открытый канал, но это “невозможно”, поскольку – как же передать секретный ключ по открытому каналу, чтобы никто не увидел? “Интуитивные” хитрости тут скрыты в понятиях “получить” и “передать”.

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

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

В мае 2023 на dxdt.ru вышло достаточное количество записок, чтобы некоторые из них отметить отдельно, а именно:

• Исчезновение “фрагментации Интернета” с разных точек зрения;
• Перспективный ИИ в “разработке кода”;
• Технократический аспект Нового Средневековья;
• Несколько комментариев “около 3d-печати”;
• Алгоритм Шора и Вселенная кубиками.

(А кроме того – внутренний идентификатор, привязанный к добавлению заметок, перевалил за 10000; но это просто технический идентификатор, количество заметок в базе dxdt.ru на данный момент существенно меньше: 2,732.)

Из недавней записки цитата про ИИ:

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

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

Mitigating the risk of extinction from AI should be a global priority alongside other societal-scale risks such as pandemics and nuclear war.

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

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

(via)

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

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

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

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

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

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

Ключевым моментом эффективности DMARC является не состав политики, а то, поддерживается ли DMARC принимающим сервером, а если поддерживается, то как именно. Сама по себе публикация сведений DMARC не обязывает принимающий сервер не только следовать опубликованным политикам, но даже и запрашивать их из DNS: для приёма и обработки сообщений это не требуется (как не требуется и возможность обработки DKIM). Конечно, грамотно настроенный сервер должен обрабатывать и DKIM, и DMARC, однако такая настройка вовсе не обязательно означает, что письмо без DKIM будет молчаливо отброшено, если принимающий сервер обнаружит политику reject в DMARC. Другими словами: DMARC носит более чем рекомендательный характер, поэтому целиком полагаться на указание политики обработки нельзя.

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

Там присутствует буква ипсилон, снабжённая, кроме знака акцента, двумя “точками” (нет, это вовсе не смайлик). Эти две “точки” называются “трема” (или “диерезис”) и вполне себе используются при записи древнегреческого (и даже английского, см. ниже), обозначая разделение гласных. Однако в данном случае дело явно хитрее. В современной типографике соответствующий фрагмент (середина второй строки) выглядит вот так: μετὰ τὸν πρῶτον ὕπνον, что означает “после первого сна”. Над ὕ должен быть знак придыхания, а на рукописном скриншоте знак ударения присутствует отдельно (сверху), соседних гласных нет, так что назначение второй “точки” не ясно. Тем более, что в этом же манускрипте в других сходных случаях двух точек над υ обычно нет, но иногда – встречаются. Это известное, – но какое-то загадочное, – явление, относящееся ещё и к букве ι в манускриптах на древнегреческом. Кстати, “сон” здесь – это тот самый “гипноз”: знак придыхания над ὕ, который объясняет одну “точку”, как раз трансформировался в русское “ги”. А в английском, например, hypnosis.

Трема/диерезис встречается при записи английского, но является большой экзотикой, о которой мало кто знает. Собственно, “Ё” даже в русском-то сейчас используют редко, зато аналогичное, редкое, сочетание знаков есть в английском. Посмотрите: coöperate, сöworker и reëlect. Здесь трема как раз делает “отделяемым” звук, обозначаемый второй буквой. Этот знак тут нужен для того, чтобы не было reel в reëlect и “коровы” (cow) в co-worker. Сейчас, конечно, приём считается устаревшим, а компенсировать можно дефисом.

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