Hacker News Digest

BIGWORDS.PAGE позволяет превратить любой экран в полноэкранный знак, сообщение или таймер через простую ссылку — без аккаунтов, приложений и хранения данных на серверах. Всё содержимое помещается в фрагмент URL (часть после #), который никогда не передаётся на сервер, обеспечивая полную конфиденциальность. Пользователь может создать сообщение вручную через встроенный редактор или сгенерировать ссылку самостоятельно, а затем открыть её на телефоне, планшете, ноутбуке или смарт-TVs — она автоматически подстроится под размер экрана.

Поддерживается разметка Markdown: жирный и курсивный текст, заголовки # и ##, переносы строк. Можно создавать слайды, разделяя содержимое символами || — они будут автоматически меняться по таймеру. Функция {countdown} позволяет вставить обратный отсчёт до указанной даты (&until=) или на заданное время (&timer=). Также доступны генераторы QR-кодов для Wi-Fi, звонков, SMS и email — всё работает локально в браузере, без обращения к сторонним сервисам. Это делает BIGWORDS.PAGE удобным инструментом для встреч в аэропорту, отображения паролей Wi-Fi на стойке регистрации, таймеров на телевизоре или личных напоминаний — всё, что нужно, закодировано в одной ссылке.

Обсуждение подтверждает, что подход 'URL как приложение' эффективен для простых, конфиденциальных решений вроде цифровых табло, особенно в сценариях с ограниченным доступом к устройству, и демонстрирует реальные кейсы использования от конференций до предупреждений водителям.

• Пользователи отмечают, что отсутствие бэкенда и хранение данных в URL-фрагменте обеспечивают полную конфиденциальность и подходят для киосков, Chromecast и подобных устройств без необходимости в сложной инфраструктуре.

• Многие сравнивают проект с аналогами вроде bigassmessage.com и bigtext.k55.io, подтверждая, что подобные инструменты востребованы и имеют устойчивую нишу в хакерской культуре.

• Совет: Пользователь @pvillano выявил баг в Firefox: scrollWidth включает пробелы в отступы, что ломает адаптивность — предложил исправление через проверку clientWidth вместо scrollWidth.

• Совет: Предложено добавить base64-кодирование для скрытия содержимого в URL, чтобы избежать утечки смысла при делении ссылки — особенно актуально для приватных сообщений.

• Совет: Рекомендовано создать приложение для Google TV / Apple TV, чтобы упростить настройку на телевизорах без ручного ввода URL.

• Совет: Предложено добавить кнопку переключения полноэкранного режима и ориентации на мобильных устройствах для удобства использования.

• Совет: Пользователь @frankthecobbler запросил возможность скрыть или заменить превью при分享 ссылки в Apple Messages, так как текущий текст слишком нагляден и неэстетичен.

• Использование URL-фрагмента как аргументов для статического веб-приложения (argv) воспринимается как элегантный и чистый архитектурный паттерн, соответствующий принципу DOTADIW.

• Реальные кейсы: использование для предупреждения водителей о проблемах с автомобилем, отображения временных меток для международных игровых встреч и демонстрации спутниковых изображений ураганов на Chromecast.

• Спор: Некоторые пользователи (например, @ShinyLeftPad) считают фразу 'the URL is the app' пустым и навязчивым жаргоном, типичным для LLM, в то время как другие (например, @Zarel, @T0mSIlver) подтверждают её техническую обоснованность.

• Пользователь @paul7986 сообщил об ошибке SSL на Firefox, что указывает на потенциальную проблему с сертификатом или настройками хостинга, требующую внимания разработчика.

• Опыт @mcrowder65 с butts.netlify.app подтверждает, что подобные инструменты находят неожиданные применения в быту и как шутки, что расширяет восприятие их полезности.

I had the idea for BIGWORDS.PAGE when I wanted to display a message on a tablet that I had remote management control over, but no physical access. Configuring it to be a kiosk browser is easy, but how do I get the browser to show my message? So I made the URL be the message. — @SpeakingOfBrad

Перевод: Я придумал BIGWORDS.PAGE, когда хотел отобразить сообщение на планшете, к которому у меня был удалённый доступ, но не было физического. Настроить браузер в режиме киоска легко, но как заставить его показать моё сообщение? Поэтому я сделал сообщение частью URL.

Passkeys предлагают сильную защиту от фишинга и утечек данных благодаря привязке к сайту и асимметричной криптографии, но для личного использования они создают новые риски: высокая вероятность постоянной блокировки аккаунта при потере устройства, бана аккаунта в экосистеме Apple или Google (что влечёт потерю всех синхронизированных passkeys) или недостаточно надёжных методов восстановления (SMS, email, секретные вопросы). Аппаратные ключи не позволяют делать бэкапы passkeys, требуют отдельной регистрации для каждого сервиса и ограничены по количе accounts (25–300 на ключ), что делает их дорогими и непрактичными при большом числе аккаунтов. Синхронизация через ОС привязывает идентичность к платформе, а экспорт passkeys остаётся фрагментированным и непоследовательным — в отличие от паролей, которые легко переносить вручную. Сторонние менеджеры паролей пока не обеспечивают плавной интеграции с нативными приложениями и браузерами из-за незрелых API и недостатка UX-полировки. В сценариях использования чужих устройств (например, коллегиного компьютера) passkeys становятся неудобными: аппаратные ключи могут быть недоступны из-за отсутствия портов, а гибридный транспорт через QR-код и Bluetooth часто сталкивается с техническими сбоями. Хотя passkeys идеальны для корпоративной среды, где управляются устройства и восстановление централизовано, для обычных пользователей текущая экосистема создаёт больше проблем, чем решает: риск потери доступа превышает выгоду от защиты от фишинга. Надёжнее пока остаётся сочетание уникальных паролей из менеджера и независимого TOTP-приложения — оно даёт контроль, гибкость и избегает привязки к единственной точке отказа. Для тех, кто ранее использовал одинаковые пароли везде, passkeys — улучшение; для остальных — шаг назад.

Passkeys создают риск потери доступа к аккаунтам из-за зависимости от экосистем Apple/Google, плохой поддержки сторонних менеджеров паролей и отсутствия гибких механизмов резервного копирования. Потеря устройства или блокировка аккаунта в Apple/Google приводит к потере всех синхронизированных ключей. Большинство пользователей не осознают привязки passkeys к экосистеме и случайно их включают, усиливая проблему непрозрачности. Сайты вроде Amazon не распознают существующие passkeys в менеджерах паролей (Bitwarden, 1Password), предлагая создать новый ключ. Многие сервисы требуют только синхронизируемые ключи Apple/Google, блокируя использование аппаратных YubiKey и делая такие инвестиции бессмысленными. Отсутствие возможности добавить резервный ключ на другое устройство или в сейф делает passkeys непригодными для безопасного хранения. Пользователи с нестандартными устройствами (Linux, Xiaomi) сталкиваются с полным отсутствием поддержки. Passkeys не решают проблему слабых методов восстановления (SMS, email, вопросы), которые остаются уязвимыми. Зависимость от синхронизации между устройствами требует постоянного наличия нескольких исправных и заряженных гаджетов. Некоторые пользователи отмечают улучшение качества жизни: упрощение входа и устранение проблем с автозаполнением в 1Password при использовании iCloud/Google-синхронизации. Другие видят прогресс в использовании passkeys как основного фактора аутентификации, несмотря на проблемы с Google. Рекомендуется иметь несколько синхронизируемых устройств, хранить passkeys в менеджере паролей для кроссплатформенного доступа, возвращаться к аппаратным ключам как более интуитивной модели, отключать навязчивые запросы на создание passkeys в браузере и использовать non-resident U2F-ключи, которые не требуют хранения на устройстве и предлагают больше свободных слотов.

Автор отказывается от смартфона, чтобы избежать навязчивых требований устанавливать приложения и сканировать QR-коды, которые превращают повседневные действия в зависимость от американских технологических гигантов. Он подсчитал, что за год пришлось отбиваться от установки 18 приложений — даже для унитаза предполагается три отдельных приложения (сиденье, слив, вентиляция), что при трёх минутах в день на каждое занимает почти час ежедневно, или 22 полных дня в году.

Каждое требование установить приложение основано на десяти предположениях: наличие смартфона, его заряд, память, сеть, данные, аккаунт Google или Apple, готовность к вниманию и принятию условий, включая передачу личных данных. Если хотя бы одно предположение ложно — приложение не работает. Автор считает странным, что люди вообще соглашаются на такие условия, и отвечает на запросы фразой «У меня нет смартфона», что заставляет продавцов и работников искать альтернативные способы взаимодействия. Он поддерживает инициативы вроде европейских альтернатив Google, Jolla-телефона и Delta Chat, критикуя политиков за игнорирование существующих приватных решений в пользу хайповых проектов вроде «европейского ИИ» или блокчейна. Себя он называет Offpunk — защитником личной автономии в цифровом мире.

Обсуждение дополняет статью практическими примерами отказа от смартфонов: это возможно, но сопряжено с трудностями — от банковских операций и медицинских устройств до общественных сервисов — и обнажает системную зависимость от американских платформ. Советы: - Модифицированный iPhone с отключёнными браузером и App Store превращается в «глупый» телефон с базовыми функциями. - Установка приложений только через F-Droid вместо Google Play убирает привязку к Google-аккаунтам, но ограничивает доступ к сервисам вроде Waymo и может нарушать правила общего пользования. - Garmin GPS подходит для навигации, но не обновляет данные о закрытых заведениях, что создаёт риски в незнакомых районах. - FairPhone 3 с /e/OS — вариант для тех, кому нужны цифровые функции без Google: приложения ставятся вручную. - Умение прямо и спокойно говорить «нет» — эффективный инструмент при требованиях установить приложение или предоставить номер, особенно в очередях. - Разделение доступа к магазину приложений на бумажную часть и запоминаемую создаёт физическую преграду для установки новых приложений. Спорные позиции: - Смартфон можно настроить под себя (отключить уведомления, оставить пустой экран, использовать только нужные приложения) — тогда он станет инструментом, а не источником стресса. - Покупка дешёвого смартфона менее чем за 100 долларов делает отказ от него экономически необоснованным при наличии интернета и цифровых сервисов. Проблемы: - Требование устанавливать приложения для доступа к базовым услугам — от ресторанов до унитазов — неприемлемое расширение контроля технологических компаний. - Приложения для управления унитазами, вентиляцией и сливом — абсурдный пример превращения бытовых объектов в продукты с подпиской и зависимостью от корпоративных экосистем. - Отказ от смартфона ведёт к невозможности использовать банковские приложения, QR-коды и другие сервисы — это социальная изоляция, а не свобода. - Обязательное предоставление номера телефона и согласие на сбор данных в магазинах Индии и формах — системная, а не техническая проблема. - Медицинские устройства (например, для диабета 1 типа), банковские сервисы и системы оплаты всё чаще привязаны к смартфонам, создавая критические точки отказа в жизненно важных системах. - Отказ от Google- и Facebook-аккаунтов возможен, но требует постоянного противостояния инфраструктуре, где большинство сервисов требуют привязки к этим платформам.

Почему не дать мне просто зарегистрировать стиралку через веб?

В 2005-м мы с женой жили в общаге в Барселоне: старенькая стиралка, дверь держится стулом. Потом купили Electrolux — 20 лет прослужила, переезжала с нами в Гамбург и обратно. На прошлой неделе мотор сдох, заказал новую (опять Electrolux, но без Wi-Fi).

К брошюре прилагалась 10-летняя гарантия по регистрации: телефон и QR-код с номером в виде текста. Позвонил — 20 минут ожидания, потом сбросили. Предложили ссылку в SMS: https://www. example.com/gc/ — сертификат браузер не принял, руками починил — сайт не грузится.

Нашёл через Google electrolux warranty register — первая ссылка вела на /mypages/register-a-product/. Создал аккаунт, ввёл номер модели вручную или просто загрузил фото таблички — ИИ сам всё распознал и зарегистрировал за два клика. Почему не сразу дали эту ссылку?

Бонус
Прикрутил демо на Prompt API: браузер распознаёт 9-значный номер с фото таблички и возвращает только цифры регуляркой /\d{9}/.

• Компании сознательно усложняют регистрацию гарантии, чтобы снизить расходы и продавать доп-гарантии по телефону.
• Пользователи предлагают простые решения: QR-код с прямой ссылкой, наклейка с данными, «тупой» сканер вместо ИИ.
• Автор статьи, гуглер, вместо критики сам решает задачу через AI/ML, что выглядит иронично.
• Многие покупатели стараются найти «немодели» без «умных» функций и рекламы, но выбор сужается.
• Участники сходятся: проблема не в технологиях, а в бизнес-модели «planned obsolescence» и избегании реальной поддержки.

Как я случайно стал неофициальным разработчиком Apple Wallet для PureGym

47 секунд: зарождение злодея
Каждый вход в PureGym занимал 47 секунд: открыть приложение, дождаться загрузки, нажать «Gym access», дождаться QR. 6 дней в неделю — 282 секунды жизни на вход. Решил оптимизировать.

Восьмилетний PIN
8 лет подряд использую один и тот же 8-значный PIN на турникете. Он никогда не протухал. А QR-код обновляется каждую минуту — спектакль безопасности.

mitmproxy и GitHub
Попытка «заснять» QR и положить в Wallet провалилась — код умирает за минуту. На GitHub нашёл кучу недовольных разработчиков и старые репозитории PureGym.

PassKit: забытый ребёнок Apple
QR-коды PureGym — это обычные signed passes Apple Wallet. Формат .pkpass — ZIP с JSON и подписью. Сгенерировал собственный pass: pass.json, manifest.json, подписал через openssl.

Swift-backend на Vapor
Написал сервис на Vapor:

• авторизация по логину/паролю PureGym
• парсинг JSON с QR-кодом
• генерация нового .pkpass каждые 6 часов
• отдача по deeplink https://pass.puregym.local/{id}

The Great Gym Heist
Запустил сервер на домашнем Raspberry Pi. Первый вход — 3 секунды, без приложения. Через неделю 50+ человек используют мой сервис. Никто не заметил.

Apple Watch
Добавил Watch-расширение: показ pass на двойное нажатие боковой кнопки. Работает даже без телефона.

Цифры

• 47 → 3 секунды входа
• 282 → 18 секунд в неделю
• 50+ пользователей
• 0 жалоб

Бонус
Сделал push-уведомления, если pass не обновился. Добавил темную иконку для Vision Pro.

Неловкая правда
PureGym мог бы сам выдать Wallet-pass за день работы. Но 8 лет никто не заметил.

Этика
Никаких персональных данных не храню, только токен. Если закроют — открою исходники.

Что дальше
Планирую добавить NFC-таг у входа: поднёс Watch — дверь открылась.

• Пользователи делятся опытом работы с ужасным официальным приложением PureGym: медленный старт, отключение фоновой музыки, веб-обёртка вместо нативного клиента.
• Автор статьи сделал собственный Swift-бэкенд и Apple Wallet-пасс, чтобы мгновенно получать обновляющийся QR-код и не ждать 7 секунд загрузки.
• Обсуждают безопасность: 8-значный PIN выдаётся самим сервисом, может быть скомпрометирован, а API, похоже, не имеет нормального rate-limit.
• Сообщают аналогичные истории с другими сетями (TrainMore, Fitness SF, Better) и спорят, почему компании не добавляют Wallet: «не приоритет», «слишком дорого поддерживать», «никому не платят за UX».
• Поднимают юридические вопросы: использование неофициального клиента может нарушать ToS или законы (CFAA в США), но многие считают это разумным «гражданским хакингом».