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

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

За несколько лет я написал некоторое количество полезных статей об интернет-технологиях на сайт ТЦИ, вот ссылки и краткие пояснения:

Certificate Transparency в современном Интернете
Статья о Certificate Transparency (CT). Это довольно техническая статья, которая, впрочем, рассказывает не столько о методах построения CT (про это и так много написано), сколько о не самых очевидных особенностях работы данной технологии на практике: полноте логов, реальному значению технологии в случае малого количества УЦ и т.д. (Отдельно рекомендую почитать, как весьма актуальную, и в стиле “на “Хабре” такого не пишут”.)

Сертификаты удостоверяющих центров TLS
Небольшая статья о том, какие и почему встречаются сертификаты УЦ.

Доступ к скрытым TLS-сервисам: Encrypted Client Hello
Encrypted Client Hello (способ сокрытия метаинформации в TLS) с примерами и описанием принципов построения, назначения, а также перспектив.

DNS в качестве инструмента публикации вспомогательной информации
Использование DNS-записей для публикации информации о настройках и свойствах других интернет-протоколов: типы DNS-записей, примеры и др. Речь про TXT для DKIM/DMARC, про SSHFP и подобные малоизвестные, но весьма полезные, записи.

DNSSEC: доверие по цепочке
Популярное описание DNSSEC, на которое можно ссылаться.

DNS-доступ под защитой: DoT и DoH
Принцип работы и способы применения технологий DNS-over-TLS и DNS-over-HTTPS, их место в общей “парадигме” инструментов защиты информации.

TLS 1.3 на веб-узлах Рунета
Количественная оценка распространённости узлов с корректно настроенным протоколом TLS версии 1.3 и валидным TLS-сертификатом в зонах .RU, .SU и .РФ. Данные актуальны на 2020 год.

Заголовки HTTP и их роль в обеспечении безопасности
Описание HTTP-заголовков, предназначенных для повышения безопасности доступа к сайтам. Content-Security-Policy и др.

ESNI как защита TLS от утечек метаинформации
Подробный рассказ про ESNI. Это 2019 год, с тех пор от ESNI отказались, но статья представляет исторический интерес.

Кстати, в продолжение долгоиграющего офтопика про цвет собак в “Илиаде” – соответствующий фрагмент (1.50, о том, что Аполлон сперва атаковал мулов и собак) из манускрипта Venetus A:

В современной “типографике”: οὐρῆας μὲν πρῶτον ἐπῴχετο καὶ κύνας ἀργούς. Обратите внимание, что подстрочная йота в ῴ написана справа от ω, а союз καί сокращён до значка, похожего на S. Сомнения может вызвать -ούς в конце предложения, но тут всё верно: это такой способ “оптимизированной” записи, в котором больше всего упростилась как раз буква ипсилон.

На исходном манускрипте немало комментариев (в частности, есть и комментарии между строк, буквально). А в комментариях пишут, в частности, что в цитированном выше фрагменте “неверно “быков/мулов” (οὐρῆας) полагать “охраной”, поскольку не совпадают они” (про охрану – это версия Аристотеля, довольно занятная). Есть и объяснение, что всякие лошаки слабые по своей природе, а среди собак – слабые белые, поэтому и те, и другие первыми пострадали от атаки Аполлона.

Между прочим, RSS остаётся одним из немногих полезных инструментов трансляции сообщений между сайтами и приложениями. Например, на dxdt.ru трансляция новых записок доступна по обычному и привычному адресу: https://dxdt.blog/feed/, что актуально во времена централизации по telegram-каналам (предположим) и разнообразным сервисам типа Facebook. Читать RSS можно разными способами. Я довольно давно использую удобное серверное решение – Tiny Tiny RSS. Уже писал про этот полезный пакет раньше, почти десять лет назад, но упомяну ещё раз, тем более, что он продолжает поддерживаться. Сейчас я использую вариант в docker-контейнере. TT-RSS работает без нареканий, есть даже отправка дайджеста почтой, а просматривать ленту сообщений можно браузером. Конечно, есть различные программы “стороны клиента”. Например, Akregator из KDE. Но серверное решение часто удобнее, на мой взгляд.

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

Попытаться построить квантовый компьютер на тысячи кубитов имеет смысл хотя бы для того, чтобы проверить, что имеющиеся модели работают для больших пространств состояний. Попытка факторизации 1024-битного числа на гипотетическом квантовом компьютере при помощи алгоритма Шора сталкивается с необходимостью как-то действовать в пространстве из 2^1024 состояний (ну, предположим). Влезет ли такое количество состояний во Вселенную? Насколько 2^1024 вообще большое?

Понятно, что какие-то прямые физические воплощения для такого числа придумать не получится, поскольку, например, 2^1024 несравнимо больше, чем масса Земли, подсчитанная в граммах. Но можно пойти на комбинаторные ухищрения. Нарежем пространство Вселенной на 2^80 небольших кубиков. 2^80 выглядит очень похожим на разные оценки “объёма Вселенной”, “количества частиц” и других сходных параметров. Перестановкой этих кубиков можно получать разные конфигурации Вселенной, которые, возможно, будут весьма сходными. Предположим, что количество конфигураций это (2^80)! (факториал, а не восклицание). “Реальный”, – что бы это ни значило, – показатель может быть другим: нужно учитывать возможности по сочетанию получившихся кубиков, их взаимное расположение. Однако для нашего примера это не важно.

Существенно ли (2^80)! превосходит 2^1024? Может показаться, что 2^1024 очень большое число. Однако провести сравнение нетрудно. Заметьте, что при вычислении факториала каждое чётное число повышает степень двойки (иногда – больше чем на единицу), поэтому 2^1024 вкладывается уже в 1026! (ну или примерно так; 1026 = 1024+2, проверьте; естественно, 171! больше 2^1024). Что уж говорить про (2^80)!! (Здесь второй восклицательный знак обозначает восклицание.) Теперь может показаться, что 2^1024 не такое уж и большое число, чтобы не вкладываться в качественно нарезанную Вселенную.

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

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

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

Сайт dxdt.ru сегодня (16/05/2023) несколько часов был полностью недоступен, к сожалению. Говорят, что “проблемы с сетевым оборудованием”. В итоге – всё же починили. Посмотрим, как будет дальше.

Чтобы придумать имя файла для архива, в котором будет сохранена резервная копия сайта, достаточно посмотреть в логи веб-сервера: /dxdt_ru.tar.gz, /dxdt-ru.tar.gz, /dxdtru.tar.gz, /dxdt.ru_backup.zip – и много других вариантов видны среди запросов ботов (впрочем, все получили ответ с кодом HTTP 404). Но, понятно, что насобирать такого по сайтам сейчас можно немало.

В быту 3D-принтер полезен тем, что можно напечатать разные уникальные изделия, “оптимизированные” для решения конкретной задачи. Например, я напечатал ремонтную деталь для блока кнопок управления автомобильным креслом: можно было бы заменить весь блок целиком (хорошо, что не кресло), но это потребовало бы снятия кресла – достаточно много работы. Это далеко не единственный пример. Так, из недавнего, я спроектировал и распечатал несколько установочных кронштейнов для крепления небольших солнечных батарей (для питания уличных светильников), кронштейн для установки самого светильника под скатом крыши, несколько элементов крепления видеокамер, немало коробок-корпусов для разных самодельных устройств вроде цифровых термометров и часов с GPS-коррекцией, несколько защитных кожухов для различных простых механизмов (вроде замка уличной калитки) и другие подобные изделия. Модели я готовлю в OpenSCAD, это очень удобно. Сейчас я в основном использую FDM-принтер Anycubic Mega X – о чём рассказано в отдельной заметке (с картинками). Этот принтер работает методом последовательного наплавления слоёв пластика, то есть, он состоит из нагреваемого столика, над которым перемещается печатающий узел с горячим соплом (“хотэндом”) экструдера.

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

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

Так вот, у всякого FDM-принтера, тем не менее, есть некоторая “степень нависания” слоя, которую принтер может распечатать без подпорок, если только соответствующая часть изделия “вырастает” из другой части, а не висит уж совсем отдельно. Это объясняется достаточно просто: если очередной слой лишь немного “свешивается” за край предыдущего, то свежий пластик успешно приклеивается к этому краю и не провисает, так как застывает достаточно быстро (тут главное не использовать ни слишком высокую скорость движения печатающего узла, ни слишком низкую). Это отлично работает как для резьбы, печатаемой вертикально, так и для других моделей (в принципе, можно даже печатать небольшие горизонтальные “прогоны”, на небольшой скорости). Что, собственно, и составляет один из методов оптимизации: углы “нависания” нужно проектировать так, чтобы принтер справился без подпорок. Да, это вводит ограничения на конструкцию изделия, поэтому может составить проблему, если использовать готовую модель. Однако если модель проектируется под конкретную задачу с нуля, этот момент можно учесть, что, в общем-то, является обычным технологическим аспектом разработки (не только в случае 3D-печати).

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

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

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

Оказывается, некоторое время назад в Google добавили занятную функцию в приложение для (так называемой) “двухфакторной аутентификации” (2FA), а именно – возможность восстановления “из облака” в случае потери устройства. Заметьте, что весь смысл “двухфакторной аутентификации” состоит в том, что подключающийся пользователь может доказать, что у него есть доступ к дополнительному секрету, кроме пароля, который могли и украсть. Естественно, этот дополнительный секрет может проявляться как “одноразовые пароли” или какие-нибудь PIN-коды, которые, например, генерируются в зависимости от текущего времени (и от значения секрета, конечно).

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

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.

Если при наборе термина “A-запись” использовать английскую раскладку (привычную), но ошибиться с выбором кнопки на клавиатуре по обозначению (кириллическая “А”), то относительно русской раскладки получится “F-запись”. Если раскладку не переключить, оставить русскую, но кнопку выбрать “обратную”, то получится “Ф-запись” (проверьте). Таким образом, данный термин содержит в себе некоторый хитрый антиомоглифический инвариант.