Hacker News Digest

Проект OTP от команды gleam-lang предоставляет инструменты для создания отказоустойчивых многопоточных программ с использованием модели акторов. Реализация переносит мощные концепции Erlang OTP в экосистему языка Gleam, предлагая разработчикам современный подход к построению распределенных систем.

В основе проекта лежит модель акторов с изолированными процессами, где каждый актор обрабатывает сообщения независимо, обеспечивая естественную параллелизм и изоляцию состояний. Такой подход позволяет создавать системы, которые продолжают функционировать даже при сбоях отдельных компонентов, автоматически перезапуская упавшие процессы и сохраняя целостность данных.

• Обсуждение началось с восторженного отзыва о Gleam и его преимуществах, но быстро перешло в сравнение с Erlang/OTP и обсуждение того, что такое actor-модель и как она справляется с распределённым состоянием.
• Участники обменялись мнениями о том, какие языки/подходы лучше подходят для BEAM-стека, и подняли вопрос о том, что именно делает Erlang уникальным и какие у него есть ограничения.
• Также было затронуто, что такое влияние имеет выбор языка на разработку DSL и встраивание в другие системы, и почему транспиляция в Lua не рассматривается как цель.
• В конце обсуждение сошлось на то, что выбор инструмента в конечном счёте сводится к личным предпочтениям и конкретному проекту.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.