Дориан Грей — это программа, вшитая в ублюдка, которая его и сожрала
Лорд Генри — не друг. Лорд Генри — инсталлятор. Он не спорит с Дорианом, он загружает в него операционку: красота — единственная ценность, молодость — единственный капитал, мораль — иллюзия для тех, кто не умеет жить. Это не философия. Это код.
Жёлтая книга — установочный диск. Портрет — внешний накопитель, куда пишется всё, что Дориан вытесняет: совесть, возраст, последствия, лицо. Он думает, что портрет — его страховка. На самом деле это лог-файл, который пишет его настоящее «я». Дориан — это процесс. Ему кажется, что он пользователь. Он выбирает, он живёт, он наслаждается. Но каждая «свобода» — это строчка, которую исполняет не он. Сибила — сбой в любви, который программа просто игнорирует. Бэзил — тот, кто видит носителя, а не софт, и программа его удаляет. Портрет — окно, куда смотрит то, что Дориан отказывается признавать.
Программа работает идеально, пока ресурсы есть. Молодость, красота, деньги, связи, скука как топливо. Потом она начинает жрать носителя: паранойя, бессонница, страх зеркал, страх ножей, страх собственной тени. Он уже не может выйти из процесса, потому что процесс — это и есть он.
Финал — это попытка kill process. Он бьёт ножом в портрет, думая, что убивает улику. Но убивает железо. Портрет возвращается к исходному состоянию, а Дориан — глюк, который самоуничтожился.
Уайльд написал не моралите. Он написал предупреждение: идея — это софт. Человек — железо. Лорд Генри остаётся в стороне, потому что он автор, а не носитель. А Дориан — тот, кто поверил, что может запустить чужой код и остаться собой.Не смог. В его случае программа оказалась сильнее того, кто думал, что управляет ею.
История разработки мессенджера Mercury, часть 2: полный P2P
Две хорошие новости для любителей интернета, технологий, мессенджеров и дневников разработки.
Как вы, конечно, помните, я разрабатываю мессенджер неподвластный цензуре и свободный от подписок и рекламы. Ну или посмотрите предыдущий пост Как написать собственный мессенджер и сохранить рассудок, кто не помнит.
Первая версия мессенджера, про которую был предыдущий пост, работала на технологии WebRTC: это хорошо проработанный набор протоколов для установления прямого соединения между устройствами через интернет и передачи текстовой/бинарной и медиа информации, такой как голос и видео. WebRTC настолько популярен, что, в общем-то, все видеоконференции сейчас работают на этом фреймворке - его поддержка вшита во все браузеры а для мобильных разработчиков поставляются и регулярно обновляются готовые библиотеки. Если очень кратко, два клиента, которые хотят установить прямое соединение, получают информацию о своем присутствии в интернете от STUN-сервера (сокр. от англ. Session Traversal Utilities for NAT, это сетевой протокол, который позволяет клиенту определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети) и публикует все что нашел на особом сигнальном сервере. Сигнальный сервер для обоих клиентов должен быть один и тот же, а STUN-сервера - какие угодно, их много публичных и бесплатных.
Проблемы начинаются, когда один или оба клиента спрятаны за NAT (Network Adress Translation, это технология, которые используют роутеры чтобы преобразовать адреса внутренней сети в адреса интернета и обратно) и входящие соединения невозможны, то есть в современном интернете - практически всегда. Для того, чтобы устройства все-таки смогли как-то установить соединение, WebRTC предполагает использование TURN-серверов (Traversal Using Relays around NAT), специальных реле, которые передают зашифрованные аудио/видео/данные потоки между устройствами когда прямое соединение не может быть установлено. Для своего приложения я использовал TURN-сервера от metered.ca.
Когда я опубликовал первую версию мессенджера, внезапно обнаружилось, что metered.ca в России заблокирован, давно и прочно. Общение не задалось.
Так вот, первая хорошая новость - я, наконец-то, полностью, окончательно и бесповоротно (потому что я никогда не возьмусь переделывать это взад) перевел мессенджер на libp2p. Это открытый фреймворк для разработки P2P приложений, со встроенным шифрованием, обходом NAT и поиском клиентов в распределенных хэш-таблицах. libp2p подразумевает, что где-то в интернете должны быть доступны стартовые ноды с известными адресами, а дальше по мере роста количества клиентов, распределенная сеть будет становиться все устойчивее и устойчивее. Пока я выкатил 4 стартовые ноды, и, если их заблокируют, я легко смогу перевыпустить их с новыми адресами и обновить приложение.




Япония, к слову, не блокирует ничего пока, там и первая версия работала. Но обновленная - намного лучше.
libp2p работает немного похоже на WebRTC но есть и принципиальные отличия. Например, когда клиент ААА хочет установить соединение с клиентом АББ, в случае WebRTC этим занимался сигнальный сервер - он знал контактные данные обоих клиентов и дружил их друг с другом:
В случае libp2p, никакого сервера больше нет, некому сообщить ААА контактные данные АББ и наоборот. Но вместо этой потенциальной точки отказа, у нас есть распределенная хэш-таблица с контактными данными, где ААА может запросить контакты АББ и инициировать соединение. Дальше либо будет установлено прямое соединение если это возможно, если нет, то потоки данных будут транслироваться через одну из нод, до которой оба ААА и АББ соединения уже установили. Практически можно сказать, что вместо одного большого сигнального сервера у нас теперь много маленьких сигнальненьких серверочков.
Аудио и видео звонки я оставил работать через WebRTC, для этого в свои ноды я добавил встроенный TURN-сервер на основе открытого coturn. Так как контакты обоих устройств уже известны - вы не можете позвонить не установив соединение - сигнальный сервер не нужен. 4 слабеньких ноды - это, конечно, не панацея, но пару сотен одновременных звонков выдержат. В теории, если надо, и для усиленной безопасности, люди смогут публиковать в интернете свои собственные ноды - и привязать их к приложению, это все уже реализовано.
И это вторая хорошая новость - я собираюсь открыть исходники под какой-нибудь подходящей лицензией, и уже начал подготовку - автосборки, автоформат кода, автовыполнение тестов при открытии пулл-реквестов, и все такое. Процесс небыстрый, к сожалению.
Из других нововведений: добавил групповые чаты, один аккаунт теперь может быть зарегистрирован на нескольких устройствах, все они будут синхронизированы, улучшена передача файлов.
В следующем посте, пожалуй, расскажу об интересном механизме синхронизации сообщений. Так как мой мессенджер не имеет серверной части, вся переписка хранится на устройстве. Для переезда с одного телефона на другой, можно сделать зашифрованный бэкап, но если единственный телефон умер - переписку не восстановить. Но есть вариант загрузить всю историю сообщений от ваших собеседников! И она загрузится. Если, конечно, вы не потеряли сам аккаунт, так что не забывайте сохранять фразу безопасности в надежном месте.
Если захотите пощупать это приложение самостоятельно, ссылку на Google Play я оставлю в комментариях.
"Угон" Apple аккаунта и минус два айфона за 3 недели
Вся история развивалась практически на моих глазах и честно говоря, вопросов больше чем ответов.
Результат на момент написания этого поста - минус iPhone 13 (с него все началось), минус iPhone 16 PRO MAX, которому с момента покупки 2,5 недели.
Вся история происходит с коллегой по работе, то есть большая часть информации - с её слов.
Начало.
12 сентября 2026 г. она обнаруживает пропажу телефона iPhone 13. Предположительно, она его именно потеряла или на мойке, или в ТЦ. Попытки дозвониться 12 и 13 числа ни к чему не привели- телефон постоянно отключен.
13 сентября через оператора, блокируется симка в утраченном телефоне и получается дубликат. 14 сентября, в понедельник, она рассказывает об этом мне, мы вместе с ней заходим в ее аккаунт ставим статус телефона как потерянный и вводим номер телефона её мужа для связи, что бы при включении, на экране сразу было видно этот номер.
15 сентября она приходит с новым телефоном iPhone 16 PRO MAX, который подключен к ее аккаунту Apple, на котором "висит" все тот же утраченный айфон 13.
Как выяснилось позже, айфон 13 она купила два года назад у подруги (чеков и упаковки нет), айфон 16 куплен в магазине и все чеки и упаковка в наличии.
Я бы забыл об этой истории (ну потеряла и потеряла), если бы она позавчера (29 сентября) не рассказала мне, что новый телефон заблокировался и ничего сделать с ним она не может.
И вот тут она рассказала, что происходило последние полторы недели.
Атака.
15 сентября, в начале пятого вечера, ей приходит уведомление "от Apple" в котором её просят ввести данные аккаунта. Она переходит по ссылке из уведомления, вводит данные и больше ничего не происходит.
Её это не смущает, не вызывает никаких вопросов и она об этом благополучно забывает.
26 сентября, (через 11 дней, после атаки), утром, она смотрит время на телефоне и понимает, что телефон показывает +2 часа к московскому времени (вроде она упоминала, что какое то уведомление о смене часового пояса было, но это не точно). И в это же время или позже, её телефон блокируется как утраченный. При этом никаких сообщений или уведомлений с просьбой связаться или требование денег нет до сих пор.
Она пытается войти в iCloud с ПК- пароль изменен, пытается его восстановить - номер изменен, почта изменена. То есть, она вообще ничего не может сделать. (В поддержку она обращалась, я так понял они просто отморозились).
1 октября выясняется, что ее старый телефон до сих пор привязан ко-всем аккаунтам в которые она с него входила. Отвязываем от всего, о чем она смогла вспомнить, в яндексе, озоне и прочих магазинах проверяем наличие новых карт/заказов - все чисто. В этот же день отзвонилась поддержка Apple, еще раз запросили фото чека, коробки, расспросили об аккаунте, дате регистрации и прочие стандартные вопросы, сказали, что рассмотрение займет 7 дней, есть надежда, что они помогут
Лично для меня пока остается открытым вопрос: как они смогли узнать номер телефона?
Первая версия была спросить Сири. Проверил на таком же, если спросить сири свой номер телефона, то она требует или пароль или фейс, но, она вполне без проблем может набрать номер если ей его продиктовать, у МТСа есть короткий номер телефона при звонке на который робот продиктует номер с которого звонишь. Биллинг при этом чистый, никаких звонков и СМС в промежутке между утратой и блокировкой сим-карты, с телефона не было.
Итог.
А итога пока нет.
Есть вопрос, на который я ответа не нашел, а именно: откуда они узнали её номер телефона, до того как получили доступ к аккаунту? Похоже ответ есть. Скорее всего переставили симку в другой телефон, на андроиде это меню "сеть", там если выбрать сим-карту и нажать на "редактировать" можно увидеть номер телефона симки.
Есть запрос в Apple на который они ответа пока не дали. (Дали, ждем 7 дней)
И есть версия, что потерянный телефон и угон аккаунта, никак между собой не связаны, просто совпадение.
Мораль.
А мораль проста- не вводите данные своих аккаунтов, даже если СМС пришла от "надежного" источника.
Проблемы можно было избежать, если бы коллега, посмотрела в адресную строку браузера прежде чем вводить логин/пароль от аккаунта. К сожалению, из за блокировки телефона не посмотреть ни само СМС, ни ссылку, куда оно уводило.
Читать можно. Писать — нет
NVIDIA выпустила Open Agent Safety Platform. Вместе с ней — OpenShell 0.1.0.
Это не новый агент. OpenShell не заменяет Codex, Claude Code, Hermes и прочие. Он работает чем-то вроде враппера. Агент сидит в песочнице: на уровне ОС ограничиваются файлы и процессы. Рядом Supervisor проверяет исходящий трафик — HTTP, GraphQL и MCP.
Политики пишут на YAML. Дальше они компилируются в правила OPA Rego и проверяются на каждый исходящий запрос. К одному и тому же API можно разрешить чтение и запретить запись. Обычная библиотечная история: книгу дают, карандаш — нет.
Секреты агенту не отдают: они остаются вне его workload. При этом сервис, куда он стучится, свои права всё равно проверяет сам — OpenShell добавляет ещё один слой контроля, а не заменяет авторизацию сервиса.
По умолчанию сети может не быть вообще — тогда curl падает ещё на уровне ядра. Разрешить только чтение GitHub API можно одной командой, причём песочницу перезапускать не надо. Каждое решение политики остаётся в журнале OCSF.
На железе эту схему дополняет NVIDIA Sentry. Она работает на BlueField-4, не на третьем поколении — у BlueField-3 заметно меньше вычислительной мощности. В системах Vera Rubin POD эти DPU стоят на единственном пути к модели. Через NVIDIA DOCA Sentry связывает разговоры агента, решения политик и обращения к инструментам в контекстные записи активности.
На испытаниях агенты до двух часов уговаривали ИИ-ревьюеров дать им права на изменение защищённого репозитория. Уговаривать им не тяжело, не устают. OpenShell в это время показывал ревьюерам, что запрашиваемые права на самом деле позволяют, даже когда агент пытался ими манипулировать. Записей в защищённые репозитории не произошло.
Что тут сказать. Ну наконец-то безопасность агентов начинают строить не вокруг надежды на их хорошее поведение, а вокруг обычных системных ограничений: песочницы, политик доступа, сетевых правил и аудита. Давно пора.
tg
Яндекс Пэй и персональные данные
Оговорочка 1: Если вы не хотите, чтобы это было в интернете, не снимайте это. Эту истину я познал более 20 лет назад, еще при зарождении Рунета.
Оговорочка 2: В нашей жизни ни от чего нет 100% защиты и гарантии безопасности. По сути любая мера преследует одну цель - уменьшить вероятность, что плохое случится.
Опущу тот момент почему, но мне захотелось открыть накопительный счет в Яндекс Пэй. Система предлагает всего два пути: сделать фото себя с паспортом и отправить им, либо встретиться с их доверенным человеком, который такое твое фото сделает. Мне оба варианта не подходят, поэтому я долго не мог открыть счет в Яндексе. При этом самим банком пользуюсь давно, вроде даже какую-то идентификацию через Госуслуги проходил (поскольку СБП в рамках Яндекса пользуюсь без ограничений).
И вот сегодня в очередной раз зачесалось пройти полную идентификацию и открыть накопительный счет. Пишу в поддержку, мол а можно кому-то лично в глаза посмотреть и паспорт показать, без всех этих ваших фото. Отвечают - можно.
Ага, лезу назначать встречу. При оформлении запроса на встречу никаких галочек "согласия" и документов нет, просто кнопка типа "давай". Оформляю и...
Мне опять угрожают, что меня сфотографируют с паспортом. Мде... Пишу в поддержку, мол какого хрена. Пока поддержка так и молчит, уже 2,5 часа, получается. Но самое интересное дальше. В последующие 20 минут мне приходит 5 смс от финансовой организации АРС Финанс. Никаких своих согласий им напрямую я не давал, очевидно, это сделали Яндекс при вызове человека. Первое СМС с подтверждением встречи (хотя в Яндексе уже и так все норм), а последующие тупо спам с рекламой. Теперь вот буду ломать голову, как у АРС Финанс отозвать свои данные.
Смысл поста двойной. Обычному пользователю - это мой опыт, смотрите, делайте выводы о допустимости этих моментов для себя. А если @Yandex прочитает - ну нельзя так, ребята. Я изначально боюсь, что фото с паспортом может быть использовано в шарашкиных конторах, а вы тут же мои данные отправляете тем, кто спамит в открытую.
Я же пойду разгребать, что уже натворил парой нажатий в приложении Яндекс Пэй ) Всем хорошего дня.
Ответ Ugrum71 в «Гражданам, уличённым в использовании VPN, будут отключать интернет на год»3
Накуй эти полумеры? Запретить продавать американьские процессоры! Незачем поддерживать супостата!
Ответ на пост «Гражданам, уличённым в использовании VPN, будут отключать интернет на год»3
Как и всегда, ИА "Панорама" всего лишь на полшишечки опережает события:
"Тем, кто размещает VPN на ру-хостинге, могут на год запретить пользоваться абсолютно любыми российскими хостингами."







