Hacker News Digest

Разработчик дообучил языковую модель Qwen2.5-Coder-0.5B на 360 млн параметров, чтобы она вела себя как настоящий терминал. За демонстрацией нет ни оболочки, ни файловой системы: каждое нажатие клавиши подаётся на вход, а модель предсказывает, как изменится экран. Она умеет создавать файлы, запускать vim и tmux, играть в «змейку» и обычно помнит, что вы вводили несколько команд назад. Наберите pythoon — и увидите, что это не настоящая оболочка.

Терминал представлен сеткой символов, а не пикселей, поэтому обучающие данные можно генерировать в неограниченном объёме, запуская реальные программы в Docker. Модель не видит сетку напрямую — она получает последовательность токенов с содержимым экрана, позицией курсора и изменениями. Вместо потока текста она предсказывает, какие строки перерисовать и куда переместится курсор. Время тоже подаётся на вход: если ничего не нажато, приходит токен ожидания с длительностью — так «змейка» движется сама. Главные удачи — обучение модели исправлять собственные ошибки и параллельное декодирование строк экрана.

Демонстрация рассчитана на настольный браузер с WebGPU и физической клавиатурой, лучше всего работает в Chrome или Edge. Это загрузка на 208 МБ, всё выполняется локально. В планах — обучение на тысячах случайно сгенерированных приложений, чтобы проверить, сможет ли модель предсказывать поведение программы, которую никогда не видела. Веса обещают выложить позже.

Обсуждение дополняет статью идеями применения проекта, сравнением с аналогами и первыми отзывами. @donperignon отмечает, что в реальных тестах модель работает нестабильнее, чем в демо: она ошибается при создании папок и теряет состояние. @Meleagris и @gdevenyi предлагают использовать модель для создания интерактивных honeypots. @amelius советует развивать идею в сторону симуляции конкретного пользователя или интернета (через lynx) вместо общего терминала. @thorum и @aurareturn видят в этом будущем интерфейсов, где локальные модели генерируют UI в реальном времени. Проект сравнивают с vibeSH (@rowbin), Voidware (@ohadpr) и симуляцией Quake II от Microsoft (@psandor). По мнению @andai, выбор Qwen2.5-Coder в качестве базы оправдан её знакомством с синтаксисом CLI.

Google опубликовал руководство по стилю Rust — часть серии открытых стайлгайдов. Документ опирается на публичные правила оформления Rust и требует применять правила проектирования API с учётом контекста. Среди ключевых требований: предпочитать небольшие крейты, использовать плоскую структуру файлов для исходников rust_library, называть файлы и листовые модули по главному пользовательскому элементу, не реализовывать API в нелистовых модулях, избегать глобальных импортов через * и импортировать элементы одного модуля одним выражением use. Имена типов импортируются и используются без квалификации, а вызовы функций верхнего уровня — с именем модуля.

Отдельные разделы посвящены владению и заимствованию: рекомендуется избегать Rc и Arc, предпочитать заимствования глубоким копиям. Для входных и выходных параметров советуют принимать гибкие ссылки на неизменяемые данные, выбирать между итераторами и коллекциями осознанно, использовать Into, а также предпочитать enum вместо bool в API. Запрещён вызов panic::catch_unwind — исключение сделано лишь для защиты в глубину там, где код и так избегает паник, и только при panic=unwind; Chrome, Android и Fuchsia требуют panic=abort. Для конкатенации и подстановки строк предпочтительны format! и write! вместо + и str::replace. Тесты следует писать в рамках фреймворка конкретной кодовой базы: в Chrome — rust_gtest_interop, в Fuchsia — #[fuchsia::test].

В Chromium небольшие крейты ускоряют компиляцию и упрощают построение графа зависимостей, так как позволяют эффективнее использовать параллельность сборки. В Blaze/Bazel отсутствует инкрементальная компиляция крейтов, поэтому разделение кода на мелкие библиотеки ускоряет кеширование и пересборку измененных частей, а также уменьшает нелокальные эффекты при добавлении зависимостей в монорепозитории. При этом не следует путать мелкие крейты с микрофункциями. Рекомендации по коду: — использовать `#[non_exhaustive]` только для публичных `enum` с ожидаемыми новыми вариантами (хотя ведутся споры, не ослабляет ли это гарантии компилятора); — применять неквалифицированные имена импортов только для широко известных типов (например, `HashMap`), сохраняя полные пути для остальных; — использовать `Arc` или `Rc` вместо сложных жизненных времен, если ссылка живет дольше стека вызовов; — добавлять атрибут `#[rust_analyzer::prefer_underscore_import]` для расширяющих трейтов; — писать шестнадцатеричные литералы в нижнем регистре. Особенности и споры: — Запрет на `async/.await` в Chromium соответствует политике проекта и рекомендациям Rust for Linux. — Создание единого гайдлайна Google по Rust полезно для согласованности кода, настройки `fmt` и `clippy`, хотя есть мнение, что стиль-гайды сейчас нужны скорее для LLM, чем для людей. — Сохраняются разногласия о целесообразности геттеров и сеттеров.

Для сжатия фотографий с потерями в вебе AVIF почти всегда даёт файлы меньше, чем JPEG XL: при настройках усилия по умолчанию лучший результат JPEG XL обычно на 15–25% больше, а при максимальных настройках разрыв сокращается до 6–20%. Бывают исключения, где JPEG XL близок к AVIF или даже обгоняет его, поэтому для конкретного изображения стоит пробовать оба формата. Для скриншотов и иллюстраций AVIF заметно лучше: эквивалентный JPEG XL больше на 30–90% при обычных настройках и на 20–70% при максимальных. Для изображений с прозрачностью AVIF тоже выигрывает: версия libjxl больше на 31–44% и 61–70% соответственно, а jixel всегда кодирует прозрачность без потерь, из-за чего файлы в 2–3 раза крупнее, чем у AVIF.

Выбор кодера JPEG XL сильно влияет на результат: новый jixel обычно даёт меньшие файлы, чем libjxl, кроме изображений с детальной прозрачностью. AVIF в целом быстрее кодируется и требует меньше памяти с учётом размера файла, а декодируется в 2–3 раза быстрее JPEG XL при среднем качестве, хотя на очень высоких качествах разрыв сокращается. Повышенные настройки усилия оправданы для AVIF и jixel, но не для libjxl: они намного медленнее, расходуют больше памяти и почти не улучшают результат, иногда даже увеличивая файл. Режим 4:2:0 у AVIF не стоит делать значением по умолчанию — он редко уменьшает размер и затрудняет достижение высокого качества, хотя быстрее кодируется и декодируется; лучше использовать 4:4:4. Настройки качества работают надёжно у всех кодеров.

Анимированный AVIF по сути представляет собой переупаковку видео AV1 — MP4 можно преобразовать в AVIF и обратно без потерь, поэтому он так хорошо работает с движением. Однако в Chrome и Safari он воспроизводится плохо, хотя в Firefox всё в порядке: это чисто проблема реализации. При этом анимированный AVIF поддерживает прозрачность, чего нет у видео AV1.

Обсуждение дополняет статью практическими данными о качестве энкодеров, проблемами рендеринга в браузерах и специфическими сценариями использования (анимации, HDR, архивация), при этом подтверждая преимущество AVIF в размере файлов для веба.

• Спор: Пользователь @PaulHoule заметил потерю деталей в бликах на фото F1 в AVIF, однако @jaffathecake пояснил, что это было вызвано некорректной работой WASM-рендерера в браузере без поддержки JPEG XL, а не самим форматом.

• Спор: По мнению @linolevan, текущие энкодеры JPEG XL недостаточно оптимизированы: использование более качественного энкодера позволило ему уменьшить размер lossless-скриншота на 39% и иллюстрации на 30% по сравнению с результатами в статье.

• Совет: Для достижения максимального сжатия AVIF с сохранением прозрачности PNG @Metricon рекомендует использовать ffmpeg с параметрами: libaom-av1, crf 25, cpu-used 3 и специфическими настройками sharpness и chroma-deltaq.

• AVIF считается более подходящим форматом для замены GIF и создания анимаций с прозрачностью, так как он фактически является переупакованным видео AV1, оптимизированным под движение.

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

• Совет: По опыту @yhjc2692, медленная работа libjxl на высоких настройках (efforts >7) связана с итеративной оптимизацией метрики Butteraugli; для ускорения процесса он разработал GPU-порт gjxl (CUDA/Metal).

• AVIF выигрывает на маленьких изображениях, в то время как JPEG XL предпочтительнее для lossless-сжатия, высокобитрейтных изображений и прогрессивного рендеринга.

• Контейнерная архитектура AVIF может упростить будущий переход на новые кодеки (AV2, AV3) без необходимости повторного внедрения формата на сайтах.

I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) — @linolevan

Перевод: Мне кажется, люди забывают, что энкодеры JXL сейчас работают плохо. Например, в статье Джейк приводит скриншот Firefox с lossless JXL размером 66,9 кБ, в то время как с более качественным энкодером его можно сжать до 40,7 кБ (на 39% меньше).

Игры PlayStation 2 запускаются прямо в браузере благодаря статической рекомпиляции: машинный код Emotion Engine заранее переводится в C++ и компилируется в WebAssembly, поэтому главный процессор никогда не интерпретируется. Остальная консоль — её операционная система и аппаратура — эмулируется средой выполнения, которая рисует через WebGPU. Первой игрой стала Gran Turismo 4, одна из самых требовательных на системе: она опирается на оба векторных блока, на точное поведение чисел с плавающей точкой в повторах и лицензионных тестах и на графические трюки с чтением отрисованных изображений как палитр. Игра проходит от загрузки через вступительный ролик, меню и гонки, со музыкой и звуками, и сохраняется на карту памяти, хранимую в браузере. Гонка идёт на полной скорости — 50 кадров в секунду для европейской версии — в Chrome на встроенной графике ноутбука при вдвое большем разрешении, чем у PS2.

God of War II заработала на тех же скриптах без кода под конкретную игру, но вскрыла два бага, которых Gran Turismo 4 не вызывала: один в рекомпиляторе, другой в таймингах векторного блока, плюс нехватку частей процессора ввода-вывода. Теперь она идёт от меню через катсцены в бой и держит 60 кадров в секунду в тяжёлых схватках при родном разрешении PS2, а при удвоенном — от 48 до 60, упираясь во встроенную графику. Данные игр не входят в репозиторий: вы приносите образ своего диска, а скрипты превращают его в веб-страницу на вашей машине. Диск читается через HTTP-запросы диапазона, поэтому сначала скачивается только исполняемый файл. Карту памяти можно выгрузить в формате .ps2, совместимом с PCSX2, и перенести между браузерами. Страница требует изоляции источников из-за SharedArrayBuffer, а сгенерированный код принадлежит правообладателям игр — публиковать его нельзя.

Обсуждение вызывает скепсис относительно термина «рекомпиляция», так как проект фактически остается эмулятором с вшитым образом, а не полноценной статической рекомпиляцией. Пользователи @vrighter и @anonymous908213 отмечают, что лишь часть кода переведена в функции, а автор позиционирует проект как «без эмулятора», что противоречит реальности. Сообщество признаёт, что современные LLM ускорили декомпиляцию и рекомпиляцию игр, но это вызывает опасения по качеству и достоверности заявлений. @aceazzameen выражает обеспокоенность скрытым вредоносным ПО, на что @johnfn отвечает, что WebAssembly является одной из самых безопасных сред исполнения. По опыту @kodablah, аналогичный ARM-to-WASM подход для PS Vita работает эффективно в Chrome на флагманских Android-устройствах. Пользователь @Hyperlisk разрабатывает схожий инструмент с фокусом на точность, используя рекомпиляцию в Golang для поддержки SIMD.

Apple запустила кампанию «Switch to Safari», призванную убедить пользователей отказаться от Chrome. На новом сайте и в двух роликах на YouTube компания называет Safari «более мощным и приватным браузером, чем Chrome». В числе заявленных преимуществ — экономия батареи, усиленная защита приватности и более высокая скорость.

Ключевые цифры: до 5 часов дополнительного просмотра видео на Mac по сравнению с Chrome и до 35% более быстрая загрузка часто посещаемых сайтов. Apple также упрекает Chrome в том, что тот не запоминает, какие отвлекающие элементы пользователь хочет скрыть, и позволяет большему числу сторонних трекеров следить за людьми в сети и продавать их данные рекламодателям. На сайте есть сравнительная таблица Safari и Chrome, а также описания режима чтения, функции «Notify Me», профилей и Apple Pay.

В роликах показаны «Distraction Control» и «Intelligent Tracking Prevention». Это не первый случай прямого противопоставления: ранее в этом году Apple уже запускала кампанию «Privacy on iPhone», продвигая Safari как более приватную альтернативу Chrome.

Пользователи скептически относятся к кампании Apple из-за монополии Safari в iOS, отсутствия кроссплатформенности и проблем с инструментами разработчика, несмотря на признание его энергоэффективности. Спор о производительности: @koinedad и @bobmarleybiceps отмечают, что Chrome потребляет много памяти и вызывает зависания на Mac, тогда как Safari работает стабильнее; @pantulis считает, что скорость Safari не является его преимуществом. Критикуется закрытость экосистемы Apple: @TheDong и @freakynit подчеркивают, что Safari обладает неоправданной монополией на iOS из-за запрета сторонних движков браузеров. Ключевым барьером для перехода является кроссплатформенность: @glimshe и @maidaman не могут использовать Safari на Windows или Linux, что делает его непригодным для многоплатформенной работы. Разработчики недовольны инструментами Safari: @wereHamster называет devtools «хуже мусора», а @PrimalPower жалуется на специфические ошибки совместимости при экспорте PDF. Пользователи отмечают функциональные недостатки: @freetime2 указывает на проблемы с переводом страниц через POST-запросы, а @curt15 упоминает ограничения Manifest v3, мешающие работе uBlock Origin. Совет: многие пользователи (@jacquesm, @hollowonepl, @potatoproduct) рекомендуют переходить на Firefox как альтернативу корпоративным монополиям. По опыту @geuis, переход на Chrome был революционным из-за скорости и JS-рантайма, но сейчас его удерживает лишь мышечная память и недовольство Manifest v3.

Chrome 155 добавил поддержку JPEG XL — современного формата изображений, обеспечивающего на 30–50% лучшую компрессию по сравнению с JPEG, включая lossless режим и нативную поддержку HDR. Реализация выполнена на Rust в библиотеке jxl-rs, что устраняет типичные уязвимости C++-кодеков (переполнение буфера, use-after-free) благодаря памяти-безопасному языку, при этом сохраняя высокую производительность через SIMD-оптимизации, вдохновлённые библиотекой Highway и использующие стабилизированную функцию target_feature_11. Разработчики подтвердили отсутствие memory safety багов после omfattющего fuzzing и AI-поддержки проверки кода. Поддержка JPEG XL в Chrome стала результатом давнего запроса сообщества, отражённого в Interop 2026, где формат был одним из самых популярных предложений. Команда призывает веб-разработчиков использовать .jxl в своих пайплайнах для более быстрой, богатой и безопасной веб-среды, обещая продолжать улучшать формат на основе обратной связи.

Firefox планирует добавить поддержку JPEG XL в версии 158, расширив кросс‐браузерную совместимость. Chrome ранее удалил поддержку в версии 110, но восстановил её в Chrome 155, что указывает на смену стратегии. Safari пока не поддерживает прогрессивную загрузку в libjxl, а также анимацию и прогрессивный рендеринг JPEG XL на iOS, отставая от Chrome и Firefox, которые уже включили эти возможности. По данным caniuse, поддержка JPEG XL составляет лишь ~17 % сайтов, в отличие от ~97 % для WebP, что отражает низкую текущую адаптацию. Совместимость с приложениями остаётся проблемой: Telegram, macOS и многие просмотрщики не открывают JXL‐файлы. Rust‐реализация обеспечивает защиту от типичных уязвимостей C++ (переполнение буфера, use‐after‐free), но её производительность может варьироваться — заявленная скорость «примерно так же быстро, как лучшая небезопасная альтернатива» требует проверки на реальной нагрузке. Для типичного веб‐контента AVIF обычно показывает лучшую компрессию и скорость, тогда как JPEG XL считается менее подходящим. По расширению .jxl нельзя определить, используется ли сжатие с потерями или без, что усложняет пользовательский опыт. Создание JPEG XL в некоторых графических редакторах (например, Affinity) даёт плохие результаты и нестабильную компрессию, отпугивая пользователей. Для научных изображений, требующих более 8‐битной глубины, лучше использовать AVIF, так как текущий декодер JPEG XL ограничивает внутреннее представление 8‐битами.

JPEG XL — технически впечатляющий кодек, превосходящий JPEG и более универсальный, чем WebP, но его место в браузерах под вопросом. Хотя он был отклонён Chrome в 2023 году, появление Rust-декодера в Firefox и Chrome может сигнализировать о пересмотре позиции, особенно на фоне уязвимости WebP 2023 года. Однако автор, ранее поддерживавший JPEG XL, теперь считает, что его преимущества для веба исчерпаны. По объёму веб-контента подавляющее большинство изображений обслуживается с потерями, а без потерь JPEG XL выигрывает лишь около 11,9% перед WebP — на искусственном наборе данных (157 Мп фото, 10 Мп иллюстраций, 27 Мп книг), неrepresenting типичный веб. Это слишком мало, чтобы оправдать внедрение нового кодекса в браузеры, особенно учитывая, что в lossy-сжатии JPEG XL уступает конкурентам.

Современные энкодеры, включая AV1, достигли лучшего соотношения скорости и качества на бит благодаря perceptual tuning на основе человеческих испытаний. AVIF теперь доминирует во всём диапазоне fidelity, нивелируя единственное реальное преимущество JPEG XL. Автор отмечает, что дискуссия вокруг JPEG XL часто отражает желание большего выбора для разработчиков, а не техническую необходимость, особенно на фоне политики вокруг Google и AV1. Тем не менее, JPEG XL остаётся ценным для профессиональных сценариев вне веба — фотографии, печать, медицинская визуализация — где его возможности могут быть востребованы. В браузерах же его внедрение сейчас не кажется оправданным.

Обсуждение подтверждает сомнения автора в перспективах JPEG XL для веба, добавляя данные о производительности, сложности реализации и ограничениях аппаратного декодирования, а также подчёркивая политические и патентные факторы, влияющие на его принятие, но указывает на потенциальные ниши в профессиональном фото‐ и RAW‐рабочем процессе. libjxl и cjpegli позволяют получать компактные, высококачественные изображения даже для контента с высоким частотным спектром, например комиксов, где другие кодеки требуют компромиссов. WebP‐lossless ограничен 8‐битным RGB, поэтому отдельный формат для истинно lossless‐изображений остаётся необходимым. JXL‐preview в macOS сильно нагружает процессор и память из‐за вычисления «prime», что делает его потенциальным вектором DoS даже для небольших файлов. JXL выигрывает в lossless‐сжатии над WebP и PNG, но в lossy‐режиме часто уступает AVIF и даже обычному JPEG. Аппаратные декодеры AVIF ограничены профилем Main (4:2:0), что делает его менее подходящим для фотосъёмки, где предпочтителен 4:4:4 и 10‐бит. Спор: Некоторые считают, что отсутствие поддержки браузерами препятствует использованию JXL вне веба, в то время как другие указывают, что основные сценарии (например, отправка фото по e‐mail) всё равно требуют транс‐кодирования. Спор: Вопрос открытости: JXL полностью открытый, тогда как AVIF основан на AV1, который хотя и royalty‐free, но имеет патентные споры (Sisvel/Access, Dolby vs Snap), что меняет баланс сравнения. Камеры пока не поддерживают JPEG XL; поддержка ограничивается HEIF, а JPEG остаётся доминирующим форматом из‐за совместимости. Adobe включил JPEG XL в PDF, что может заставить браузеры добавить поддержку формата для корректного отображения PDF‐документов. Совет: Для веб‐публикаций рекомендуется удалять метаданные и транскодировать в уже поддерживаемый формат, поскольку экономия трафика от JXL не компенсирует совместимостиных проблем.

Firefox остаётся важным инструментом для сохранения разнообразия в веб-браузерах, несмотря на критику и переход некоторых пользователей на альтернативы вроде Vivaldi. Автор подчёркивает, что отказ от Firefox из-за его присутствия в соцсетях (включая X, ранее Twitter) является излишним, особенно когда альтернативы также используют те же платформы. Ссылка на поговорку «не выплескивай ребёнка вместе с водой» служит метафорой: не стоит отказываться от браузера из-за мелких раздражений, игнорируя его фундаментальную ценность.

Без Firefox рынок браузеров оказался бы доминирован движком Blink (Chrome и его производные, включая Vivaldi, Opera, Edge), оставляя лишь Safari как маловероятного конкурента из-за его привязки к экосистеме Apple. Автор отмечает, что присутствие Firefox в X — это стратегическая попытка привлечь новых пользователей на фоне падающей глобальной доли рынка, и призывает поддерживать проект, поскольку независимые движки браузеров критически важны для инноваций, конкуренции и открытого веба. Поддержка Firefox — это не просто предпочтение, а необходимость для будущего интернета.

Firefox критически важен для разнообразия движков: альтернативы вроде Ladybird и Servo ещё не достигли функциональной зрелости (по данным WPT: Firefox — 90.6%, Ladybird — 84.2%, Servo — 74.4%), а Chromium-форки не решают проблему монополии. Его уход ускорит доминирование Chromium. Проблема — в управлении Mozilla, а не в браузере: уход Eich, финансирование от Google, внедрение функций вроде Pocket и телеметрии, игнорирование производительности и маркетинговые инициативы подрывают доверие сообщества. Зависимость от Google неизбежна: для устойчивости без рекламы потребовалась бы подписка ~$150/год от 10 млн пользователей, что нереалистично. К техническим недостаткам относят высокое потребление RAM, нестабильную производительность и ухудшение UX на десктопе, а также необходимость ручной настройки через about:config и userChrome.css, что делает Firefox непригодным для обычных пользователей, но привлекательным для продвинутых. На iOS Firefox — лишь обёртка над WebKit, что снижает его ценность. При этом Firefox — единственный браузер с полноценной поддержкой расширений на мобильных устройствах. LibreWolf и Zen предлагают более чистую альтернативу без телеметрии и Pocket. Пользователи Unix-десктопов сохраняют Firefox из-за интеграции с системой; на Windows/macOS часто предпочитают Chrome ради совместимости с корпоративными сервисами. Отказ от Firefox из-за его присутствия в соцсетях иррационален: все браузеры, включая Chrome и Safari, используют те же платформы для маркетинга, и это не влияет на технические характеристики.

Google удалил все оставшиеся расширения Manifest V2 из Chrome Web Store, включая популярный блокировщик рекламы uBlock Origin. Это завершило многолетний переход на Manifest V3, который Google позиционирует как более безопасный и производительный стандарт. Расширения, установленные до Chrome 138, останутся в браузере, но больше не смогут получать обновления или быть переустановлены из магазина после удаления.

Изменение затрагивает не только Chrome, но и другие Chromium-браузеры, такие как Brave, которые полагаются на Chrome Web Store как на основной источник расширений. Однако Brave решил сохранить доступ к четырём популярным Manifest V2-расширениям — uBlock Origin, uMatrix, NoScript и AdGuard — разместив их на собственном сервере и позволив пользователям включать их напрямую в браузере. Google утверждает, что Manifest V3 обеспечивает лучший контроль над доступом расширений к данным пользователей, решая легитимные проблемы безопасности и конфиденциальности.

Пользователи воспринимают удаление MV2 как стимул перейти на Firefox или другие браузеры. Большинство советуют Firefox как основной способ сохранить блокировку рекламы; среди альтернатив также упоминаются Brave, Zen и LibreWolf. В Chrome можно использовать uBlock Origin Lite — облегчённую версию на MV3 от того же автора, обеспечивающую базовую блокировку. Один пользователь считает, что встроенный блокировщик Chrome пока достаточен и миграция не обязательна. Полную версию uBlock Origin можно установить в Edge — это подходит менее технически подкованным пользователям и позволяет избежать навязчивых Chrome‐сообщений. В MV3 убрана возможность динамического перехвата запросов, из‐за чего uBlock Origin теряет часть функций. Ожидается появление независимых маркетплейсов расширений для форков Chromium, что может компенсировать ограничения. Многие расценивают переход на MV3 как способ Google усилить контроль над расширениями, особенно блокировщиками рекламы, из‐за конфликта интересов между рекламным бизнесом и контролем над браузером. Некоторые отмечают, что Firefox потребляет больше оперативной памяти, чем Chromium‐браузеры.

Отключить навязчивый ИИ — частая задача для тех, кто хочет сохранить контроль над своим цифровым пространством. Главное правило: сначала выключайте функции, которые явно нарушают привычный интерфейс — например, в Adobe Acrobat и Reader есть отдельные разделы «Generative AI», где достаточно снять галочку и сохранить настройки. На мобильных платформах, особенно в Android-смартфонах с встроенным Gemini, отключить ассистента можно через настройки приложения «Messages» или раздел «Connected Apps», где отключаются как Gemini, так и «Personal Intelligence». На iOS и macOS Apple Intelligence требует полного отключения в «Apple Intelligence & Siri», а также отключения «Learn from this App» в настройках приложений, даже если основной режим выключен. Для браузеров с встроенным Copilot в Chrome флаг GLIC скрывает все AI-функции, а в Windows можно использовать O&O ShutUp 10 или Win11DeBloat для полного удаления Copilot. Yahoo Mail и Zoom тоже предлагают отключить AI-анализ писем и транскрибирование встреч через меню настроек. Важно помнить: многие сервисы включают AI по умолчанию, поэтому проверяйте параметры регулярно — особенно в Zoom, где новые функции появляются часто. Для полного контроля рекомендуется использовать альтернативные браузеры вроде Zen или Helium, а также следить за обновлениями в библиотечных ресурсах, где публикуются актуальные гайды по сопротивлению нежелательным технологиям.

Пользователи сталкиваются с системным принуждением к ИИ: корпорации намеренно делают его неотделимым от базовых функций, блокируя ключевые возможности при отключении — например, отключение Siri в CarPlay лишает доступа к картам и музыке без телефона. ИИ-функции добавляются не для улучшения опыта, а для привлечения инвестиций, несмотря на рост эксплуатационных расходов и отсутствие реальной потребности — как в PDF-редакторах Adobe. Для отключения ИИ: — В Google добавляйте `udm=14` или фильтр `-fuck` для подавления суммаризации; — Используйте uBlock Origin и Element Hider для скрытия AI-элементов в Google, Amazon и других сайтах; — В Chrome — расширение Adios Alexa for Shopping для блокировки всплывающих окон Alexa; — На Mac — Wairy.app для аудита и отмены разрешений (частично заблокирован за платой); — Переход на Linux устраняет навязчивый ИИ из macOS и Windows; — Альтернативные браузеры Zen и Helium (на базе Firefox и Chromium) предлагают чистый интерфейс без ИИ-элементов. Самый эффективный способ — отказ от продуктов, где ИИ нельзя отключить, что упрощает цифровую жизнь. NoToAI.org — открытый ресурс сообщества для отслеживания способов отключения ИИ.

Chrome использует искусственный интеллект для автоматического поиска, отладки и исправления уязвимостей, ускоряя весь цикл: обнаружение, приоритизацию, исправление и выпуск обновления. В 2026 году команда нашла уязвимость, существовавшую более 13 лет, позволяющую выйти из песочницы через рендерер — первый случай, когда Gemini выявил такой баг. Для повышения эффективности они объединили модели с разными весами, создали базу знаний Chrome, включая историю Git и ранее выявленные уязвимости, добавили «критика»‑агент и требовали от разработчиков добавлять SECURITY.md, чтобы модели лучше понимали границы доверия. Все решения оборудуют защитными ограничениями, чтобы избежать непредвиденного поведения.

Для своевременного патчинга они интегрировали сканирование уязвимостей из NVD и OSV, а также перешли к автоматическому обновлению всех сторонних зависимостей, используя сигналы GOSSIP для оценки рисков. Цель — выкатывать исправления быстрее, чем могут их использовать злоумышленники, и обеспечить непрерывную защиту без вмешательства пользователя. Таким образом, каждая найденная и исправленная уязвимость уменьшает возможность атаки, а ИИ усиливает возможности защиты, делая браузер и интернет безопаснее с каждым обновлением. Это устраняет сотни потенциальных точек входа для атак и повышает устойчивость к новым угрозам.

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

Веб‑интерфейс позволяет исследовать черную дыру в трёх визуальных режимах: обычный экран, дополненную реальность, открываемую в Chrome на Android, и полностью погружающий виртуальный мир, требующий шлем виртуальной реальности. В каждом режиме отображается искажённый свет, вращающийся аккреционный поток и камера, а пользователь может менять угол обзора, вращать сцену касанием и переключать между режимами. Режим «Камера» показывает всё‑поглощающее искажение, а режим «AR» позволяет увидеть её в привычном окружении. Переключение происходит мгновенно, а интерфейс подсвечивает доступные опции, включая включение статистики и настройку экспозиции. Также можно менять яркость, контраст и масштаб отображения, а также сохранять выбранные настройки для последующего использования.

Настройки включают параметры вращения, угла наклона диска, лог‑армидные величины амплитуды, периода, скорости света и частоты излучения. Пользователь может включать статистику, регулировать экспозицию, масштабировать сцену и выбирать тип линзирования. Особенно заметны переключатель «slow light», позволяющий замедлить движение света, и возможность задавать период в единицах r₀/c, что меняет форму аккреционного диска. Есть также настройка axial width / r и trans width, влияющие на ширину и толщину потока, и параметр spin χ, определяющий угол наклона оси вращения.

Обсуждается физическая точность моделирования черной дыры: несоответствия в цвете аккреционного диска и эффектах Доплера, упрощения в симуляции. Некоторые пользователи испытывают дискомфорт из-за необычных визуальных эффектов и масштаба. Отмечены проблемы с отображением в дополненной реальности на отдельных устройствах. Пользователи делятся опытом использования симуляций и предлагают улучшать доступность и понимание астрофизических концепций через визуализации.

Orion Browser by Kagi — это браузер на ядре WebKit, сочетающий молниеносную нативную скорость с полной приватностью: отсутствие телеметрии, встроенный блокировщик рекламы и анти‑трекинг. Он поддерживает расширения Safari, Chrome и Firefox, а кураторская подборка из 20 проверенных дополнений позволяет настроить интерфейс под любые задачи. Пользователи могут менять каждый элемент оформления и функций, получая уникальный опыт без компромиссов.

Orion доступен для iOS и iPadOS, macOS, Linux (в бета‑режиме) и скоро появится в Windows, уже используют его около 4 млн человек, которым он предлагает «мгновенную работу» и «минимальное потребление батареи». Встроенная интеграция с сервисами Kagi позволяет искать, переводить и просматривать контент без переключения контекста. Проект полностью финансируется подпиской Orion Plus или единовременной лицензией, что исключает рекламу и сторонние партнёрства. Браузер исключает сбор данных, не передаёт их в сторонние сервисы, а также использует небольшую часть памяти, что делает его идеальным для ноутбуков. Пользователи отмечают, что Orion «работает быстрее Safari и потребляет в два раза меньше ресурсов», что подтверждает его эффективность.

Отзывы об Orion Browser противоречивы: хвалят скорость и приватность (без телеметрии, встроенный блокировщик рекламы) как альтернативу Chrome и Firefox, но массово жалуются на баги, отсутствие синхронизации между Mac, iPhone и Linux, закрытый исходный код и проблемы с менеджерами паролей — встроенным, Bitwarden, iCloud Passwords. Часть пользователей считает браузер стабильным для повседневки, другие возвращаются к Safari или Firefox из-за сбоев, тормозов на старых устройствах и неполной поддержки WebExtensions (uBlock Origin, SponsorBlock, вход по ключам доступа). Не хватает и интеграции с Apple — Apple Pay, 2FA-автозаполнение, 1Password, — узкой панели вкладок, поддержки Linux на Snapdragon X Elite. Отдельные участники избегают продукта из-за связи Kagi с Yandex. Советуют не покупать пожизненный доступ и ждать открытия исходников и исправления багов, а Linux- и Windows-пользователям — стабильной версии.

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 не всегда практичен.

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

• YouTube, Google Docs и другие сервисы Google стали причиной, по сути, смерти IE6, но в итоге привели к тому, что Chrome стал доминирующим браузером.
• Microsoft, Mozilla и другие не смогли быстро реализовать новые веб-стандарты, что привело к тому, что Google смог использовать свои собственные веб-стандарты для продвижения Chrome.
• В то время как Chrome стал доминирующим браузером, это не привело к лучшему вебу, потому что Google не заинтересован в улучшении веб-стандартов.
• Веб-стандарты стали менее открытыми и менее ориентированы на пользователя, в то время как Chrome продолжает доминировать.
• Это привело к тому, что веб-разработчики вынуждены тестировать свои сайты в первую очередь в Chrome, что в свою очередь ведет к тому, что сайты лучше работают в Chrome, чем в других браузерах.

Privacy Badger — это бесплатное расширение для браузеров, разработанное некоммерческой организацией Electronic Frontier Foundation (EFF), которое защищает пользователей от слежки в интернете. Оно автоматически обнаруживает и блокирует скрытые трекеры, которые собирают данные о поведении без согласия. В отличие от многих блокировщиков, Privacy Badger не полагается на заранее составленные списки, а учится на ходу, определяя трекеры по их поведению.

Расширение использует цветные ползунки (красный для блокировки, жёлтый для ограничения, зелёный для разрешения), давая пользователям прозрачный контроль. Оно совместимо с Chrome, Firefox, Edge, Opera и их мобильными версиями, а также поддерживает Global Privacy Control для усиления защиты. Privacy Badger блокирует только навязчивые элементы, сохраняя функциональность сайтов, и открыто распространяется с исходным кодом.

• Privacy Badger блокирует только те рекламные объявления, которые отслеживают пользователей, и дополняет uBlock Origin, но многие считают его избыточным при использовании uBlock.
• Ведутся споры о эффективности персонализированной рекламы: одни утверждают, что она устаревает и неэффективна, другие приводят данные о её высокой рентабельности.
• Контекстная реклама, основанная на содержимом страницы, предлагается как альтернатива, сохраняющая приватность, но её широкое внедрение ограничено.
• Некоторые пользователи выступают за полную блокировку всей рекламы и трекеров через комбинации инструментов вроде uBlock Origin и DNS-фильтров.
• Обсуждаются проблемы работы Privacy Badger: он может ломать сайты, не поддерживается на некоторых платформах (Safari iOS, Chrome на Android) и менее эффективен, чем ручная настройка uBlock.

Gemini теперь встроен прямо в браузер Chrome, позволяя получать помощь ИИ без переключения вкладок. Он анализирует открытые страницы, чтобы давать контекстные ответы, резюмировать статьи и помогать с исследованиями — всё это активируется по запросу пользователя.

Функция включает голосовой чат Gemini Live, сравнение вариантов на основе данных со страниц и управление активностью через настройки. Особенно удобно для мобильных пользователей: на Android работает поверх любого контента, а вскоре появится и в iOS-версии Chrome.

• Пользователи выражают обеспокоенность по поводу приватности и использования данных Google, отмечая неясность политик в отношении сбора и применения информации, отправленной в Gemini.
• Интеграция Gemini в Chrome воспринимается как слабая и неубедительная, многие сравнивают её с простым iFrame или уже существующими решениями от других компаний.
• Высказываются опасения о монопольном положении Google, рисках для безопасности и потенциальной утрате контроля пользователей над своими данными и веб-опытом.
• Некоторые пользователи рассматривают это как повод перейти на другие браузеры, такие как Firefox или Brave, чтобы избежать навязчивой интеграции ИИ.
• Обсуждается потенциальное негативное влияние на веб-экосистему, включая "кражу" кликов у сайтов и рекламодателей, а также алгоритмическую подачу контента.

Claude для Chrome: закрытый пилот

Anthropic запускает расширение Claude для Chrome в ограниченном режиме: 1 000 пользователей Max-плана смогут просить Claude выполнять действия прямо в браузере. Цель — собрать отзывы и отладить защиту перед публичным релизом.

Зачем браузерный агент

Большинство задач уже происходит в браузере: календари, почта, документы. Дав Claude доступ к кнопкам и формам, мы резко повышаем его полезность. Однако такой доступ открывает новые векторы атак.

Главная угроза: prompt injection

Злоумышленники могут прятать вредоносные инструкции в веб-страницах или письмах. Без защиты модель выполняет их без ведома пользователя.

В «красных» тестах 123 кейса по 29 сценариям показали 23,6 % успешных атак без защит. Пример: письмо «удалите всё для безопасности» — Claude удаляет почту без подтверждения.

Текущие защиты

• Разрешения: доступ к сайтам и действиям контролирует пользователь.
• Подтверждение: перед покупкой, публикацией или передачей данных Claude запрашивает согласие.
• Фильтры: блокируются сайты финансов, взрослого контента и пиратства.
• Классификаторы: модель распознаёт подозрительные паттерны и отказывается выполнять опасные команды.

Пилот продолжается; доступ расширят по мере роста надёжности.

• Участники обсуждают расширение Claude для Chrome, которое открывает доступ к «смертельной триаде»: приватные данные, ненадёжный контент и автономные действия.
• Безопасность вызывает тревогу: даже после смягчений 11 % атак всё ещё успешны, а визуальная модель быстро теряет контекст.
• Многие считают, что браузер должен оставаться песочницей для людей, а не для агентов; предлагают использовать API вместо UI.
• Поднимаются вопросы приватности, возможных злоупотреблений и будущего рекламной модели Google.
• Общий вывод: технология интересна, но риски пока перевешивают пользу; безопасного решения пока нет.