Зачем ИИ-агенту разрешение эмитента или целого мастеркарда?
Из новости не ясно. Предположить можно следующее: все эти ИИ-агенты - это сервисы с центральным внешним управлением; соответственно, с точки зрения платёжной системы, корпорация "Имярек", массово тыкающая агентами через актуальные реквизиты и приложения пользователей в платёжную систему, выглядит как объект, нуждающийся в специальных соглашениях, иначе, технически, оно будет выглядеть очень похоже на фрод, что не должно нравиться ни "Имяреку", ни платёжной системе. А при наличии специальных доступов/договоров - история с классификацией транзакций и с возможными спорами будет совсем другая (как, собственно, уже верно отметили в комментарии выше).
В самом по себе использовании калькулятора на уроках математики ничего плохого нет. Проблемы начинутся, если (или, точнее, когда) изучение арифметики превратится в "знакомство с назначением кнопок калькулятора", с целью "уметь правильно сформулировать ему задание".
агент будет искать и предлагать клиенту варианты и сможет совершить покупку [...] ИИ-агенты не будут иметь полной автономии, чтобы самостоятельно совершать покупки
Из текста не понятно, сможет всё же совершать покупки или не сможет. Однако идея предоставить компаниям-операторам ИИ-агентов возможность не только списывать средства за собственные услуги, но и оплачивать произвольные покупки от "имени клиента" - очень даже масштабная.
А в MWI делим единицу на единицу, чтобы получить единицу: то есть, пока событие-измерение не произошло, то вероятность любого исхода - нулевая, зато как только произошло, то тут уже эта вероятность тождественно равна единице.
В many-worlds interpretation нельзя построить разумное понятие о вероятности, так что, да, там весь смысл Предсказателя растворяется и исчезает. Однако в этой интерепретации вообще нетрудно всё что угодно растворить таким же способом, через бесконечный "спектр", так что она не очень-то содержательна.
В статье дано условие "ВО ВСЕХ случаях предсказатель угадывал ваш выбор"
Справедливости ради: вот прямо такого условия - в статье нет. Я написал, что "до этого момента все (сколь угодно много) испытуемые, выбравшие только закрытую коробку, получали миллион, а те, кто забирал обе, лишь тысячу". Тут речь про испытуемых, а не про угадывание конкретного выбора.
Насчёт "очень сильно" - момент спорный. "Инлайн" тоже не всегда соответствует ожиданиям. Современные процессоры весьма коварные, когда дело касается оптимизации и Go, поэтому вызов функции может стоить дешевле, чем развёрнутый копилятором Go "инлайн".
Например, компилируем (go1.24.0) код первого примера, где func withDefer(){ defer func() {}()} на RaspberryPi 4, ARM Cortex-A72:
С ассемблерным CALL (для ARM Cortex - BL, на самом деле ), - то есть, без inline, - для отсутствующего defer, всё равно получилось, как минимум, не медленнее (вообще, по коду выглядит так, что будет даже несколько быстрее).
Вариант с defer - понятно, что медленнее в любом случае, но defer приносит с собой важные семантические преимущества.
Верификация даёт гарантию, что программа будет выполняться только как задумали разработчики
Это излишнее упрощение, которое, почему-то, кочует из статьи в статью (и в заголовке, кстати, оно же). Невозможно гарантировать, что достаточно сложная программа будет исполняться так, как "задумали разработчики". Верификация тут означает следующее: имеется машинное доказательство того, что запись алгоритма соответствует, с точностью до используемых функциональных примитивов, описанию работы этого алгоритма на некотором формальном (мета)языке.
Генерирование строгого кода с доказательствами - штука весьма и весьма полезная, но не очень хорошо расширять её действие до безграничного. Это больше вредит, чем помогает.
Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.
Это цитата из статьи 2019 года. Вообще, о том, что всё придёт к пропуску только подписанного на конечном устройства трафика, я говорю лет пятнадцать или двадцать. Довольно интересно наблюдать изменение реакции слушающих: если ещё пятнадцать лет назад даже не все сетевые инженеры понимали, о чём, собственно, речь (а она не о развитии sBGP и пр.), то сейчас не все уже и удивляются, что такое возможно в обозримом будущем.
И поддержка защищённого DNS со стороны клиентов вовсе не нужна.
Это как посмотреть. Конечно, сокрытие запросов от провайдера - не требует DoH внутри: если весь процесс резолвинга для устройств в локальной сети зведён на резолвер роутера или на другой конролируемый резолвер, тоже внутри LAN, то хорошо. То есть, решается именно задача закрытия DNS-трафика между "пограничным" резолвером и внешним резолвером. Но вообще, основной смысл DoH - именно в защите от приложения к приложению, то есть, даже выше уровня устройства. Другое дело, что DNS требуется примерно везде, однако на произвольных устройствах - DoH большая редкость.
Таким образом, если даже в сетевых настройках у какого-то клиента явно указан адрес публичного DNS-сервера, эти DNS-запросы обработает резолвер на роутере.
Кстати, это как раз пример подмены DNS. Клиент обращается к 8.8.8.8, а отвечает - (ближайший) роутер. Для борьбы с чем, собственно, и предлагается DoT/DoH, но в приложении на клиенте. Момент, с точки зрения администрирования LAN, спорный; регулряно выдвигается в качестве одной из основных причин того, почему "DoH в браузере - плохо". Но тут просто разные парадигмы.
Обычно поверхность атаки определяют экспертным методом, однако тут же возникает вопрос полноты этого метода [...] На этот большой вопрос пытается ответить инструмент для определения поверхности атаки
А в конце:
При подготовке к анализу ПО [...] необходимо провести аналитическую работу по выбору конкретных узлов, которые лежат на общей поверхности атаки
Это несколько странно. Выглядит так, что инструмент служит для определения поверхности атаки, однако для его эффективного использования нужно уже знать поверхность атаки, а иначе инструмент придётся гонять до "Тепловой смерти Вселенной" (цитата).
Как скрыть свои запросы от провайдера с помощью этой штуки?
Достаточно указать внешний, относительно провайдера, рекурсивный резолвер, включить для этого резолвера DoH и убедиться, что защищаемые DNS-запросы действительно ходят через DoH на этот резолвер. Если прошивка роутера позволяет, то можно настроить на роутере локальный резолвер в качестве "форвардера", указав в качестве вышестоящего рекурсивный резолвер с DoH или DoT и выбрав один из этих протоколов для доступа. Соответственно, на всех устройствах в LAN тогда нужно настроить в качестве DNS-сервера IP-адрес роутера (или роутерного резолвера). Это настраивается через DHCP или вручную на устроствах (в настройках DNS). Тогда локальная работа с DNS будет в открытом виде, но за пределы LAN DNS-трафик будет ходить через DoH/DoT, которые настроены на роутере для "форвардера". То есть, устройства в локальной сети используют в качестве резолвера роутер, а внутри роутера запросы оборачиваются в DoH/DoT (на этот момент нужно обратить внимание) и передаются на внешний, относительно провайдера, рекурсивный резолвер в защищённом виде.
Почему указание резолвера на роутере не даёт эффекта?
Точно сказать сложно, зависит от сетевой конфигурации. Скорее всего, потому, что устройства обращаются к внешнему DNS-резолверу напрямую, без всяких DoH/DoT, например, получив такой адрес резолвера по DHCP. Кроме того, сам по себе адрес - не говорит о том, по какому протоколу нужно подключаться. Если по умолчанию, то всё будет ходить в открытом виде, даже если указать IP-адрес сервиса резолвера, который, потенциально, поддерживает тот же DoH. То есть, нужно не только настроить защищённый DNS-доступ на DNS-подключении роутера, но ещё и устройствам в локальной сети рассказать, что нужно использовать именно защищённую точку входа для DNS, особенно, если эти устройства не поддерживают DoH/DoT (см. про "форвардер" выше).
Преимущество DNSSEC как раз в том, что администратор DNS-зоны подписывает конкретные сведения в этой зоне. Администратор является первоисточником сведений о настройках зоны, так или иначе. Поэтому, если мы принимаем, что подпись работает и подписывающие ключи сохраняются администратором в секрете, то для стороны, валидирующей DNS-записи, вообще становится без разницы, откуда и как эти записи были получены - главное, чтобы сходились подписи и все ключи в цепочке были доверенными. То есть, DNSSEC как раз делает DNS-данные независимыми от транспорта. Конечно, это не защищает от того, что записи всё же кто-то испортит на транзите, но подменить содержание, скрыв факт подмены, не получится, так что порчу можно будет обнаружить.
и никак не может помешать отправке любой белиберды
Это так. Администратор волен написать в DNS-зоне что угодно, в том числе, может корректно подписать "кривые" записи или наделать "кривых" ключей, может ещё что-то сломать под своими именами, подтвердив все поломки DNSSEC-записями. Однако в случае, когда DNSSEC нет, всё это может проделать не только администратор, которому по статусу положено, но и всякий транзитный узел.
А главный недостаток DNSSEC в том, что это слишком хрупкая, по нынешним временам, технология, требующая, к тому же, специальных знаний и понимания принципов работы для поддержки уже настроенных процессов. И когда хрупкость DNSSEC даёт о себе знать, тогда отламываются сразу целые национальные зоны.
Атаковать валидатор УЦ необязательно. Чтобы клиент мог поверить подписи в сертификате - этот клиент должен верить в ключи УЦ, которым сертификат выпущен. Соответственно, ключи откуда-то нужно взять. Если же у клиента таких доверенных ключей нет и в сертификате подпись он проверяет просто, "чтобы сходилось", то перехватывающий узел может выпустить и подписать свой сертификат, который будет предназанчен именно для конкретной сессии (это нетрудно - сертификат выпускается за какие-то десятки миллисекунд).
Если клиент дополнительно сверяет имя в сертификате с именем, которое заранее известно клиенту, то перехватывающему узлу нужно подходящее имя вписать в подставной сертификат, а для этого имя нужно как-то выяснить. Это не всегда просто сделать: то есть, можно ожидать, что какое-то имя есть в поле SNI начального сообщения TLS, но, во-первых, для DoT тут есть оговорки; во-вторых, придётся парсить TLS-сессию и сообщения. Для IP-адреса - всё проще: он заранее известен, так что и сертификат можно заранее заготовить.
В отличии от корневых DNS, маршруты до которых хорошо защищены
У корневых DNS-серверов очень много локальных узлов, которые расставлены по разным местам Интернета. Какие-то исключительные особо эффективные методы защиты для маршрутов там не применяются, да их и не получится применять для всех локальных узлов. Всё в общем порядке. Да, собственно, BGP везде примерно одинаково "защищён" сейчас.
Но тут важно другое: с точки зрения обычного клиентского подключения (а не межсетевого взаимодействия на уровне AS), в IP-сетях всякий промежуточный узел может ответить вместо "оконечного", соответственно, для активной атаки лишь нужно "встать в разрыв"; ну и вот разные "угоны маршрутов" - лишь служат для того, чтобы петлёй закинуть к себе "хопы", которые в штатном режиме - "чужие" (то есть, должны были бы быть в других сетях). С DNS тут даже хуже, потому что распространённый доступ тут по UDP. Так что для защиты протоколов, работающих выше IP, в принципе нужны какие-то дополнительные меры, типа проверки ключей/подписей.
Можно пытаться распределять сертификаты сверху вниз через механизм похожий
Или просто использовать отпечатки ключей. Или, например, проверять отпечатки ключей и цепочки с валидацией DNSSEC. А исключительно TLS-cертификаты, да ещё и с привычной иерархией, для DoT вообще не очень подходят, на мой взгляд.
Чисто технически - ничто не мешает: вписать IP-адрес в сертификат несложно, это предусмотрено форматом. Но, если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt вот обещают для всех в этом году сделать автоматические короткоживущие TLS-сертификаты на IP-адреса. Поскольку там есть механизм подтверждения чисто по TLS, то можно будет в прозрачном режиме привестить ACME-проверку к DoT, не поднимая ненужного веб-сервера.
Однако, если про использование УЦ, то есть другие особенности. Проверка соответствия IP-адресов потребует ввести доверие инфраструктуре УЦ ещё и для DNS, что создаст очень нехорошую зависимость от работы и политик этих УЦ; а DNS, всё же, фундамент Интернета. Если же доверие УЦ не предусматривать, то, при активной атаке, подменить сертификат, выпущенный для IP-адреса, даже проще, чем сертификат для DNS-имён: имена нужно как-то узнать для конкретной сессии, до подмены, а IP-адрес сервера - заранее известен.
Только тут получилось, что в итоговую формулу π входит и в правую часть тоже, в составе L и т.д. Поэтому нужно что-то с буквами сделать, а то π используется для вычисления π.
С одной стороны, утверждение про "100% кода через год" - рискованное: кто-то из выживших человеков может же из принципа продолжать кодить без ИИ - либо чтобы не было 100%, либо по причине отсутствия доступа к интернетам. С другой стороны, сделать вот 99.9% ИИ-кода - не так уж и сложно: пусть этот ИИ генерит больше и больше кода, тогда доля будет расти. Вот, скажем, в "параллельной ветке" этого интеллектуального развлечения прямо утверждается, что искусственный суперинтеллект "будет писать триллионы строк кода", который код "человек не сможет понять, даже если ИИ будет годами его объяснять". Что там нагенерировано - не понятно, но зато непонятно на 100% (почти).
Из новости не ясно. Предположить можно следующее: все эти ИИ-агенты - это сервисы с центральным внешним управлением; соответственно, с точки зрения платёжной системы, корпорация "Имярек", массово тыкающая агентами через актуальные реквизиты и приложения пользователей в платёжную систему, выглядит как объект, нуждающийся в специальных соглашениях, иначе, технически, оно будет выглядеть очень похоже на фрод, что не должно нравиться ни "Имяреку", ни платёжной системе. А при наличии специальных доступов/договоров - история с классификацией транзакций и с возможными спорами будет совсем другая (как, собственно, уже верно отметили в комментарии выше).
В самом по себе использовании калькулятора на уроках математики ничего плохого нет. Проблемы начинутся, если (или, точнее, когда) изучение арифметики превратится в "знакомство с назначением кнопок калькулятора", с целью "уметь правильно сформулировать ему задание".
Или выгружают двадцать мешков цемента: всё уже оплачено ИИ-агентом.
Из текста не понятно, сможет всё же совершать покупки или не сможет. Однако идея предоставить компаниям-операторам ИИ-агентов возможность не только списывать средства за собственные услуги, но и оплачивать произвольные покупки от "имени клиента" - очень даже масштабная.
А в MWI делим единицу на единицу, чтобы получить единицу: то есть, пока событие-измерение не произошло, то вероятность любого исхода - нулевая, зато как только произошло, то тут уже эта вероятность тождественно равна единице.
В many-worlds interpretation нельзя построить разумное понятие о вероятности, так что, да, там весь смысл Предсказателя растворяется и исчезает. Однако в этой интерепретации вообще нетрудно всё что угодно растворить таким же способом, через бесконечный "спектр", так что она не очень-то содержательна.
Справедливости ради: вот прямо такого условия - в статье нет. Я написал, что "до этого момента все (сколь угодно много) испытуемые, выбравшие только закрытую коробку, получали миллион, а те, кто забирал обе, лишь тысячу". Тут речь про испытуемых, а не про угадывание конкретного выбора.
Насчёт "очень сильно" - момент спорный. "Инлайн" тоже не всегда соответствует ожиданиям. Современные процессоры весьма коварные, когда дело касается оптимизации и Go, поэтому вызов функции может стоить дешевле, чем развёрнутый копилятором Go "инлайн".
Например, компилируем (go1.24.0) код первого примера, где
func withDefer(){ defer func() {}()}на RaspberryPi 4, ARM Cortex-A72:Включен inline:
Выключен inline (go build -gcflags='-l')
С ассемблерным CALL (для ARM Cortex - BL, на самом деле ), - то есть, без inline, - для отсутствующего defer, всё равно получилось, как минимум, не медленнее (вообще, по коду выглядит так, что будет даже несколько быстрее).
Вариант с defer - понятно, что медленнее в любом случае, но defer приносит с собой важные семантические преимущества.
Это излишнее упрощение, которое, почему-то, кочует из статьи в статью (и в заголовке, кстати, оно же). Невозможно гарантировать, что достаточно сложная программа будет исполняться так, как "задумали разработчики". Верификация тут означает следующее: имеется машинное доказательство того, что запись алгоритма соответствует, с точностью до используемых функциональных примитивов, описанию работы этого алгоритма на некотором формальном (мета)языке.
Генерирование строгого кода с доказательствами - штука весьма и весьма полезная, но не очень хорошо расширять её действие до безграничного. Это больше вредит, чем помогает.
Это цитата из статьи 2019 года. Вообще, о том, что всё придёт к пропуску только подписанного на конечном устройства трафика, я говорю лет пятнадцать или двадцать. Довольно интересно наблюдать изменение реакции слушающих: если ещё пятнадцать лет назад даже не все сетевые инженеры понимали, о чём, собственно, речь (а она не о развитии sBGP и пр.), то сейчас не все уже и удивляются, что такое возможно в обозримом будущем.
Ещё я бы не исключал "фактчегинговые" агентства, которые, в рамках борьбы с "фейкньюс", проверяют страницы сайтов при помощи ИИ/LLM.
Это как посмотреть. Конечно, сокрытие запросов от провайдера - не требует DoH внутри: если весь процесс резолвинга для устройств в локальной сети зведён на резолвер роутера или на другой конролируемый резолвер, тоже внутри LAN, то хорошо. То есть, решается именно задача закрытия DNS-трафика между "пограничным" резолвером и внешним резолвером. Но вообще, основной смысл DoH - именно в защите от приложения к приложению, то есть, даже выше уровня устройства. Другое дело, что DNS требуется примерно везде, однако на произвольных устройствах - DoH большая редкость.
Кстати, это как раз пример подмены DNS. Клиент обращается к 8.8.8.8, а отвечает - (ближайший) роутер. Для борьбы с чем, собственно, и предлагается DoT/DoH, но в приложении на клиенте. Момент, с точки зрения администрирования LAN, спорный; регулряно выдвигается в качестве одной из основных причин того, почему "DoH в браузере - плохо". Но тут просто разные парадигмы.
В начале статьи сказано (выделил ключевые слова):
А в конце:
Это несколько странно. Выглядит так, что инструмент служит для определения поверхности атаки, однако для его эффективного использования нужно уже знать поверхность атаки, а иначе инструмент придётся гонять до "Тепловой смерти Вселенной" (цитата).
Достаточно указать внешний, относительно провайдера, рекурсивный резолвер, включить для этого резолвера DoH и убедиться, что защищаемые DNS-запросы действительно ходят через DoH на этот резолвер. Если прошивка роутера позволяет, то можно настроить на роутере локальный резолвер в качестве "форвардера", указав в качестве вышестоящего рекурсивный резолвер с DoH или DoT и выбрав один из этих протоколов для доступа. Соответственно, на всех устройствах в LAN тогда нужно настроить в качестве DNS-сервера IP-адрес роутера (или роутерного резолвера). Это настраивается через DHCP или вручную на устроствах (в настройках DNS). Тогда локальная работа с DNS будет в открытом виде, но за пределы LAN DNS-трафик будет ходить через DoH/DoT, которые настроены на роутере для "форвардера". То есть, устройства в локальной сети используют в качестве резолвера роутер, а внутри роутера запросы оборачиваются в DoH/DoT (на этот момент нужно обратить внимание) и передаются на внешний, относительно провайдера, рекурсивный резолвер в защищённом виде.
Точно сказать сложно, зависит от сетевой конфигурации. Скорее всего, потому, что устройства обращаются к внешнему DNS-резолверу напрямую, без всяких DoH/DoT, например, получив такой адрес резолвера по DHCP. Кроме того, сам по себе адрес - не говорит о том, по какому протоколу нужно подключаться. Если по умолчанию, то всё будет ходить в открытом виде, даже если указать IP-адрес сервиса резолвера, который, потенциально, поддерживает тот же DoH. То есть, нужно не только настроить защищённый DNS-доступ на DNS-подключении роутера, но ещё и устройствам в локальной сети рассказать, что нужно использовать именно защищённую точку входа для DNS, особенно, если эти устройства не поддерживают DoH/DoT (см. про "форвардер" выше).
Преимущество DNSSEC как раз в том, что администратор DNS-зоны подписывает конкретные сведения в этой зоне. Администратор является первоисточником сведений о настройках зоны, так или иначе. Поэтому, если мы принимаем, что подпись работает и подписывающие ключи сохраняются администратором в секрете, то для стороны, валидирующей DNS-записи, вообще становится без разницы, откуда и как эти записи были получены - главное, чтобы сходились подписи и все ключи в цепочке были доверенными. То есть, DNSSEC как раз делает DNS-данные независимыми от транспорта. Конечно, это не защищает от того, что записи всё же кто-то испортит на транзите, но подменить содержание, скрыв факт подмены, не получится, так что порчу можно будет обнаружить.
Это так. Администратор волен написать в DNS-зоне что угодно, в том числе, может корректно подписать "кривые" записи или наделать "кривых" ключей, может ещё что-то сломать под своими именами, подтвердив все поломки DNSSEC-записями. Однако в случае, когда DNSSEC нет, всё это может проделать не только администратор, которому по статусу положено, но и всякий транзитный узел.
А главный недостаток DNSSEC в том, что это слишком хрупкая, по нынешним временам, технология, требующая, к тому же, специальных знаний и понимания принципов работы для поддержки уже настроенных процессов. И когда хрупкость DNSSEC даёт о себе знать, тогда отламываются сразу целые национальные зоны.
Атаковать валидатор УЦ необязательно. Чтобы клиент мог поверить подписи в сертификате - этот клиент должен верить в ключи УЦ, которым сертификат выпущен. Соответственно, ключи откуда-то нужно взять. Если же у клиента таких доверенных ключей нет и в сертификате подпись он проверяет просто, "чтобы сходилось", то перехватывающий узел может выпустить и подписать свой сертификат, который будет предназанчен именно для конкретной сессии (это нетрудно - сертификат выпускается за какие-то десятки миллисекунд).
Если клиент дополнительно сверяет имя в сертификате с именем, которое заранее известно клиенту, то перехватывающему узлу нужно подходящее имя вписать в подставной сертификат, а для этого имя нужно как-то выяснить. Это не всегда просто сделать: то есть, можно ожидать, что какое-то имя есть в поле SNI начального сообщения TLS, но, во-первых, для DoT тут есть оговорки; во-вторых, придётся парсить TLS-сессию и сообщения. Для IP-адреса - всё проще: он заранее известен, так что и сертификат можно заранее заготовить.
У корневых DNS-серверов очень много локальных узлов, которые расставлены по разным местам Интернета. Какие-то исключительные особо эффективные методы защиты для маршрутов там не применяются, да их и не получится применять для всех локальных узлов. Всё в общем порядке. Да, собственно, BGP везде примерно одинаково "защищён" сейчас.
Но тут важно другое: с точки зрения обычного клиентского подключения (а не межсетевого взаимодействия на уровне AS), в IP-сетях всякий промежуточный узел может ответить вместо "оконечного", соответственно, для активной атаки лишь нужно "встать в разрыв"; ну и вот разные "угоны маршрутов" - лишь служат для того, чтобы петлёй закинуть к себе "хопы", которые в штатном режиме - "чужие" (то есть, должны были бы быть в других сетях). С DNS тут даже хуже, потому что распространённый доступ тут по UDP. Так что для защиты протоколов, работающих выше IP, в принципе нужны какие-то дополнительные меры, типа проверки ключей/подписей.
Или просто использовать отпечатки ключей. Или, например, проверять отпечатки ключей и цепочки с валидацией DNSSEC. А исключительно TLS-cертификаты, да ещё и с привычной иерархией, для DoT вообще не очень подходят, на мой взгляд.
Чисто технически - ничто не мешает: вписать IP-адрес в сертификат несложно, это предусмотрено форматом. Но, если говорить про имеющиеся "хорошо известные УЦ", то сертификаты для IP-адресов выпускают неохотно, так как есть трудности с надёжной проверкой права управления адресом, а также с сопровождением. Впрочем, Let's Encrypt вот обещают для всех в этом году сделать автоматические короткоживущие TLS-сертификаты на IP-адреса. Поскольку там есть механизм подтверждения чисто по TLS, то можно будет в прозрачном режиме привестить ACME-проверку к DoT, не поднимая ненужного веб-сервера.
Однако, если про использование УЦ, то есть другие особенности. Проверка соответствия IP-адресов потребует ввести доверие инфраструктуре УЦ ещё и для DNS, что создаст очень нехорошую зависимость от работы и политик этих УЦ; а DNS, всё же, фундамент Интернета. Если же доверие УЦ не предусматривать, то, при активной атаке, подменить сертификат, выпущенный для IP-адреса, даже проще, чем сертификат для DNS-имён: имена нужно как-то узнать для конкретной сессии, до подмены, а IP-адрес сервера - заранее известен.
Поправил. Спасибо.
Только тут получилось, что в итоговую формулу π входит и в правую часть тоже, в составе L и т.д. Поэтому нужно что-то с буквами сделать, а то π используется для вычисления π.
С одной стороны, утверждение про "100% кода через год" - рискованное: кто-то из выживших человеков может же из принципа продолжать кодить без ИИ - либо чтобы не было 100%, либо по причине отсутствия доступа к интернетам. С другой стороны, сделать вот 99.9% ИИ-кода - не так уж и сложно: пусть этот ИИ генерит больше и больше кода, тогда доля будет расти. Вот, скажем, в "параллельной ветке" этого интеллектуального развлечения прямо утверждается, что искусственный суперинтеллект "будет писать триллионы строк кода", который код "человек не сможет понять, даже если ИИ будет годами его объяснять". Что там нагенерировано - не понятно, но зато непонятно на 100% (почти).