Hacker News Digest

Parley — это федеративный чат, построенный поверх IRC, где каждый домен запускает собственный инстанс, а пользователи идентифицируются как email: alice@foo.com, bob@bar.com. Инстансы автоматически обнаруживают друг друга через DNS и обмениваются подписанными сообщениями по HTTPS, позволяя обычным IRC-клиентам (irssi, WeeChat, Textal и др.) общаться без плагинов. Сообщения типа /msg alice@foo.com hi работают сразу, даже если инстансы ранее не взаимодействовали — федерация устанавливается на лету.

Система поддерживает стандартные IRCv3-расширения: server-time, message-tags, echo-message, multi-prefix, setname и relaying клиентских тегов (например, индикаторы набора текста) через федерацию. История сообщений по умолчанию хранит последние 50 строк (было 20). Глобальные каналы вроде #lobby реплицируются между инстансами, отображая только количество участников и список доменов, без раскрытия имён пользователей — это делается через подписанные hello-снимки. Из известных ограничений: нет per-user ключей и end-to-end шифрования, нет канальных модов и операторов (глобальные каналы ничьи), ники привязаны к аккаунтам, а веб-интерфейс служит только для администрирования — чат остаётся делом IRC-клиентов. Проект лицензирован под MIT, тесты покрывают end-to-end сценарии через make test.

Обсуждение выявило серьёзные практические проблемы федеративного чата Parley: отсутствие централизованных операторов делает модерацию почти невозможной, спам и DDoS‐атаки считаются неизбежными, а сама идея воспринимается как переизобретение уже существующих протоколов (Matrix, XMPP) вместо использования готовых федеративных сетей. Одни считают, что отсутствие операторов каналов делает блокировку пользователей непрактичной, требуя от каждого админа блокировать злоумышленников на своём сервере; другие предлагают использовать репутационные списки блокировок, которые могут быстро распространяться между администраторами, как в системе спам‐фильтров email. Для решения проблемы модерации предлагается внедрить репутационные фильтры, позволяющие администраторам подписываться на блок‐листы друг друга, аналогично общим спам‐листам в почтовой системе. Множество участников согласились, что спам и возможность масштабных DDoS‐атак через динамически создаваемые серверы являются главным риском для любой децентрализованной IRC‐сети. Parley по сути повторяет функции уже существующих федеративных протоколов, таких как Matrix и XMPP, и поэтому не предлагает принципиально новых возможностей. Некоторые советуют построить приложение поверх уже существующей федеративной сети (например, ActivityPub или atproto), чтобы избежать создания отдельной учетной базы и упростить интеграцию. Несколько участников подчеркнули, что IRC уже имеет элементы федерации через связку серверов, но глобальные каналы без операторов создают новые сложности в управлении. Для упрощения деплоя предлагается использовать чистый Go‐SQLite вместо C‐биндингов, что облегчает создание минимальных Docker‐образов без необходимости наличия C‐runtime. Было отмечено, что удобство Parley может способствовать росту бот‐свармов, о чём уже предупреждались в контексте других децентрализованных систем.

Google анонсировал, что с выходом Chrome 154 в октябре 2026 года включит по умолчанию функцию "Always Use Secure Connections", требующую разрешения пользователя для доступа к сайтам без HTTPS. Эта мера призвана защитить пользователей от атак, при которых злоумышленники могут перехватить навигацию и подменить контент. Хотя HTTPS-адoption достиг 95-99%, прогресс застыл с 2020 года, а оставшиеся HTTP-соединения все еще представляют значительную угрозу.

Для баланса безопасности и удобства Chrome не будет дублировать предупреждения для часто посещаемых HTTP-сайтов. Google подчеркивает, что даже небольшая доля небезопасных соединений создает риски, так как атакующему достаточно одного успешного перехвата. Компания отмечает, что за десятилетие наблюдений HTTPS стал зрелым и широко распространенным, что позволяет теперь перейти к более строгим мерам защиты по умолчанию.

• Пользователи обсуждают, что почти весь трафик уже давно перешёл на HTTPS, и оставшиеся HTTP-сайты — это в основном старые ресурсы, которые не обновлялись с 2010-х годов.
• Обсуждается, что в 2024 году Google Chrome полностью отключит поддержку HTTP, и это вызвало споры о том, насколько это нужно, учитывая, что большинство сайтов уже используют HTTPS.
• Участники обсуждают, что вместо того, чтобы отключать HTTP, Google мог бы вместо этого инвестировать в улучшение инструментов для разработчиков, чтобы они могли легче мигрировать с HTTP на HTTPS.
• Также обсуждается, что отключение HTTP может затруднить доступ к внутренним ресурсам в корпоративных сетях, где HTTPS не всегда практичен.

The Tor Project выпустила альфа-версию Tor Browser 15.0a4, финальную перед стабильным релизом в конце октября. Ключевые изменения включают полное удаление встроенных ИИ-функций из соображений приватности, переименование 'meek-azure' в просто 'meek' для унификации, и улучшенную поддержку тёмной темы.

Важные технические правки: улучшено отображение CJK-иероглифов шрифтом Jigmo, управление WebAssembly теперь делегировано NoScript для совместимости с PDF, а индикатор протокола 'https' в URL-bar теперь всегда виден, как и в Firefox. Эти изменения завершают подготовку к стабильной версии.

• Mozilla и другие проекты продолжают внедрять AI-функции, что вызывает критику из-за конфликта с приватностью и философией открытого ПО.
• Пользователи жалуются на то, что Firefox и подобные браузеры всё больше становятся похожи на Chrome, теряя свою уникальность.
• Сторонники приватности и открытого ПО выражают обеспокоенность по поводу того, что Mozilla и подобные проекты всё меньше соответствуют своим принципам.
• Некоторые пользователи отмечают, что Mozilla всё меньше взаимодействует с сообществом и всё больше ведёт себя как корпорация.

Ключевые выводы исследования

• 8 популярных коммерческих VPN обслуживают >700 млн пользователей, но скрывают собственность и имеют критические уязвимости.
• 3 VPN связаны с НОАК Китая, у остальных найдены признаки китайского контроля.
• Отсутствие прозрачности позволяет злоумышленникам снимать шифрование и перехватывать трафик.

Почему важна прозрачность
VPN переносят доверие от интернет-провайдера к самому сервису. При выборе пользователи должны решить:

• Прозрачность — знать, кто видит данные.
• Анонимность — не знать, но полагаться на обещания.

Риски для пользователей

• Авторитарные государства могут использовать скрытые связи VPN для слежки.
• Отсутствие публичной информации о владельцах и разработчиках усиливает уязвимости.

• Коммерческие VPN часто продаются через страх не-технических пользователей, хотя реальные сценарии — это обход геоблоков, торренты и «неполиткорректный» контент.
• Модель доверия к единому VPN-узлу критикуется; предлагаются решения вроде iCloud Private Relay и MASQUE-релеев, разделяющих «кто» и «что».
• Подозрения вызывают «популярные» VPN (Nord, Express), их рекламные бюджеты и возможные связи с разведками; Mullvad считается одним из самых прозрачных, но его IP-адреса всё чаще банят.
• Некоторые «бесплатные» или малоизвестные VPN/прокси-сервисы превращают клиентов в узлы резидентного прокси и продают их трафик третьим лицам.
• Даже при смене IP браузерное фингерпринтирование легко идентифицирует пользователя; HTTPS сделал старые аргументы «VPN для безопасности в публичном Wi-Fi» почти бесполезными.

• История: от pre-fork до epoll — каждый шаг уменьшал сисколлы, но они всё ещё оставались узким местом.
• io_uring — кольцевые очереди в памяти: сервер пишет команды, ядро асинхронно их выполняет и кладёт результат обратно. При высокой нагрузке strace не покажет ни одного сисколла.
• 1 поток = 1 ядро без разделяемых структур; память берётся только из локального NUMA-узла.
• Память: заранее выделяем фиксированный буфер на соединение — без brk/mmap, без фрагментации.
• kTLS — после рукопожатия шифрование переходит в ядро. Плюсы:
  1. Работает sendfile, данные не копируются в userspace.
  2. Возможно аппаратное ускорение NIC.

• io_uring даёт «zero-syscall» при высокой нагрузке, но требует ручного управления памятью: безопасность не обеспечивается ни borrow checker, ни runtime.
• На большинстве облачных платформ io_uring выключен по умолчанию, поэтому остаётся нишевым.
• Автор статьи сначала чистит код, а потом будет мерить производительность — что вызвало одобрение читателей.
• Обсуждаются альтернативы: epoll, kTLS, DPDK, eBPF, а также споры «один поток на ядро» vs oversubscription.
• Некоторые считают, что сложность io_uring и async Rust — цена за неспособность ОС ускорить syscalls без нарушения обратной совместимости.

Я использую Tailscale около четырех лет, чтобы объединять свои устройства, серверы и приложения. Расскажу, как применяю его, о полезных фишках и подводных камнях.

Tailscale — это по сути оркестрация WireGuard с приятными надстройками. Продукт по подписке, но у него очень щедрый бесплатный тариф для личного использования. Клиенты — с открытым исходным кодом; есть и сторонний контроль-сервер Headscale, если не хочется облака.

Базовое подключение

Tailscale позволяет легко связать устройства, даже если они не торчат в интернет. Ставите клиент на телефон/компьютер/сервер/Raspberry Pi, авторизуете — и он общается с остальными по приватным IP Tailscale.

Это обычная идея VPN, но здесь всё просто: не нужно настраивать сеть и раздавать ключи — ставите клиент и логинитесь.

Например, мой домашний автоматизационный сервис на Raspberry Pi за двумя роутерами: поставил Tailscale, вошел — и сразу могу SSH с ПК или телефона, даже из разных сетей.

Есть особая поддержка SSH: Tailscale принимает подключения на 22 порт с tailnet и сам выполняет аутентификацию. Никаких ключей и паролей: вошли в Tailscale — можете войти на машину. Особенно удобно с телефона, где управлять ключами неудобно.

Можно публиковать не целую машину, а отдельные сервисы как отдельные узлы tailnet: есть официальный Docker-образ, Go-библиотека, и сторонние инструменты (например, мои Centauri и tsp).

Это больше, чем VPN

Чтобы не запоминать IP, я долго вручную добавлял DNS-записи. Перешел на MagicDNS — он автоматически создает DNS по имени машины.

Сначала меня смущало, что он меняет резолвер на устройствах — “слишком магично”. Разобрался, привык. Можно задать и свой upstream DNS. Я везде использую NextDNS, и Tailscale сам настраивает его на всех устройствах.

Помимо коротких имен, есть формат machine.your-tailnet.ts.net. Его можно «перебросить» на глобальную маршрутизацию и получить TLS-серты.

Нужно быстро показать локальный сервис? Включите funnel: tailscale funnel 127.0.0.1:8080 Без доп. опций сервис будет доступен по HTTPS:443. Дайте ссылку https://machine.your-tailnet.ts.net — трафик пойдет на ваш 8080. У посетителей Tailscale не нужен. Пользуюсь редко, но удобно.

Команда serve делает похожее, но только внутри tailnet. Так же работает Docker-образ Tailscale для публикации обычного сервиса. Для тестов с телефона: вместо танцев с Wi‑Fi/локалхостом/IP просто запускаю tailscale serve и захожу с устройства.

• Включение tailscale funnel мгновенно привлекает ботов, сканирующих новые HTTPS-сертификаты из CT-логов.
• Пользователи делятся альтернативами: Headscale, NetBird, Nebula, Zerotier и «чистый» WireGuard.
• Mullvad-интеграция позволяет использовать выходные ноды Tailscale для смены геолокации.
• Настоятельно не рекомендуют запускать dev-серверы и OIDC-серверы через funnel из-за риска блокировки и атак.
• Чтобы не светить домены, применяют wildcard-сертификаты и нестандартные порты.
• Tailscale собирает телеметрию по умолчанию; её можно отключить, но это не анонимный VPN.