Hacker News Digest

Современные методы отслеживания пользователей перешли от сторонних cookies к более надёжному и труднообнаруживаемому способу — браузерному отпечатку (fingerprinting). Он собирает десятки технических деталей: модель GPU, поддержка WebGL, шрифты и рендеринг текста в canvas, настройки Intl (часовой пояс, локаль, календарь), количество ядер CPU, объём памяти, язык браузера и даже результаты криптографических хэшей через crypto.subtle. Эти данные объединяются в уникальный идентификатор, который остаётся стабильным даже при смене IP через VPN, очистке cookies или использовании режима инкогнито — только при смене устройства он меняется, но остаётся предсказуемо постоянным для каждого гаджета.

Этот отпечаток позволяет рекламным сетям и брокерам данных связывать ваше поведение на разных сайтах, создавая детальный профиль: интересы, привычки, даже диалоги с ИИ, если сайт их сохраняет по политике конфиденциальности. В отличие от cookies, отпечаток нельзя просто удалить — он встроен в ваше устройство и браузер. Google, несмотря на публичные обещания отказаться от сторонних cookies к 2022 году, в итоге отложил это из-за давления рекламного бизнеса и неудач Privacy Sandbox, а в 2025 году официально разрешил использование fingerprinting в своих рекламных продуктах. Таким образом, пользователь становится не субъектом с правами, а источником предсказуемых паттернов — цифровым фракталом, чьё поведение монетизируется высшим бiddером, будь то рекламодатель, государство или брокер данных. Ваша индивидуальность сводится к набору измеряемых параметров — вы становитесь шестернёй в машине профилирования, а не её хозяином.

Тема раскрывает, что отпечатки действительно заменяют куки благодаря широким возможностям JavaScript, однако их практическая стабильность ограничена, коммерческие сервисы всё ещё полагаются на IP, а реальные защиты (расширения, браузеры) лишь частично снижают уникальность; участники считают, что единственное надёжное решение — законодательное, при этом предлагаются варианты добровольного таргетинга.

• Все согласны, что основная причина возможности отпечатков — JavaScript, который раскрывает браузеру детали аппаратуры, часовой пояс, язык и т.д., тогда как чистый HTML предоставляет лишь IP и User‐Agent.

• Спор: Сторона A ( @legitster): отпечатки нестабильны, большинство коммерческих сервисов всё ещё полагаются на IP, а без него идентификация быстро деградирует. Сторона B ( @alkonaut): если бы пользователи могли добровольно предоставить гео‐данные, пол, возраст и интересы, то целевая реклама была бы приемлемой, а скрытый сбор отпечатков — неприемлем.

• Совет: Для снижения уникальности рекомендуется использовать расширения Chameleon (ротация профилей) совместно с JShelter в строгом режиме, как советует @absqueued.

• Практические наблюдения показывают разную стабильность: в Vanadium ID остаётся одинаковым даже в инкогнито, а в Firefox с uBlock и CanvasBlocker отпечаток меняется при каждой перезагрузке страницы.

• По мнению @boomlinde и @1a527dd5, европейский «cookie law» на самом деле регулирует любой способ слежения, а не только файлы cookie, поэтому согласие требуется и для отпечатков.

• Некоторые участники, например @exceptione, считают, что единственное решение — законодательное, сравнивая нарушение приватности с тяжкими преступлениями и требуя строгих санкций.

• Совет: Предлагается создать открытый API для целевого рекламного таргетинга, где пользователь явно соглашается делиться гео‐данными, полом, возрастом и интересами, как предлагает @alkonaut.

• Стоимость реального отпечатка подтверждается данными @jwally: Fingerprint.com берёт $0.004 за проверку и требует прокси‐сервер, что показывает, насколько сложна масштабируемая эксплуатация.

• Отметка @HughParry: анти‐fingerprint браузеры трудно отличить, поэтому трекеры могут переходить к более «грубым» отпечаткам, собирая менее детальные, но всё равно уникальные данные.

• По словам @sridevisridevi2, современные отпечатки позволяют обходить блокировщики рекламы и более эффективно продавать пользовательские данные, чем традиционные cookie.

LineageOS отмечает приближение десятилетнего юбилея проекта, который будет отмечаться 24 декабря 2026 года. Этот релиз, основанный на Android 17, стал возможен благодаря раннему ребейзу изменений после выхода Android 17 в июне, что позволило команде опередить график. Безопасность остаётся приоритетом: патчи с августа 2025 по октябрь 2026 интегрированы в ветки 18.1–24.0, а для старых версий (15.1–17.1) завершена бэкпортировка патчей до ноября 2025, хотя декабрьские обновления 2025 года остаются частично неадаптированными из-за сложности.

В приложениях LineageOS произошли значительные обновления: Canvas — новый редактор изображений с базовыми инструментами обработки; Catapult (Android TV Launcher) получил индикатор батареи и обновлённый UI; Etar обновлён до последней upstream-версии; Jelly теперь поддерживает PWA-подобные приложения через ярлыки; Twelve улучшил загрузку больших библиотек, добавил раздел «Most played» и исправил проблемы с аудио-offload; Updater перешёл на потоковые обновления по умолчанию, ускоряя установку на A/B-устройствах. Также добавлена поддержка десятков новых устройств, включая LG Velvet 5G, Motorola Edge 30 Ultra и несколько моделей Xiaomi и Nubia, что расширяет охват проекта.

LineageOS остаётся критически важным для продления срока службы старых устройств, где производители отказали в обновлениях. Пользователи активно используют его на Pixel 4a, OnePlus 7 и OnePlus 6T, чтобы избежать выбрасывания телефонов. Однако выявлен разрыв в приоритетах: GrapheneOS делает акцент на безопасности и своевременных обновлениях AOSP, тогда как LineageOS фокусируется на широкой совместимости. Поддержка устройств в LineageOS зависит исключительно от волонтёров-мейнтейнеров, владеющих устройствами — нет поддержки там, где никто не берётся на себя ответственность. Это объясняет отсутствие поддержки Mi 8 SE и неравномерность обновлений (например, Pixel 9 не поддерживается в LineageOS 24.0, в отличие от Pixel 9 Pro). На старых устройствах (Samsung Galaxy S5/S7) качество камеры может ухудшаться из-за отсутствия проприетарных драйверов, но проблему решает установка GCAM. На устройствах с разблокированным загрузчиком (OnePlus 7) LineageOS работает стабильно и лучше заводской прошивки без bloatware. Проблемы с RCS в групповых чатах на Pixel 4a с LineageOS связаны с разблокированным загрузчиком и не решаются системными обновлениями. LineageOS предоставляет только обновления пользовательского пространства, не включая ядерные патчи, что оставляет уязвимости в базовом стеке. Несмотря на заявления о поддержке сотен устройств, большинство — устаревшие модели; современные устройства (например, новые Motorola) представлены слабо. Использование на старых ноутбуках с x86_64 и Apple Silicon рассматривается как перспективное, но ограничено отсутствием поддержки аппаратных кодеков и камеры. GrapheneOS имеет преимущество в скорости обновлений благодаря доступу к проприетарным патчам безопасности через партнёрство с Motorola. LineageOS не рекомендует новые устройства для покупки, что затрудняет выбор новичкам. Для приложений, требующих доступа к данным (WhatsApp и т.п.), советуют использовать изолированные рабочие профили через Shelter для минимизации рисков приватности. LineageOS не заменяет GrapheneOS, а дополняет его — для устройств, не поддерживаемых более строгой системой. Оба проекта сосуществуют, удовлетворяя разные потребности пользователей.

Автор экспериментирует с созданием собственного текстового редактора, начиная с рендера на <canvas>, где реализовал базовые функции: позиционирование курсора, перемещение стрелками, подсветку текущей строки, ввод текста и анимацию курсора. Однако столкнулся с отсутствием выделения текста, undo/redo, многострочной вставки и прокрутки — последняя решена через скрытый <div> с нативным overflow, но доступность осталась проблемой. Перешёл на contenteditable с plaintext-only, получив бесплатную выделение, историю изменений и доступность, но обнаружил непредсказуемые проблемы с производительностью в Chromium при большом объёме текста. Попробовал <textarea> — оказался более производительным, особенно с подсветкой синтаксиса через дополнительный слой <div> и MicroLighter. Упомянул новые API: OpaqueRange для кастомных выделений в <textarea> и EditContext для улучшения ввода в <canvas>. Отметил, что слишком много CSS-подсветок создаёт узкое место, и предложил использовать Tree-sitter для генерации подсветки только видимых строк или применить «обратную липкую технику» для оптимизации скроллинга. Заключил, что для его задач contenteditable достаточно, так как редактируемые файлы малы. Демонстрации неоптимизированы и не идеальны по доступности, но отправной точки лучше, чем с <canvas>. Завершил примером на UTF-16 и графемах, показывающим сложность корректной работы с текстом в JavaScript.

Создание собственного текстового редактора — классический обучающий проект, но опытные разработчики сходятся во мнении, что существующие решения практичнее. Нативный `<textarea>` остаётся самым производительным и согласованным средством редактирования в браузере. Современные редакторы (Emacs, Sublime, VS Code) уже решают ключевые задачи — LSP, мультикурсоры, подсветку синтаксиса — и их повторная реализация ведёт к раздуванию, а не к улучшению. Canvas-подходы в браузере крайне сложны из-за отсутствия низкоуровневых API для ввода, макросов и системного взаимодействия, что делает их непрактичными. Использование скрытого `<div>` для прокрутки — признанный костыль, а рендеринг курсора на canvas часто ломается, особенно в Safari. Даже базовые функции — выделение, undo/redo, прокрутка — требуют сложных решений, которые уже реализованы в готовых инструментах. Производительность критична: небольшие задержки делают редактор непригодным, и лишь немногие (Sublime, Vim) сохраняют плавность на больших файлах. По этой причине лучше использовать фреймворки: CodeMirror 6 для веба, KTextEditor для Qt, Emacs для полной настраиваемости, а для экспериментов — модифицировать существующий редактор (например, Emacs с Org-mode или Magit). Спорные моменты: Sublime Text одни считают устаревшим, другие — непревзойдённым по отзывчивости. Часть участников полагает, что текстовое редактирование — решённая проблема и новшества — лишь конфигурация Vim/Emacs; другие указывают, что LSP и удалённое редактирование требуют новых архитектур. Тренд на использование AI поверх KTextEditor подтверждает: даже создавая «свой» редактор, разработчики опираются на существующие библиотеки.

Doomscrolling: игра
Скроллинг как единственный способ управления.

---

Идея
Классический дум-скроллинг → браузерная игра, где всё, что нужно — листать вниз. Никаких стрелок и прыжков.

Попытка №1: провал
9 месяцев назад ни один LLM не смог связать «скролл вниз» с «фон движется вверх». Получилась пародия на игру. Забросил.

GPT-5 и победа
Через пару часов — рабочий прототип.

• Враги: 5 спрайтов, 2 кадра, как у Space Invaders.
• Механика: Galaga, но вертикально. Игрок движется вперёд-назад, монстры «привязаны» к полу.

Кофе-морнинги на каникулах
По часу утром:

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

Финальный штрих: новости
Появляются мемориальные плиты с заголовками NYT за сегодня. Не влияют на геймплей, только отвлекают.
Игра = самый сложный RSS-ридер в мире.

ИИ всё ещё тупит
Когда LLM не понимает, прерываю диалог и начинаю новый с тем же промптом — срабатывает.

• Пользователи в восторге: человек без навыков кодинга собрал динамичную «дум-скролл»-игру, спросив ChatGPT сгенерировать всё.
• Механика: скроллинг = движение; враги и огонь идут снизу, игроку надо лутать апгрейды и убивать монстров.
• Впечатляет «лаборатория» со слайдерами для настройки спрайтов — пример Steve-Jobs-овского «конструктора калькулятора».
• Критика: нет инерции/чувствительности скролла, на больших экранах играть легче, можно «откатом» обмануть стену огня.
• Баг: одновременная смерть и 100-килл-бонус крашит игру.
• Общий вывод: простая, но свежая идея, показывающая, как LLM-инструменты открывают геймдев даже «не-программистам».

Lazy Brush — библиотека для рисования плавных линий мышью, пальцем или любым другим указателем.
GitHub | npm | Reddit

Параметры:

• Lazy radius (60 px) — минимальное расстояние, при котором кисть тянется к курсору.
• Friction (0.10) — инерция: 0 — без задержки, 1 — бесконечная.
• Brush radius (13 px) — толщина кисти, не влияет на логику.

Автор: dulnan

• Библиотека Perfect Freehand и её демо drawmote от автора TLDRaw признаны лучшей альтернативой для плавных подписей и рисования.
• Техника «ленивого» курсора с гистерезисом/стабилизатором уже применялась в Wii-играх, Krita, ZBrush, Black & White и других графических пакетах.
• Пользователи отмечают, что визуальный «поводок» между курсором и пальцем делает рисование интуитивным, особенно на мобильных устройствах и при работе мышью.
• Некоторые считают задержку слишком большой и предлагают использовать фильтр Калмана или DynaDraw для меньшего лага.
• Проект вызвал восторг («лучшее бесплатное», «шокирующе хорошо»), но кто-то жалуется на пропадающие линии и невозможность «естественных» штрихов.