Кто вообще кэширует ваш сайт

Кэш редко бывает один. Между вашим сервером и пользователем обычно стоит минимум три независимых хранилища копий:

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

Каждый уровень обновляется по своим правилам и не знает о существовании соседних. Поэтому «обновил — не работает» может означать три совершенно разные проблемы, и решать их нужно по отдельности.

Почему браузер не видит обновление

Браузер решает, использовать ли сохранённую копию файла или запросить новую, по заголовку Cache-Control, который сервер прислал вместе с этим файлом в прошлый раз. Директив несколько, и путаница вокруг них — обычное дело: no-cache не значит «не кэшировать», это значит «кэшировать, но каждый раз ревалидировать перед показом»; за настоящее «не хранить вообще» отвечает no-store. Если сервер прислал max-age=86400, браузер имеет полное право сутки ничего не спрашивать — то есть сутки отдавать сохранённую копию, даже не обращаясь к серверу.

Ревалидация тоже работает не вслепую. Для проверки актуальности файла сервер присылает ETag, то есть идентификатор его версии. При следующем запросе браузер подставляет его в заголовок If-None-Match. Если файл не изменился, сервер отвечает 304 Not Modified без тела ответа. Браузер использует сохранённую версию, поэтому трафик на повторную загрузку не тратится.

Поэтому жёсткое обновление страницы (Ctrl+Shift+R) часто «чинит» проблему — оно заставляет браузер игнорировать сохранённую копию и переспросить сервер заново. Но это симптоматическое решение: у пользователя, который просто открыл сайт как обычно, тот же файл ещё какое-то время будет браться из кэша.

Почему CDN отдаёт старую версию, даже когда ориджин уже обновлён

CDN — ещё один слой кэша: его копии лежат на edge-серверах между вашим сервером и браузером пользователя, физически ближе к тому, кто делает запрос. Edge-серверы CDN решают, отдать сохранённую версию или сходить на origin, по ключу кэша. Обычно это URL плюс набор заголовков, которые указаны в Vary, указывающем, какие варианты ответа нужно различать. Директива Cache-Control: s-maxage работает именно для таких shared-кэшей и имеет приоритет над max-age в CDN, хотя браузер её игнорирует.

Здесь и кроется вторая причина «обновил — не работает»: вы поменяли файл на origin, но edge-серверы CDN узнают об этом, только когда истечёт TTL их собственной копии — или когда вы явно скажете им сбросить кэш через purge. Purge — это команда, отличная от кэш-бастинга на стороне браузера. Purge удаляет сохранённый файл, поэтому при следующем запросе CDN обращается к origin. У крупных провайдеров эта операция быстрая: и Cloudflare, и Fastly заявляют медианное время распространения purge по всей сети менее 150 мс. Но всё равно запуск очистки остается отдельным этапом, который обычно добавляют в CI/CD-пайплайн и выполняют после успешного деплоя.

А что кэширует сам сервер

Третий уровень — кэш внутри приложения: сохранённый результат тяжёлого запроса к базе, посчитанная агрегация, готовый рендер страницы. Здесь чаще всего используют отдельное хранилище вроде Redis, которое инвалидируется вручную или по TTL — так же, как и CDN, только этим занимается уже код приложения.

Проблема та же, что и с CDN: если вы поменяли логику или данные, но забыли инвалидировать соответствующий ключ в этом кэше, приложение продолжит отдавать посчитанный заранее результат — код при этом будет полностью новым, а ответ пользователю — старым.

Почему нельзя просто выключить кэш

Соблазн понятен: раз кэш создаёт столько путаницы, почему бы не выставить везде no-store и не жить спокойно? Дело в том, что кэш — основа современной веб-инфраструктуры: без него задержки и нагрузка на серверы выросли бы на порядок.

Без кэша браузера каждая загрузка страницы заново скачивает все статические файлы: шрифты, картинки, JS-бандлы — даже если они не менялись между визитами. Без кэша CDN каждый запрос долетает до origin-сервера, который физически может находиться в другом регионе: значит, для пользователя это лишние сотни миллисекунд задержки на каждый клик, а для инфраструктуры — нагрузка на origin, снимать которую как раз и должен CDN. Без кэша на уровне приложения тяжёлый запрос к базе будет выполняться заново при каждом обращении, даже если результат не изменился ни на бит.

Иными словами, выключить кэш — значит вернуть всю нагрузку, которую он снимал, обратно на серверы и заплатить за это временем ответа, трафиком и стоимостью инфраструктуры. Задача — научиться обновлять кэш синхронно с тем, что реально изменилось.

Как правильно обновлять то, что закэшировано

Рабочий подход строится на двух связанных приёмах.

Для файлов, которые меняются вместе с деплоем (CSS, JS, картинки), используют версионирование имени: хэш содержимого зашивается прямо в имя файла (app.a1b2c3.js вместо app.js). Новый файл — новое имя, значит, старая закэшированная копия просто не совпадает с URL, который запрашивает обновлённая страница, и конфликта не возникает. Для таких файлов можно смело ставить долгий max-age и директиву immutable: раз имя гарантированно уникально, ревалидация браузеру не нужна вовсе.

Для остального контента, который должен обновляться без смены URL (тексты, данные API, HTML-страницы), работает сочетание короткого max-age с stale-while-revalidate: пользователь получает мгновенный ответ из кэша, а в фоне кэш обновляется, и уже следующий запрос получит свежую версию. Для больших изменений добавляют явный purge на CDN и точечную инвалидацию нужных ключей в серверном кэше вместо полного сброса всего подряд.

Если изменение рискованное, ситуацию с кэшем это тоже упрощает: canary деплой на часть трафика и feature flag позволяют проверить новую версию до того, как она уйдёт на всех пользователей, — а значит, и до того, как её экземпляры разойдутся по кэшам на разных уровнях.

Что проверить, если «обновил, но не работает»

• Откройте страницу в режиме инкогнито или через Ctrl+Shift+R — если там всё новое, проблема была в браузерном кэше конкретного пользователя: на сервере уже всё актуально.
• Посмотрите заголовки ответа (Cache-Control, Age, ETag) в инструментах разработчика — заголовок Age покажет, сколько секунд назад ответ был сгенерирован и отдаётся ли он вообще из кэша.
• Проверьте, был ли выполнен purge на CDN после деплоя — если у вас настроен автоматический purge в CI/CD-пайплайне, убедитесь по логам, что он реально отработал: одного факта запуска недостаточно.
• Проверьте кэш на уровне приложения — не остался ли в Redis или аналогичном хранилище старый ключ, который никто не инвалидировал.
• И только после этого возвращайтесь к вопросу «а точно ли задеплоилось» — если все слои кэша чистые, а старая версия всё равно на месте, проблема, скорее всего, действительно в деплое.

Для пользователя Firefox изменится привычное расположение и оформление панелей браузера. Проверить ранний вариант можно уже в стабильной версии через скрытую настройку. При этом текущая реализация отличается от будущего релиза, а наиболее близкое представление о новом виде, по совету издания, даёт Nightly, ежедневная сборка разработки.

• Mozilla планирует сделать Nova интерфейсом по умолчанию в Firefox 157; релиз намечен на 29 сентября 2026 года, планы могут измениться.
• Скруглённые вкладки и адресная строка, панель вкладок и навигации в отдельной цветной области, отдельные кнопки приватного режима и встроенного VPN на панели инструментов.
• Компактный режим вернули: он уменьшает отступы для тех, кому новая разметка занимает слишком много места.
• Включить заранее: в about:config выставить browser.nova.enabled в true; в стабильной версии вид будет отличаться от финального, точнее всего показывает Nightly.
• Предыдущие редизайны: Australis в 2014 году, Photon в 2017-м, Proton в 2021-м.

Что именно меняется в интерфейсе

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

OMG! Ubuntu отмечает, что за полгода разработки замысел заметно смягчили. Мартовские макеты показывали сильно скруглённые элементы, «плавающие» панели с зазорами между ними и содержимым страницы и много пастельных градиентов. К сентябрю скругления уменьшили, зазоры убрали, градиент по умолчанию сделали мягче, а компактный режим вернули. На Linux в стандартной теме градиентов в окне браузера нет вовсе.

Компактный режим относится к плотности интерфейса: он уменьшает увеличенные отступы. Сохранение этой настройки важно при сравнении вариантов, потому что свободное пространство между элементами влияет на то, сколько места остаётся странице. В ранних макетах панели визуально отделялись от контента зазорами, но к сентябрю, по описанию OMG! Ubuntu, от этих зазоров отказались. Поэтому мартовские изображения уже не описывают подготовленный к релизу вариант.

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

Как включить Nova уже сегодня и как выключить

Для пробы Nova откройте about:config и найдите browser.nova.enabled. Значение true включает новый интерфейс. Мгновенное переключение без перезапуска не гарантируется. Перед сравнением запишите исходное значение параметра, чтобы при необходимости вернуть его. Результат ранней пробы относится к установленной версии браузера.

В текущих стабильных выпусках Firefox Nova доступна через скрытый флаг. Значение false возвращает прежний вид. После релиза этот способ останется доступным лишь пока флаг существует; срок его сохранения источник не называет. OMG! Ubuntu предупреждает, что текущий вариант в стабильной ветке отличается от будущего Firefox 157, и рекомендует Nightly для более близкого знакомства с результатом разработки.

Если оформление настроено через userChrome.css, перед переходом стоит проверить его вместе с Nova: собственные CSS-правила меняют внешний вид поверх интерфейса браузера. Это рекомендация редакции для раннего тестирования, а не подтверждение поломки конкретной темы. Обратную связь Mozilla собирает в обсуждении на Mozilla Connect. В сообщении о проблеме полезно указать версию браузера и используемое оформление.

Как Nova связана с другими обновлениями Firefox?

До Nova браузер получил Australis в 2014 году, Photon в 2017-м и Proton в 2021-м, напоминает OMG! Ubuntu. Издание рассматривает нынешний редизайн вместе с уже обновлённой страницей настроек, виджетами новой вкладки и иллюстрациями с талисманом Kit. Это изменения разных частей браузера, поэтому скриншот одного окна не показывает весь набор нововведений. Дата включения Nova относится именно к новому оформлению основных панелей.

Отдельного анонса в блоге Mozilla с датой на момент публикации мы не нашли: дата 29 сентября следует из графика выпусков и подтверждена OMG! Ubuntu. Не названо и то, останется ли флаг browser.nova.enabled после релиза и как долго можно будет вернуть старый вид. На сайте мы недавно разбирали, что принёс Firefox 155, а также удаление uBlock Origin из Chrome Web Store, после которого часть пользователей как раз присматривается к Firefox.

Источники: OMG! Ubuntu: Firefox's Nova Redesign Arrives in Firefox 157, OpenNET: В Firefox 157 будет существенно переделан интерфейс пользователя, Mozilla Connect: обсуждение проекта Nova

Изображение на обложке: Mozilla, логотип Firefox

Практический смысл простой: то, что раньше делали через --i в инлайн-стиле каждого элемента или через JavaScript, теперь считает сам браузер. Ступенчатые задержки анимации в списке, ширина колонок по числу карточек, позиционирование по индексу без нумерации в разметке. По данным Web Platform DX, функции получили статус «newly available» с 18 августа 2026 года; статус «widely available» по правилам Baseline ожидается 18 февраля 2029 года, то есть старые браузеры ещё долго будут требовать запасного варианта.

• sibling-index() возвращает позицию элемента среди соседей, начиная с 1; sibling-count() возвращает число прямых детей родителя, включая текущий.
• Поддержка: Chrome и Edge 138 (июнь 2025), Safari 26.2 (декабрь 2025), Firefox 154 (18 августа 2026).
• Функции считают по дереву DOM, а не по flat tree; при попытке пересечь границу Shadow DOM результат может быть 0.
• Типичные применения: transition-delay и animation-delay по номеру, размер элемента в зависимости от числа соседей, раскладка без JavaScript.
• CSSWG допускает будущую форму с фильтром of, чтобы считать только соседей по селектору.

Как это выглядит в коде

Классический пример из обсуждения: список, где каждый следующий пункт появляется чуть позже предыдущего. Раньше для этого либо писали style="--i: 3" в каждом li, либо перечисляли :nth-child() вручную. Теперь достаточно одного правила:

Обе функции возвращают целое число без единиц, поэтому умножение на 80ms или на 100px внутри calc() работает как с обычной переменной. В спецификации CSS Values and Units Level 5 их называют tree-counting functions, функциями подсчёта по дереву.

Где функции ведут себя не так, как ожидается

• Считается дерево DOM, а не flat tree: слоты и элементы внутри Shadow DOM учитываются иначе, чем при рендеринге; на границе теневого дерева функция может вернуть 0, чтобы не раскрывать его содержимое.
• Учитываются все элементы-соседи, а не только подходящие под селектор. Если в списке есть скрытый li, он всё равно попадёт в счёт; форма с фильтром of пока только обсуждается в CSSWG.
• Индексация начинается с 1, как у :nth-child(), а не с 0.

Можно ли использовать в проде

Для декоративных эффектов вроде задержек анимации можно уже сейчас: в браузере без поддержки calc(sibling-index() * 80ms) будет невалидным значением, и правило просто не применится, элементы появятся одновременно. Для раскладки, от которой зависит читаемость, стоит завернуть правило в @supports:

Кому это ничего не даст: проектам, которые обязаны поддерживать браузеры старше Chrome 138 и Safari 26.2, а также тем, кто уже генерирует индексы на сервере. По данным Web Platform DX, Chrome и Chrome Android получили функции в версии 138 от 24 июня 2025 года, Edge 138 от 26 июня 2025 года, Safari и iOS Safari в 26.2 от 12 декабря 2025 года, Firefox и Firefox Android в 154 от 18 августа 2026 года.

Из соседних CSS-новостей на сайте: Firefox 155 добавил функцию progress(), а в Chrome 154 beta появились режимы links и tabs у scroll-marker-group. Черновик спецификации с формальным описанием функций лежит на сайте CSSWG.

Источники: Обсуждение в r/css, Web Platform DX: sibling-count и sibling-index, CSS Values and Units Module Level 5

Я разбираю WebLLM как рабочий инструмент: что нужно от железа и браузера, сколько весят модели, какой скоростью придётся заплатить за отказ от сервера и где проще остаться на облачном API. Все команды и фрагменты кода взяты из README репозитория, цифры производительности из статьи авторов на arXiv, требования к видеопамяти из файла конфигурации в исходниках.

Материал для фронтенд- и фулстек-разработчиков, которым нужен чат, классификатор или JSON-извлекатель на клиенте без счёта за токены и без передачи пользовательских данных третьей стороне.

• WebLLM выполняет модель в браузере на WebGPU, без сервера; API совместим с OpenAI Chat Completions: стриминг, JSON-режим, seed. Вызов функций помечен в README как незавершённый.
• Актуальная версия пакета @mlc-ai/web-llm — 0.2.84 от 27 мая 2026 года; в 2025–2026 годах вышло всего 7 релизов против 63 за 2024 год по данным реестра npm.
• По замерам авторов на MacBook Pro M3 Max WebLLM выдаёт 41,1 токена/с на Llama-3.1-8B и 71,1 токена/с на Phi-3.5-mini, то есть 71–80% от нативного MLC-LLM на том же железе.
• Модели в 4-битной квантизации требуют от 0,7 ГБ видеопамяти (gemma3-1b) до 6,4 ГБ (Qwen3.5-9B) по значениям vram_required_MB в src/config.ts; первый запуск качает всё это с huggingface.co.
• WebGPU по данным MDN есть в Chrome и Edge с версии 113, в Safari 26 с сентября 2025 года, в Firefox с 141 только частично: Linux и Intel-маки не поддерживаются.

Как WebLLM выполняет модель в браузере и при чём тут WebGPU?

Модель считается на видеокарте пользователя через WebGPU, а всё, что не ложится на GPU, крутится в WebAssembly. Авторы описывают схему так: родственный проект MLC LLM компилирует открытую модель заранее в два артефакта, конвертированные веса и WASM-библиотеку с WebGPU-ядрами и вспомогательными функциями. WebLLM в браузере загружает оба артефакта с хостинга, инициализирует WebGPU-устройство и дальше исполняет граф вычислений локально.

Everything runs inside the browser with no server support and is accelerated with WebGPU.

Отсюда же и главное ограничение, о котором в статье авторы говорят прямо: в отличие от CUDA у WebGPU нет готовых ускоренных библиотек для типовых ядер, поэтому матричные умножения и внимание команде пришлось писать и оптимизировать самой. Цена этого видна в замерах: на Apple MacBook Pro M3 Max в Chrome Canary 133 WebLLM версии 0.2.75 выдавал 41,1 токена/с на 4-битной Llama-3.1-8B против 57,7 у нативного MLC-LLM с Metal-ядрами на той же машине, и 71,1 против 89,3 токена/с на Phi-3.5-mini. Это 71,2% и 79,6% нативной скорости соответственно, замер вендора, другого железа в статье нет.

Второй компонент, о котором обычно забывают, это кэш. Веса и WASM-библиотека скачиваются при первом обращении и складываются в хранилище браузера. README перечисляет четыре бэкенда, которые задаются полем cacheBackend в AppConfig: Cache API по умолчанию, IndexedDB, Origin Private File System и экспериментальный cross-origin через расширение Chrome, чтобы одни и те же веса не качались заново для каждого сайта. Без расширения движок сам откатывается на Cache API.

JSON-режим, который в серверных API обычно реализован на стороне провайдера, здесь тоже выполняется локально: по README структурированная генерация встроена в WebAssembly-часть библиотеки модели, а попробовать её со своей JSON-схемой можно в JSON Playground на Hugging Face. Про то, как WASM-рантаймы догоняют нативный код, мы писали в заметке про Wasmi 2.0.

Что нужно, чтобы запустить первый чат?

Достаточно npm-пакета, одного вызова фабрики и терпения на первую загрузку весов. README даёт три варианта установки и импорт через CDN для JSFiddle и CodePen без сборщика.

Движок создаётся функцией CreateMLCEngine: это асинхронная фабрика: она возвращает Promise, а готовый движок с загруженной моделью получают через await. Колбэк прогресса обязателен на практике, потому что без него пользователь смотрит на пустой экран, пока качаются гигабайты.

loading models requires downloading and it can take a significant amount of time for the very first run without caching previously

Дальше интерфейс тот же, что у клиента OpenAI: engine.chat.completions.create({ messages }). Одна ловушка: параметр model в запросе игнорируется, модель выбирается при создании движка или через engine.reload(model). Стриминг включается флагом stream: true, а статистика по токенам приходит только в последнем чанке, если попросить её через stream_options.

Готовый чат для проверки железа не нужно собирать самому: WebLLM Chat сделан на том же пакете, а его код открыт в отдельном репозитории.

Какие модели доступны и сколько видеопамяти им нужно?

В список prebuiltAppConfig.model_list в src/config.ts на 3 сентября входят 165 записей: это варианты квантизации и длины контекста для семейств Llama 3.x, Qwen 2.5, Qwen 3 и Qwen 3.5, Phi 3.5 и Phi 4 mini, Gemma 2 и Gemma 3, Mistral и Ministral 3, дистилляты DeepSeek-R1, SmolLM2, OLMo 2, а также две модели эмбеддингов snowflake-arctic-embed. README при этом всё ещё перечисляет старый набор с Llama 2 и Qwen2, так что актуальный набор виден только в коде.

У каждой записи есть поле vram_required_MB, и это честнее любого «весит N гигабайт»: оно включает не только веса, но и память под KV-кэш при заданном контексте. Для 4-битных вариантов с половинной точностью (суффикс q4f16_1) разброс такой:

• gemma3-1b-it — 0,71 ГБ; Llama-3.2-1B-Instruct — 0,88 ГБ; Qwen2.5-0.5B-Instruct — 0,94 ГБ. Помечены флагом low_resource_required, это кандидаты для встроенной графики и ноутбуков.
• Qwen3-0.6B — 1,40 ГБ; gemma-2-2b-it — 1,90 ГБ; Llama-3.2-3B-Instruct — 2,26 ГБ.
• Qwen3-4B — 3,43 ГБ; Phi-3.5-mini-instruct — 3,67 ГБ; Llama-3.1-8B-Instruct — 5,00 ГБ; Qwen3-8B — 5,70 ГБ; Qwen3.5-9B — 6,43 ГБ.
• Есть и Llama-3.1-70B-Instruct в 3-битной квантизации с требованием 31,15 ГБ; на потребительской видеокарте это не запустится.

Варианты с суффиксом «-1k» урезают контекст до одной тысячи токенов и экономят память: у Llama-3.1-8B это 4,60 ГБ вместо 5,00, у Phi-3.5-mini 2,52 ГБ вместо 3,67. Все эти гигабайты приезжают с huggingface.co/mlc-ai, поэтому доступность и скорость этого хоста в вашей сети стоит проверить до того, как обещать пользователям «работает без сервера». Свою модель в формате MLC подключают через appConfig.model_list, указав URL весов и WASM-библиотеки. Какие небольшие открытые модели вышли в августе и на чём их запускать дома, мы собирали в обзоре открытых нейросетей.

Полный каталог собранных моделей лежит на mlc.ai/models. Номер совместимой сборки библиотек зашит в пакет: для 0.2.84 это константа modelVersion со значением «v0_2_84/base», так что после обновления npm-пакета кэшированные WASM-библиотеки могут потребовать перезагрузки.

Как не заморозить интерфейс: Web Worker или Service Worker?

Для обычного приложения хватает выделенного Web Worker, а Service Worker нужен, когда модель должна переживать переходы между страницами. Оба варианта в README оформлены одинаково: в потоке живёт обработчик, в основном скрипте создаётся движок-прокси с тем же интерфейсом MLCEngineInterface.

С Service Worker сложнее. Его жизненным циклом управляет браузер и может убить поток без предупреждения; движок шлёт heartbeat каждые 10 секунд по умолчанию (значение keepAliveMs в src/service_worker.ts), но авторы просят закладывать обработку ошибок и в приложении. README отдельно требует создавать ServiceWorkerMLCEngineHandler на верхнем уровне скрипта и запрещает делать это внутри обработчиков activate или message: браузер перезапускает уже активный воркер без повторного события activate.

Service Worker's life cycle is managed by the browser and can be killed any time without notifying the webapp. ServiceWorkerMLCEngine will try to keep the service worker thread alive by periodically sending heartbeat events, but your application should also include proper error handling.

Отдельная ветка применения — расширения Chrome: в репозитории есть примеры базового расширения и расширения на Service Worker с WebGPU, которое держит модель в фоне. По данным MDN, в Firefox WebGPU недоступен именно в контексте Service Worker, так что этот сценарий пока привязан к Chromium.

Где WebLLM выигрывает у серверного API, а где проигрывает?

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

• Деньги. Инференс идёт на GPU пользователя, счёт за токены равен нулю. Платите трафиком: каждый новый пользователь качает от 0,7 до 6,4 ГБ весов с Hugging Face; свой CDN нужен только тем, кто перехостит артефакты сам.
• Приватность. Промпты и ответы на сервер не уходят, это следует из архитектуры. Но сетевые запросы есть: веса и WASM скачиваются с huggingface.co и jsdelivr, поэтому формулировка «данные никогда не покидают устройство» некорректна, и в политике приватности так писать нельзя.
• Скорость. 71–80% от нативного инференса по замеру авторов на M3 Max. На ноутбуке с встроенной графикой цифр в статье нет, и обещать «десятки токенов в секунду» без своего замера нельзя.
• Первый запуск. Минуты загрузки против миллисекунд первого ответа у API. Кэш спасает повторные визиты, но не первый.
• Браузеры. По данным MDN, WebGPU есть в Chrome и Edge с версии 113 (полная поддержка на Linux только с 144 и только на Intel Gen12 и новее), в Safari 26 на macOS и iOS с 15 сентября 2025 года, в Firefox с 141 частично: есть Windows и Apple Silicon, нет Linux и Intel-маков. Проверка navigator.gpu обязательна.
• Управление моделью. Серверный API даёт одну версию модели для всех и мгновенную замену. В WebLLM версия модели живёт в кэше каждого браузера, а обновление пакета может потребовать перекачки библиотек.
• Функции. Вызов инструментов через tools и tool_choice в README помечен как WIP с предварительной поддержкой. Для агентских сценариев это стоп-фактор; про выбор стека для агентов у нас есть отдельный разбор.

Есть и организационный риск. По реестру npm пакет обновлялся 19 раз в 2023 году, 63 раза в 2024-м, 3 раза в 2025-м и 4 раза с начала 2026 года; последний релиз 0.2.84 вышел 27 мая. Код в репозитории при этом продолжает меняться, последний push был 3 сентября. Для продакшена это означает, что свежие модели из config.ts могут ждать релиза месяцами.

Evaluations show that WebLLM can retain up to 80% native performance on the same device with room to close the gap further.

Что делать по шагам, чтобы собрать чат на WebLLM за вечер

План ниже покрывает путь от проверки железа до защиты артефактов; команды и имена функций взяты из README для версии 0.2.84.

1. Проверьте, что в браузере есть navigator.gpu, и покажите понятную заглушку тем, у кого его нет. По MDN это Chrome и Edge 113+, Safari 26+, Firefox 141+ с оговорками по ОС.
2. Установите пакет: npm install @mlc-ai/web-llm (версия 0.2.84). Для прототипа без сборки подойдёт импорт с https://esm.run/@mlc-ai/web-llm.
3. Выберите модель из prebuiltAppConfig.model_list по полю vram_required_MB. Для широкой аудитории начните с моделей с флагом low_resource_required: Llama-3.2-1B, Qwen2.5-0.5B, gemma3-1b.
4. Создайте движок через CreateMLCEngine с initProgressCallback и выведите прогресс загрузки на экран.
5. Перенесите инференс в Web Worker через CreateWebWorkerMLCEngine, чтобы интерфейс не замирал во время генерации.
6. Включите стриминг флагом stream: true; для извлечения структурированных данных используйте JSON-режим из раздела Full OpenAI Compatibility.
7. Если артефакты лежат на своём хостинге, добавьте в запись модели поле integrity с SRI-хэшами для конфига, WASM и токенизатора; хэш генерируется командой openssl из README.

При несовпадении хэша движок бросает IntegrityError, либо пишет предупреждение и продолжает работу, если задать onFailure: "warn". Без поля integrity проверка не выполняется вовсе, как и в прежних версиях.

Что дальше: чего нет в WebLLM и за чем следить

Первое, за чем стоит следить, это релиз после 0.2.84: в src/config.ts уже есть Qwen3.5 и Ministral 3, и вопрос в том, когда они попадут в опубликованный пакет. Второе — статус вызова функций, который держится в README как WIP. Третье — cross-origin хранилище: сейчас это расширение Chrome и экспериментальный API, а без него каждый сайт качает свою копию весов.

Мы не проверяли скорость на встроенной графике и на Windows-ноутбуках; единственные опубликованные цифры относятся к MacBook Pro M3 Max. Доступность huggingface.co и esm.run из конкретной сети мы тоже не измеряли: перед запуском продукта на WebLLM стоит замерить время первой загрузки у своей аудитории или перехостить артефакты.

Источники: GitHub: mlc-ai/web-llm (README, лицензия Apache-2.0), src/config.ts: prebuiltAppConfig.model_list с vram_required_MB, src/service_worker.ts: keepAliveMs и heartbeat, arXiv 2412.15803: WebLLM: A High-Performance In-Browser LLM Inference Engine, Блог MLC: WebLLM, 13 июня 2024, Документация WebLLM, Реестр npm: @mlc-ai/web-llm (версии и даты), Hacker News: обсуждение WebLLM 2 сентября 2026, MDN: WebGPU API, совместимость браузеров, Hugging Face: модели mlc-ai, WebLLM JSON Playground, WebLLM Chat, Каталог моделей MLC, GitHub: mlc-ai/mlc-llm

Изображение на обложке: Скриншот: chat.webllm.ai

Бета обычно доживает до стабильного релиза без крупных изменений, поэтому всё перечисленное стоит проверять уже сейчас: часть новинок меняет поведение существующего кода. Background Fetch начинает применять CORS, а AbortController теперь передаёт причину отмены в Response и ReadableStream. Автор поста в блоге Chrome for Developers Рэйчел Эндрю; отдельных региональных ограничений на бету в источнике нет.

• Web Crypto получил ML-KEM 768 и 1024, ML-DSA 44, 65 и 87, ChaCha20-Poly1305 и гибридную схему X-Wing.
• WebSocket принимает options bag: new WebSocket(url, { protocols: "soap" }); новое поле targetAddressSpace позволяет подключаться к локальным адресам при secure context и разрешении Local Network Access.
• scroll-marker-group получил режимы links и tabs; в режиме tabs активный маркер остаётся единственным tab-stop, а неактивный контент скрывается из дерева доступности.
• CSSStyleValue и связанные конструкторы доступны в воркерах; text-decoration-inset принимает auto, длину, процент и одно-/двухзначную запись; FontFace.width стал алиасом stretch.
• Background Fetch теперь соблюдает CORS; WebGPU получил модификаторы frag_depth less и greater, которые позволяют не терять ранний Z-тест.

Что даёт постквантовая криптография в браузерном API

До сих пор постквантовые алгоритмы в Chrome работали только на уровне TLS, незаметно для страницы. В 154 они выходят в JavaScript: через crypto.subtle можно генерировать ключи и выполнять инкапсуляцию ML-KEM (стандарт NIST для обмена ключами) и подписи ML-DSA. Добавлены также ChaCha20-Poly1305 и X-Wing, гибрид классического X25519 и ML-KEM. На практике это нужно тем, кто делает сквозное шифрование в веб-приложениях: мессенджерам, хранилищам паролей, локальным подписям документов. Проверить у себя просто: вызвать crypto.subtle.generateKey с новым именем алгоритма в бете и убедиться, что он не бросает NotSupportedError.

Зачем WebSocket объект настроек и локальная сеть

Конструктор WebSocket много лет принимал только URL и строку или массив протоколов. Теперь второй аргумент может быть объектом: new WebSocket(url, { protocols: "soap" }). Это задел под будущие опции без ломки сигнатуры. Второе поле, targetAddressSpace, решает конкретную боль: страница с публичного HTTPS-сайта не могла открыть сокет к устройству в локальной сети. В 154 это возможно, но при трёх условиях: secure context, разрешение пользователя по механизму Local Network Access и имя хоста, которое резолвится в локальный IP. Сценарий типичный для панелей управления IoT и локальных серверов разработки.

Что меняется в CSS

Свойство scroll-marker-group, которое вместе с псевдоэлементами ::scroll-marker позволяет делать карусели и табы без JavaScript, получило два режима. links ведёт себя как набор ссылок, tabs как настоящий tablist: активный маркер единственный останавливается по Tab, а контент неактивных вкладок исключается из accessibility tree. Это закрывает главную претензию к CSS-каруселям: раньше скринридер видел все панели сразу.

Из остального: text-decoration-inset позволяет отступать подчёркивание от краёв текста и принимает auto, длину, процент и запись из одного или двух значений; FontFace.width и дескриптор font-width в @font-face стали алиасами stretch и font-stretch; типизированная объектная модель CSS (CSSStyleValue и конструкторы) теперь доступна в воркерах, что упрощает расчёты стилей вне главного потока.

Что может сломаться после обновления

• Background Fetch теперь применяет CORS: фоновые загрузки с чужих доменов без правильных заголовков начнут падать.
• AbortController прокидывает reason в Response и ReadableStream: код, который сравнивал ошибку отмены с конкретным AbortError, может получить другой объект.
• По заметкам к релизу, браузер в ряде сценариев использует события click вместо пары pointerdown/pointerup; обработчики, завязанные на порядок этих событий, стоит перепроверить.
• В WebGPU появились модификаторы frag_depth less и greater: шейдеры, которые пишут глубину, могут вернуть себе ранний Z-тест, но это требует правки WGSL.

Как попробовать

Бета ставится параллельно со стабильным Chrome со страницы загрузки Chrome Beta; анонс сборки опубликован в Chrome Releases; на Android доступна через бета-программу в магазине. Стабильный релиз 154 по обычному графику Chrome выходит примерно через четыре недели после беты, точную дату Google в посте не называет. До этого времени полезно прогнать сайт с включёнными фоновыми загрузками и WebSocket-подключениями к локальным устройствам.

Что происходит в других движках, можно сравнить с недавними релизами: WebKit переписал загрузчик модулей для Safari 27, а Firefox 155 добавил CSS-функцию progress(). Полный список изменений Chrome 154 с примерами кода лежит в блоге Chrome for Developers.

Источники: Chrome for Developers: Chrome 154 beta, Chrome Releases: Chrome Beta for Desktop Update

Изображение на обложке: Google, логотип Chrome

Для фронтендера это означает, что один из последних поводов не использовать top-level await в продакшене исчезает: в Chrome и Firefox функция работает давно, а Safari оставался браузером, ради которого библиотеки и сборщики держали обходные пути. По словам автора публикации, инженера WebKit Кая Тамкуна, вместе с загрузчиком в порядок приведены ES-модули в целом, так что после релиза Safari 27 на них «можно опираться, не задумываясь».

• Старый загрузчик модулей Safari был написан по черновику WHATWG Loader, последний раз обновлённому в январе 2016 года, ещё до появления async/await в языке.
• Top-level await, добавленный в ECMAScript 2022, реализовали поверх этой устаревшей основы, отсюда ошибки порядка выполнения и обращения к неинициализированным экспортам.
• В январе 2026 года команда удалила старый загрузчик целиком и переписала его на C++ по алгоритмам спецификации ECMAScript, отказавшись от самохостируемого JavaScript.
• Проверка: тест-кейсы от команды Bun, чей рантайм на JavaScriptCore унаследовал те же баги, фаззер графов модулей со сравнением вывода с другими движками, все модульные тесты test262 и исправленные тесты WPT без регрессий.
• Попробовать можно сегодня в Safari Technology Preview 251 или Safari 27 beta; сроки стабильного Safari 27 в публикации не названы.

Что именно ломалось

Top-level await позволяет писать await прямо в теле ES-модуля: модуль приостанавливается до разрешения промиса, и вместе с ним ждут все модули, которые его импортируют, а независимые ветки графа зависимостей продолжают выполняться. В Safari нарушался именно порядок: загрузчик неверно выбирал, когда считать модуль выполненным. WebKit показывает это на минимальном примере, где один и тот же модуль с задержкой на верхнем уровне динамически импортируется три раза подряд.

Ожидаемый порядок завершения импортов 1, 2, 3. Старый загрузчик выдавал 2, 3, 1, причём второй и третий импорт завершались с ошибкой Cannot access 'someArray' before initialization, и только первый печатал список экспортов. Причина одна: когда первый импорт доходил до await и уступал управление, промис второго импорта должен был ждать окончания выполнения модуля, но из-за ошибки разрешался сразу. Код получал ещё не инициализированные экспорты и падал. С новым загрузчиком вывод становится ожидаемым: 1, 2, 3, и каждый раз с корректным списком ключей.

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

Спецификация ECMAScript оставляет часть механики модулей на усмотрение хоста, в первую очередь загрузку по сети в браузере или с диска в Node.js и Bun. Загрузчик Safari писали в эпоху предложения WHATWG Loader, которое описывало эту хостовую часть и последний раз обновлялось в январе 2016 года. Тогда модули выполнялись строго синхронно, и черновика хватало. Затем предложение фактически умерло, вытесненное разделом о модулях в самом стандарте ECMAScript, а в 2022 году в язык вошёл top-level await. В WebKit его реализовали поверх алгоритмов заброшенного черновика, а не по асинхронным алгоритмам стандарта. Отсюда тонкие ошибки, которые, по словам Тамкуна, команда безуспешно пыталась закрыть несколько раз, пока не решила заменить основание.

Второе решение касается языка реализации. Старый загрузчик был самохостируемым встроенным кодом на JavaScript. У такого подхода есть плюсы: его можно инлайнить в пользовательский код и не платить за переход между JavaScript и C++. Но он медленнее стартует, потому что компилируется во время выполнения, а оптимизирующие JIT-компиляторы JavaScriptCore плохо используют его широкие паттерны применения; загрузчик к тому же не горячий путь, так что выигрыша от компиляции на лету почти нет. Новый загрузчик написан целиком на C++.

Как переписывали и проверяли

Работа началась в январе 2026 года с удаления файла со старым загрузчиком. Дальше команда переводила псевдокод операций из спецификации ECMAScript в C++ по одной, начав с листовых функций вроде ExecuteModule и ModuleRequestsEqual, у которых нет зависимостей, и двигаясь по графу вызовов. Через несколько недель черновая реализация справлялась с типичными случаями, и появился draft pull request.

Тестов было три слоя. Во-первых, инженеры Bun, чей рантайм построен на JavaScriptCore и унаследовал те же проблемы, передали собранные ими случаи неправильного поведения; их адаптировали под консольную оболочку jsc. Во-вторых, команда написала фаззер, который генерирует большие графы модулей, часть с top-level await, часть без, и сравнивает текстовый вывод JavaScriptCore с выводом других движков байт в байт; по словам WebKit, во всех проверенных примерах новый загрузчик отработал верно. В-третьих, все модульные тесты набора test262 стали проходить, а часть ранее падавших тестов WPT исправилась без регрессий. Перед слиянием разработчики несколько недель пользовались сборкой Safari с новым загрузчиком как основным браузером.

Что делать фронтендеру

• Проверить свои модули с top-level await в Safari Technology Preview 251 или Safari 27 beta; о найденных проблемах WebKit просит сообщать на bugs.webkit.org.
• Обходные пути для Safari пока не убирать: стабильный Safari 27 ещё не вышел, а старые версии Safari останутся у пользователей надолго.
• Если проект работает на Bun, следить за обновлениями рантайма: он использует JavaScriptCore и, по словам WebKit, унаследовал те же ошибки загрузчика; о сроках их исправления в Bun публикация не говорит.

Дата выхода стабильного Safari 27 в публикации не названа. Открытым остаётся и вопрос старых версий: о переносе исправления в уже вышедшие Safari WebKit не сообщает, так что доля пользователей на Safari 26 и старше будет определять, когда обходные пути можно убрать совсем.

Источник: WebKit Blog: Fixing Top-Level Await in Safari

Изображение на обложке: Изображение: логотип WebKit, Apple

В тот же день вышел Firefox 155 для десктопа, и для верстальщиков в нём есть чем заняться: CSS-функции progress() и alpha(), свойство font-width, attr() в любом свойстве, а в JavaScript Promise.allKeyed(). Обновиться стоит и без новинок: бюллетень безопасности MFSA 2026-82 закрывает несколько уязвимостей высокого уровня.

• Блокировщик в Firefox для iOS включается в Settings, затем Browsing, затем Ad Blocker; по умолчанию выключен, расширение ставить не нужно.
• Работает на технологии Apple WebKit Content Blocker и списке EasyList; рекламу в поисковой выдаче и рекламу самих сайтов может пропускать.
• Firefox 155: CSS progress(), alpha(), font-width, attr() везде; Promise.allKeyed() и allSettledKeyed(); согласование QUIC v2 для HTTP/3; NDJSON в JSON Viewer.
• MFSA 2026-82 закрывает уязвимости высокого уровня, среди них CVE-2026-84119, 84143 и 84144, и повышение привилегий в Firefox для Android.
• Минимальную версию iOS для блокировщика Mozilla не назвала; доступность функции по регионам анонс не описывает.

Почему блокировщик пришлось встраивать

Apple разрешает сторонним браузерам блокировать контент только через свой механизм Content Blocker: приложение отдаёт WebKit готовый список правил, а сам движок решает, какие запросы не выполнять. Расширение не может «посмотреть» на страницу и вмешаться в её код, как это делает uBlock Origin на десктопе. Mozilla взяла список EasyList, самый распространённый набор правил для рекламы, и упаковала его в такой блок правил внутри приложения.

Ad Blocker uses Apple's WebKit Content Blocker technology and the EasyList filter list.

Из этой архитектуры следуют ограничения, которые Mozilla перечисляет сама. Реклама, которую сайт отдаёт с собственного домена, может остаться, потому что её не отличить от контента по URL. Реклама в результатах поиска не блокируется. Рекламные ярлыки на стартовой странице самого Firefox к блокировщику не относятся. Включается всё в три касания: Settings, Browsing, Ad Blocker; там же выключается, если сайт перестал работать.

Что Firefox 155 даёт верстальщику

По заметкам для разработчиков на MDN, самое полезное в CSS — функция progress(): она возвращает долю от 0 до 1, показывающую, где значение находится между двумя границами. Раньше такой расчёт делали руками через calc(), теперь адаптивные размеры шрифта и отступов записываются короче. Функция alpha() меняет прозрачность цвета без переписывания его в rgb(), а attr() отныне работает в любом свойстве, а не только в content.

В JavaScript добавились Promise.allKeyed() и Promise.allSettledKeyed(): они принимают объект с промисами и возвращают объект с теми же ключами, так что не нужно сопоставлять результаты по индексам массива. Свойство font-width заменило font-stretch, старое имя оставлено как псевдоним. Если импорт модуля упал из-за временной ошибки сервера, повторный импорт теперь может выполниться успешно; это касается JS, JSON, CSS и текстовых модулей. В сетевом стеке появилось согласование QUIC version 2 для HTTP/3, а JSON Viewer в DevTools научился читать NDJSON построчно.

Для автотестов: в WebDriver BiDi исправлены перезагрузка фреймов, подписки и конфликт с DevTools, в WebRTC добавлена поддержка двухбайтовых RTP-заголовков с идентификаторами от 15 и новые поля статистики. Перед использованием progress() и alpha() в проде стоит сверить поддержку в Chrome и Safari на caniuse: MDN описывает только Firefox.

Почему обновиться сегодня

Бюллетень MFSA 2026-82 сопровождает релиз набором исправлений. CVE-2026-84119 (выход из песочницы через use-after-free в навигации DOM), CVE-2026-84143 и CVE-2026-84144 помечены как уязвимости высокого уровня, CVE-2026-84142 объединяет внутренне найденные ошибки памяти умеренного уровня. Отдельно для Firefox на Android бюллетень называет повышение привилегий (CVE-2026-84117, высокий уровень) и раскрытие информации через WebExtensions (CVE-2026-84127, умеренный уровень). Обновление на 155 закрывает всё это разом; на десктопе и Android оно важнее новых функций.

Что дальше

Mozilla объясняет встроенный блокировщик ограничениями расширений на iOS и формулирует их как «недоступны таким же образом», а не «невозможны навсегда»: в ЕС и Японии Apple уже допускает альтернативные движки, и если Firefox на iOS когда-нибудь перейдёт на Gecko, вопрос с расширениями встанет заново. Пока же блокировщик работает ровно в тех пределах, которые задаёт Content Blocker API.

Источники: Introducing Ad Blocker for Firefox on iOS (Mozilla), Firefox 155 for developers (MDN), Mozilla Foundation Security Advisory 2026-82

Изображение на обложке: Mozilla

Для пользователя Chrome это означает, что установить полный uBlock Origin из магазина больше нельзя, а там, где он ещё стоит, он уже не работает без корпоративной политики. Для разработчиков расширений закончился последний переходный режим: с этого дня у клиентов не может быть рабочей V2-сборки, которую можно было бы чинить и обновлять.

• 31 августа 2026 года Google удалил из Chrome Web Store все расширения Manifest V2; uBlock Origin в их числе.
• Chrome 138 был последней версией, где корпоративная политика ExtensionManifestV2Availability могла включить V2; в Chrome 139 политика удалена.
• Установленные V2-расширения на старых версиях Chrome остаются в списке, но отключены для обычных пользователей ещё с марта 2025 года и не обновляются.
• Полный uBlock Origin доступен в Firefox Add-ons и Microsoft Edge Add-ons; для Chrome автор предлагает uBlock Origin Lite на Manifest V3.
• Разработчикам: путь V2 в Chrome Web Store закрыт полностью; Edge завершает переход позже по своему графику.

Чем Manifest V3 отличается от V2 и почему это важно для блокировщиков

Manifest — это набор правил, по которым браузер разрешает расширениям вмешиваться в работу страниц. В V2 расширение могло само перехватывать каждый сетевой запрос через webRequest, анализировать его и блокировать по своей логике. В V3 этот механизм заменён на declarativeNetRequest: расширение заранее передаёт браузеру список правил фильтрации, а решения принимает сам Chrome. Google объясняет переход безопасностью и производительностью: расширение больше не видит содержимое запросов и не может выполнять удалённо загруженный код.

Для блокировщиков разница принципиальная. Число правил ограничено, динамические правила по содержимому страницы невозможны, а списки фильтров нельзя обновлять чаще, чем выходит новая версия расширения. Автор uBlock Origin Рэймонд Хилл с начала перехода писал, что полноценная версия в этой модели невозможна, и выпустил отдельное расширение uBlock Origin Lite, которое живёт в рамках V3. По его README, у Lite нет динамической фильтрации, а часть косметических правил работает только в более агрессивных режимах.

Хронология: четыре с половиной года на переезд

• Январь 2022 года: Chrome Web Store перестал принимать новые публичные и unlisted-расширения на V2.
• Июнь 2022 года: магазин перестал принимать новые приватные V2-расширения.
• 31 марта 2025 года: V2 начали отключать по умолчанию у обычных пользователей; корпоративные клиенты могли включить его ключом политики ExtensionManifestV2Availability.
• Chrome 138: последняя версия, в которой этот ключ работал; в Chrome 139 политика удалена.
• 31 августа 2026 года: все оставшиеся V2-расширения удалены из Chrome Web Store.

All remaining Manifest V2 extensions are removed from the Chrome Web Store.

Что происходит с уже установленным uBlock Origin

Если расширение стоит на Chrome 138 и старше, оно остаётся в списке установленных, но для обычных пользователей уже отключено: с марта 2025 года включить его могла только корпоративная политика. Обновлений оно не получает, в том числе списков фильтров, которые у полной версии обновляются через код расширения. После удаления из магазина переустановить его оттуда нельзя. На Chrome 139 и новее полный uBlock Origin не запускается независимо от того, откуда он был установлен.

Практический выбор для пользователя Chrome сводится к трём вариантам. Первый: uBlock Origin Lite, который использует встроенный API фильтрации и справляется с большинством рекламы, но уступает полной версии. Второй: Firefox, где, по словам самого автора в README, uBlock Origin «работает лучше всего». Третий: Microsoft Edge, в чьём магазине расширение по-прежнему есть; Edge, по графику в README, завершает переход на V3 позже Chrome; для Opera README указывает лишь доступность uBlock Origin. Про Brave отдельной оговорки в README нет.

Что это значит для разработчиков расширений

Новости для тех, кто пишет под Chrome, нет уже год: в Chrome Web Store V2 нельзя было опубликовать с 2022 года. Изменилось другое: закончился режим «у клиентов ещё стоит старая версия, и её можно чинить». Если у продукта остались V2-сборки в корпоративных установках, они больше не получат ни одного обновления, и переезд на V3 из «когда-нибудь» стал срочным.

• Сетевую фильтрацию переносите на declarativeNetRequest: статические правила в JSON внутри пакета, динамические через API, с лимитом на число правил, который стоит проверить по документации Chrome до проектирования.
• Фоновые страницы заменяйте на service worker; он засыпает, поэтому состояние держите в chrome.storage, а не в переменных.
• Удалённо загружаемый код в V3 запрещён: вся логика должна быть внутри пакета расширения; списки фильтров обновляются только с новой версией.
• Перед публикацией проверьте тот же пакет в Edge и Firefox: у них свои магазины и свои отличия в поддержке V3.

Что дальше

Google завершила переход, который анонсировала ещё в 2019 году. Следующий фронт — сам API declarativeNetRequest: авторы блокировщиков будут добиваться повышения лимитов на правила и новых возможностей, а Google будет решать, насколько далеко готова пойти. Пока этого не произошло, Chrome остаётся браузером, где реклама блокируется хуже, чем в Firefox, и это уже не временная ситуация, а свойство платформы.

Источники: Manifest V2 support timeline (Chrome for Developers), Репозиторий uBlock Origin, Карточка uBlock Origin в Chrome Web Store, Обсуждение на Hacker News

Изображение на обложке: скриншот Chrome Web Store

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

Проект поддерживается преимущественно разработчиками из России, Казахстана, Украины и Германии. Код распространяется под открытой лицензией, а сборки регулярно публикуются на официальном сайте и зеркалах сообщества.

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

Это меняет статус системы с «основной ОС на каждый день» на «платформу для специальных задач». Почта, мессенджеры, облачные сервисы и онлайн-документация остаются недоступны без промежуточного прокси или другой машины.

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

• Chrome 150 (конец июня) и Chrome 151 (июль 2026) удалят остатки поддержки Manifest V2.
• Перестанут работать старые блокировщики вроде uBlock Origin, если их запускали через обходные пути.
• Компания ссылается на технический долг, сложность поддержки и риски для безопасности, включая баги, специфичные для MV2.
• Альтернатива — расширения на Manifest V3, например uBlock Origin Lite, или переход на другой браузер.

По данным 9to5Google, в версиях Chrome 150 (конец июня) и Chrome 151 (июль) Google уберёт последние упоминания платформы Manifest V2 из кода браузера.

Manifest V2 — это формат расширений Chrome, на котором работали привычные инструменты вроде uBlock Origin. В 2024 году Google начал отказываться от него в пользу Manifest V3: новая платформа ограничивает возможности фильтрации трафика, чтобы повысить производительность и безопасность. О том, чем отличаются платформы, мы рассказывали ранее.

Расширения MV2 больше не разрешены в любой поддерживаемой версии Chrome, и мы удаляем поддержку для них и связанный функционал. Мы не можем поддерживать это бесконечно из-за сложности, технического долга и рисков для безопасности — к тому же недавно мы нашли ряд багов, специфичных для MV2.

Что изменится для пользователей

• После Chrome 151 старые расширения на Manifest V2 не смогут запускаться ни через официальный магазин, ни через обходные механизмы.
• Блокировщики вроде uBlock Origin придётся заменить на версии для Manifest V3 — например, uBlock Origin Lite.
• Если привычный набор фильтров важен, можно рассмотреть Firefox или другие браузеры, которые пока сохраняют поддержку MV2.

Какие блокировщики останутся

В экосистеме Chrome останутся решения, созданные под Manifest V3: uBlock Origin Lite, AdGuard и другие. Они работают с жёсткими ограничениями на количество правил фильтрации — например, базовый лимит статических правил в declarativeNetRequest заметно ниже, чем было доступно старым инструментам. Из-за этого на некоторых сайтах может прорываться реклама или реже обновляться фильтры.

FAQ

Выводы

Google завершает многолетний переход с Manifest V2 на Manifest V3. Чтобы не остаться без привычной фильтрации рекламы, проверьте расширения уже сейчас: откройте chrome://extensions/, найдите uBlock Origin и посмотрите на предупреждение о совместимости. Если важен привычный уровень блокировки — установите uBlock Origin Lite или подготовьтесь к переходу на Firefox. Chrome 150 выйдет через две недели.

Источники: The Verge, 9to5Google.

Мы рады анонсировать выпуск MDN MCP server. MCP (Model Context Protocol) — открытый стандарт, который позволяет ИИ-инструментам подключаться к внешним источникам данных. MDN MCP server использует этот протокол, чтобы перенести документацию MDN и данные о совместимости браузеров прямо в вашего ИИ-агента или IDE.

• MDN MCP server — экспериментальный сервер по протоколу MCP.
• Даёт ИИ-агентам и IDE доступ к актуальной документации MDN и данным о совместимости браузеров.
• Работает с VS Code, Zed, Cursor, Claude Code, Codex CLI, Antigravity CLI и Claude Desktop.
• В тестах с Claude Code Opus 4.7 MDN MCP дал гораздо точнее и надёжнее результаты о поддержке браузеров.
• Ответы с MDN MCP были вдвое быстрее, чем без него.

Зачем мы создали MDN MCP

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

Например, LLM или агент для написания кода может не знать, что существует функция вроде @view-transition CSS at-rule, или не знать, достигла ли она статуса Widely Available в Baseline и безопасна ли для использования во всех браузерах.

MDN MCP даёт вашему агенту для написания кода доступ к точной и актуальной информации о веб-платформе. Также он упрощает доступ к последней документации, не покидая привычные инструменты.

Сервер сейчас находится в экспериментальном статусе. Подробности об обработке данных в этой фазе — в нашей заметке о приватности.

Как использовать MDN MCP

MDN MCP server работает с любым MCP-совместимым клиентом, включая:

• Редакторы: VS Code, Zed и Cursor.
• CLI-агенты: Claude Code, Codex CLI и Antigravity CLI (ранее Gemini CLI).
• Чат-приложения: Claude Desktop.

Ссылки в этом списке ведут к инструкциям по настройке MCP для каждого инструмента. Инструкции по установке и другие детали — на нашей странице MDN MCP server.

Как быстрый пример, чтобы использовать его с Claude Code, нужно выполнить следующую команду:

Мы с нетерпением ждём, как вы интегрируете его в свой рабочий процесс веб-разработки и в каких сценариях он окажется наиболее полезен.

Какую разницу даёт MCP

Учитывая недетерминированную природу LLM и разнообразие доступных моделей, часто сложно сравнивать их поведение с включёнными или выключенными навыками, промптами, инструментами и MCP.

Мы протестировали Claude Code Opus 4.7 с MDN MCP и без него на нескольких функциях, недавно появившихся в Firefox 150 и 151, спрашивая, как использовать функции и какая у них поддержка браузеров. А именно:

1. Как использовать CSS-функцию light-dark() для изображений и какие браузеры её поддерживают?
2. Как использовать CSS-псевдокласс :buffering и какие браузеры его поддерживают?
3. Как использовать атрибут shadowrootslotassignment на элементе и какие браузеры его поддерживают?
4. Как использовать Web Serial API и какие браузеры его поддерживают?

Мы заметили определённые закономерности в результатах. В большинстве случаев заметки по использованию от Claude Code с MDN MCP и без него были сопоставимы. Часть ответов, использовавших MCP, была структурирована лучше и полнее. Например, заметки для CSS-функции light-dark() также включали примеры с линейными градиентами, которые не были прямо упомянуты в вопросе, но тоже поддерживаются.

Когда дело дошло до информации о поддержке браузеров, победитель был очевиден: MDN MCP дал намного точнее и надёжнее результаты. Claude Code без MCP правильно определил поддержку браузеров только в одном случае — для псевдокласса :buffering.

Например, Claude Code без MCP настаивал, что декларативный атрибут shadowrootslotassignment поддерживается в Chrome 120 и Safari 18.3, возможно, путая его с опцией slotAssignment метода Element.attachShadow(). Но на самом деле Firefox 151 — первый браузер, в котором появилась поддержка этого атрибута.

Без MCP Claude Code также не дал никакой конкретной информации о поддержке браузеров для использования изображений в функции light-dark(): «поддержка менее однородна, чем вариант с цветом», тогда как с MCP он выдал полную таблицу с указанием Firefox 150 и Chrome (за флагом) как поддерживающих браузеров.

Худший результат Claude Code без MCP показал на вопросе про Web Serial API. Firefox 151 получил поддержку Web Serial API в мае 2026 года. Однако Claude Code без MCP правильно упомянул браузеры на базе Chromium как поддерживающие эту функцию, но также настаивал, что в Firefox она:

Не реализовано (и не в планах — см. позицию Mozilla по стандартам: «вредно»).

С включённым MCP Claude Code правильно определил, что Firefox 151 поставляет поддержку Web Serial API, согласно примечаниям к выпуску.

Кроме того, мы заметили, что в наших тестах ответы с использованием MDN MCP были вдвое быстрее. Без MCP Claude Code приходилось загружать и парсить немало HTML-страниц, чтобы найти актуальную информацию, что занимало время, но даже тогда не давало точных результатов.

Поучаствовать

Ваш отзыв помогает нам становиться лучше. Если вы столкнулись с проблемами, есть комментарии или предложения или хотите поделиться, как используете MDN MCP, мы будем рады услышать вас. Заходите в канал platform в нашем Discord. Если заметили проблемы, сообщайте о них в репозиторий mdn/mcp на GitHub.

Что дальше

По мере того как ИИ-инструменты становятся всё большей частью рабочих процессов веб-разработки, мы стремимся сделать документацию MDN доступной там, где она вам нужна. Этот релиз — один шаг к этой цели, и мы с нетерпением ждём возможности продолжить улучшать опыт с вашей помощью.

Источник: Introducing the MDN MCP server — MDN Blog.

Попробуйте подключить MDN MCP к своему редактору или агенту и проверьте, насколько точнее станут ответы о веб-платформе.

Техника описана в исследовательской статье, которую представят на конференции DIMVA в июле 2026 года. Атака работает исключительно внутри браузера и не требует никаких действий от пользователя.

Как работает FROST

FROST (Fingerprinting Remotely using OPFS-based SSD Timing) использует побочный канал утечки на основе конкуренции процессов за доступ к общему ресурсу. В данном случае ресурс — SSD-накопитель пользователя.

Вредоносный сайт создаёт большой файл (от 1 ГБ) в Origin Private File System (OPFS) — изолированном хранилище, доступном через JavaScript без запроса разрешений. Затем код выполняет случайные чтения из этого файла и измеряет задержки. Если в это время другая вкладка или приложение обращается к SSD, задержки меняются. Эти изменения анализирует предобученная свёрточная нейросеть (CNN), которая по сигнатуре нагрузки определяет, что именно работает в системе.

Исследователи продемонстрировали полноценную атаку на Mac с процессором M2. На Linux подтвердили работу базового примитива — измерение задержек через JavaScript. Windows в тестах не участвовала, но авторы не исключают, что техника применима и там.

OPFS поддерживается во всех современных браузерах на базе Chromium, а также в Firefox и Safari. Это означает, что потенциально техника применима к большинству пользователей десктопного веба.

FROST позволяет сайтам отслеживать открытые вкладки и приложения через анализ SSD-активности.

Атака работает внутри браузера через JavaScript и OPFS, без взаимодействия с пользователем.

Ключевой инструмент — свёрточная нейросеть, классифицирующая задержки чтения SSD.

Полная атака продемонстрирована на macOS (M2); на Linux работает базовый примитив.

Пока не зафиксировано случаев применения FROST в реальных условиях.

Ограничения и защита

У техники есть важные ограничения. Для атаки файл в OPFS должен занимать не менее 1 ГБ. Это означает, что массовое применение будет заметно: создание гигабайтного хранилища в браузере занимает время и место на диске. Кроме того, OPFS должен находиться на том же SSD, что и отслеживаемые приложения.

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

Итоги

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

Источник: Ars Technica. Читайте также о новой защите Firefox от цифрового отпечатка.

О поведении сообщил норвежский исследователь Tom Jøran Sønstebyseter Rønning (в X — @L1v1ng0ffTh3L4N). Публичное раскрытие — 4 мая 2026 года. Цитата исследователя: «Edge — единственный Chromium-браузер из проверенных мной, который ведёт себя именно так». Уведомление отправлял в Microsoft заранее, ответ — «не уязвимость».

Edge при запуске загружает в память все сохранённые пароли и держит их в открытом виде всю сессию. Не имеет значения, открывал ли ты сайт, к которому относится конкретный пароль. У других браузеров на Chromium такого нет: Chrome расшифровывает пароль только в момент автозаполнения и тут же его выгружает.

• Microsoft Edge при старте грузит в память все сохранённые пароли в открытом виде и держит их так до закрытия браузера.
• Воспроизведение — три шага без прав администратора в рамках своего пользователя: запустить Edge, сделать дамп памяти процесса, прогнать strings.
• Edge — единственный Chromium-браузер с таким поведением: Chrome расшифровывает пароль только в момент использования и применяет Application-Bound Encryption.
• Microsoft признаёт поведение и квалифицирует его как «by design» — не уязвимость, а баланс между производительностью и безопасностью.
• Реальный риск — на терминальных и общих машинах: администратор сервера через дамп памяти получает пароли всех вошедших пользователей.

Как воспроизвести за три минуты

Воспроизводимо на любой Windows-машине без прав администратора в рамках текущего пользователя — для своих паролей в своей сессии. Понадобится утилита strings из Sysinternals или из пакета binutils в Linux/WSL.

1. Открыть Microsoft Edge и больше ничего не делать — никуда не заходить, ничего не открывать.
2. Открыть Task Manager (Диспетчер задач), найти процесс Edge, развернуть подпроцессы. На browser-подпроцессе — правый клик → «Create memory dump file».
3. Открыть полученный файл с расширением .DMP в любом окружении со strings.

Дальше нужно отфильтровать дамп по характерному формату записи (URL + протокол + логин + пароль идут подряд). Команда из разбора Rob VandenBrink в SANS ISC:

В большинстве случаев домен сайта оканчивается на .com, а сразу за ним без разделителя идёт схема https — поэтому фильтр по подстроке comhttps ловит почти все записи. В выводе видны логины и пароли — отдельным аккуратным блоком, по одной строке на сайт.

Почему у Chrome так не работает

Google Chrome расшифровывает пароль только в момент, когда он действительно нужен — на автозаполнении или когда пользователь сам открывает «показать пароль». В остальное время в памяти лежит зашифрованная версия.

Сверх того в Chrome есть Application-Bound Encryption (ABE) — это механизм, привязывающий ключи шифрования паролей к Chrome через отдельный сервис с правами SYSTEM. Чтобы дотянуться до ключей, инфостилеру (вредоносу, который ворует учётные данные) нужно повышать привилегии до SYSTEM, а пользовательских прав — недостаточно. У Edge этой защиты не наблюдается: пароли в памяти браузерного процесса лежат в открытом виде.

Что говорит Microsoft

Microsoft получила отчёт об исследовании заранее и квалифицировала поведение как «не уязвимость». 6 мая 2026 года представитель компании дал официальный комментарий CyberNews:

Безопасность и приватность — фундамент Microsoft Edge. Сценарий, описанный в отчёте, требует, чтобы устройство уже было скомпрометировано. Дизайн в этой области — компромисс между производительностью, удобством и безопасностью; мы продолжаем оценивать его в свете новых угроз. Браузеры обращаются к данным паролей в памяти, чтобы пользователь мог быстро и удобно входить — это ожидаемая функция приложения. Рекомендуем установить последние обновления безопасности и антивирус.

На Hacker News тема собрала живое обсуждение. Один из тезисов: «если атакующий уже может читать произвольную память, он, вероятно, в состоянии и аутентифицироваться от имени пользователя». Уточнение в комментариях: терминальные серверы и общие рабочие станции — типичный сценарий, когда у администратора сервера легитимно есть доступ к памяти всех залогиненных пользователей, и поведение Edge превращает этот доступ в доступ ко всем их учётным записям разом.

Что делать сейчас

• На терминальных серверах и общих рабочих машинах отключить сохранение паролей в Edge или перейти на Chrome или Firefox.
• Перенести пароли в специализированный менеджер: 1Password, Bitwarden, KeePass — они шифруют записи в памяти и достают их по одной за раз, а не разом всю базу.
• Для самых критичных аккаунтов — мигрировать с пароля на passkey (вход без пароля по биометрии или PIN, стандарт FIDO2). Приватный ключ обычно лежит в TPM, Secure Enclave или защищённом keychain и не попадает в память приложения в виде, пригодном для копирования.
• Везде, где пароль остался — обязательно включить второй фактор: TOTP (Google Authenticator, Authy) или аппаратный ключ (YubiKey, Titan).
• Проверять, что Windows-учётка обычного пользователя не имеет прав администратора: тогда вредоносная программа в его контексте не сможет добраться до памяти других сессий.

Про автора исследования

Tom Jøran Sønstebyseter Rønning — норвежский исследователь по безопасности. Никнейм @L1v1ng0ffTh3L4N («living off the LAN») отсылает к living-off-the-land технике — использовать штатные средства окружения вместо принесённых вредоносных инструментов. PoC по Edge — продолжение той же темы: атакующему ничего не нужно, кроме штатного Task Manager и стандартной утилиты strings.

Выводы

Edge показывает биометрический запрос при попытке открыть пароль в UI, но в памяти процесса параллельно лежит копия в открытом виде. Это ровно тот самый «security theatre» — показная безопасность, на которую часто жалуются исследователи: визуально серьёзный замок на двери при открытом окне сбоку. Microsoft пока не планирует менять поведение.

Для пользователя вывод простой: не доверять менеджеру паролей браузера. Это удобный сервис автозаполнения, но не безопасное хранилище. Серьёзный пароль и тем более ключ от рабочих сервисов — место не там.

Технический разбор и proof-of-concept — у Tom Jøran Sønstebyseter Rønning в треде на X. Независимая верификация и пошаговая инструкция — у Rob VandenBrink, SANS ISC, выпуск 32954. Развёрнутый разбор и комментарий Microsoft — на CyberNews.

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

Denwer SE решает все эти проблемы, оставаясь при этом таким же портативным — достаточно скопировать папку на флешку или в облачный каталог.

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

Самое болезненное место при локальной разработке это самоподписанные сертификаты. Браузеры постоянно ругаются, приходится кликать «Принять риск». Для командной разработки это вообще катастрофа: каждый участник должен сгенерировать свой сертификат и добавить в исключения.

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

Поддержка macOS через Secure Enclave появится в одном из следующих релизов — конкретных сроков Google не назвала. Linux в анонсе вообще не упоминается.

• Chrome 146 для Windows автоматически использует DBSC на сайтах, которые его поддерживают
• Даже заражённая малварью машина не отдаст ключ: приватный ключ сессии живёт в TPM и не может быть оттуда прочитан — даже самим Chrome
• Украденный cookie быстро становится бесполезным: сервер требует подпись challenge приватным ключом с оригинального устройства при каждом обновлении
• Внедрение для бэкенда — два новых эндпоинта (регистрация + refresh), фронтенд трогать не нужно
• DBSC — открытая спецификация в рамках W3C, разработанная Google совместно с Microsoft; Firefox и Safari пока молчат
• Это вторая попытка Google защитить cookies после App-Bound Encryption 2024 года, которую малварь обошла за пару месяцев

Что такое DBSC и зачем оно нужно

Сессионный cookie — это токен авторизации, который сервер выдаёт после успешного логина и принимает вместо пары логин-пароль. Из-за того что одного cookie достаточно для входа в аккаунт в обход 2FA, инфостилеры (LummaC2, MeduzaStealer, Vidar, StealC и десятки других) превратили кражу сессионных cookies в основной способ монетизации взломанных машин. Google в анонсе признаёт прямо: «как только продвинутая малварь получила доступ к машине, она может читать локальные файлы и память, где браузер хранит cookies. Нет надёжного способа предотвратить exfiltration программными средствами».

DBSC меняет архитектуру защиты: если украсть cookie всё равно можно, сделаем так, чтобы украденный cookie был бесполезен. Вместо одного долгоживущего cookie браузер получает серию короткоживущих, и каждый новый выдаётся сервером только после того, как Chrome докажет владение приватным ключом, лежащим в TPM. Длительность задаёт сам сервер, Google конкретных цифр не публикует.

Как это работает технически

1. При создании сессии Chrome просит TPM сгенерировать пару ключей — приватный остаётся внутри чипа, публичный уходит на сервер и привязывается к сессии
2. Сервер выдаёт короткоживущий session cookie и запоминает публичный ключ
3. Cookie быстро истекает; Chrome запрашивает новый и получает challenge от сервера
4. Chrome подписывает challenge приватным ключом через TPM — ключ при этом не покидает чип
5. Сервер проверяет подпись публичным ключом и выдаёт следующий cookie

Если инфостилер украл файл с cookies и залил его на свою машину — на следующем refresh сервер потребует подписать challenge, а без TPM с оригинального устройства ключа для подписи нет. Cookie устаревает, использовать его нельзя. За год тестирования в партнёрстве с Okta и ещё несколькими платформами Google заявила о снижении краж сессий, но конкретных цифр не привела.

Отдельный момент — приватность. Для каждой сессии генерируется уникальный ключ, так что сайт не может использовать DBSC как трекер между сессиями или между сайтами. Обмен ограничен одним публичным ключом, никаких device ID не утекает — этот момент Google подчёркивала ещё при первом анонсе протокола в 2024 году.

Почему прошлая попытка провалилась

В 2024 году Google уже запускала защиту cookies в Chrome 127 — App-Bound Encryption. Идея была проще: шифровать cookies системным сервисом Windows, работающим с правами SYSTEM, а не обычного пользователя. Малварь бы не смогла расшифровать cookies без прав SYSTEM или инъекции кода в процесс Chrome — обе операции шумные и заметные для антивирусов.

Защита продержалась около двух месяцев. К сентябрю 2024 авторы MeduzaStealer, WhiteSnake, LummaC2, Lumar, Vidar и StealC выкатили обход, не требующий прав SYSTEM. Разработчики другой малвари, Rhadamanthys, тогда похвастались, что реверс-инжиниринг защиты занял у них 10 минут.

Почему DBSC должен сработать лучше: App-Bound Encryption был программной защитой — малварь на машине в принципе могла её сломать, потому что ключ хранился в памяти того же компьютера. DBSC переносит ключ в TPM: Chrome может попросить TPM подписать challenge, но не может прочитать или экспортировать сам ключ. Это архитектурное отличие, а не «усилили обфускацию» — украсть содержимое TPM без физического доступа к железу невозможно.

Что нужно сделать бэкенд-разработчикам

Главное — DBSC не требует изменений во фронтенде. Браузер сам берёт на себя всю работу с ключами и подписями. На бэкенде нужно добавить следующее:

• Эндпоинт регистрации сессии — принимает публичный ключ от браузера и сохраняет его рядом с сессией
• Эндпоинт обновления сессии — выдаёт новый короткоживущий cookie после проверки подписи challenge приватным ключом
• Логику выдачи cookies — вместо одного долгоживущего теперь серия короткоживущих с refresh каждые несколько минут
• Graceful degradation для браузеров без DBSC — чтобы Firefox и Safari не ломались на тех же эндпоинтах

Спецификация опубликована на сайте W3C как открытая спецификация, разработанная Google совместно с Microsoft, — так что другие браузеры теоретически могут подхватить. Google подготовила гайд по внедрению для разработчиков, а для тех, кто хочет глубже — explainer на GitHub.

Что это значит для обычного пользователя

Если вы просто пользуетесь Chrome — обновитесь до 146. Дальше делать ничего не нужно: защита включается автоматически на сайтах, которые уже внедрили DBSC. Для остальных сайтов всё работает как раньше — обычные cookies без аппаратной привязки. Пока что DBSC активна только на Windows с TPM 2.0; на ПК без TPM Chrome откатится на обычные cookies.

Выводы

Главное — защита от кражи сессий впервые переносится с программного уровня на аппаратный. Это ломает бизнес-модель инфостилеров, которая последние годы была построена на перепродаже украденных cookies: украденный токен просто перестаёт стоить денег, если его нельзя использовать на чужой машине. Если вы держите критичный сервис — добавляйте DBSC в беклог. Если просто пользуетесь Chrome — обновитесь до 146 и ждите, когда Firefox и Safari подтянутся.

Источники: BleepingComputer | Google Online Security Blog | gHacks

Use-after-free (использование после освобождения) — класс ошибок памяти, при котором программа обращается к уже освобождённому участку. В контексте браузера это позволяет атакующему выполнить произвольный код через специально подготовленную HTML-страницу.

• CVE-2026-5281 — use-after-free в Dawn (реализация WebGPU в Chromium), уже эксплуатируется
• Затронуты Chrome, Edge, Brave, Opera, Vivaldi — все Chromium-браузеры
• Google выпустила патч: Chrome 146.0.7680.177/178
• CISA добавила в каталог обязательных исправлений с дедлайном 15 апреля 2026
• Это 4-й активно эксплуатируемый zero-day в Chrome с начала года

Что за уязвимость

Баг находится в Dawn — open-source кроссплатформенной реализации стандарта WebGPU, которую Chromium использует для доступа к GPU. Use-after-free в Dawn позволяет атакующему, скомпрометировавшему процесс рендерера, выполнить произвольный код через сформированную HTML-страницу.

Google подтвердила, что эксплойт для CVE-2026-5281 существует и используется в реальных атаках, но не раскрыла деталей — кто стоит за эксплуатацией и каким образом уязвимость используется. Это стандартная практика: информацию публикуют после того, как большинство пользователей обновятся.

WebGPU как новая поверхность атаки

CVE-2026-5281 — не первая проблема в GPU-подсистеме Chrome. В 2026 году три из четырёх zero-day затронули компоненты, связанные с графикой и GPU-ускорением:

• CVE-2026-2441 (февраль) — use-after-free в CSS-компоненте Chrome
• CVE-2026-3909 и CVE-2026-3910 — два high-severity zero-day, исправленных ранее
• CVE-2026-5281 (апрель) — use-after-free в Dawn/WebGPU

Появление WebGPU как стандартного API браузера расширило поверхность атаки: код, работающий с GPU-памятью и шейдерами, стал доступен из любой веб-страницы. Баги в этом слое особенно опасны — они дают доступ к аппаратному уровню из песочницы браузера.

Как обновить

Проверьте версию Chrome: Меню → Справка → О Google Chrome. Безопасные версии:

• Windows и macOS: 146.0.7680.177 или 146.0.7680.178
• Linux: 146.0.7680.177

После проверки нажмите «Перезапустить», чтобы применить обновление. Если используете Edge, Brave, Opera или Vivaldi — проверьте наличие обновлений и в них: все они построены на Chromium и подвержены той же уязвимости.

Реакция CISA

CISA добавило CVE-2026-5281 в каталог Known Exploited Vulnerabilities (KEV) 1 апреля 2026 года. Все федеральные агентства обязаны применить патч до 15 апреля 2026. Для остальных организаций каталог KEV — ориентир: если CISA считает уязвимость достаточно серьёзной для обязательного исправления, стоит последовать.

Выводы

Четвёртый zero-day в Chrome за 2026 год — и третий, связанный с графической подсистемой. WebGPU открывает новые возможности для веб-разработки, но одновременно создаёт поверхность атаки, которой раньше не существовало. Обновите браузер, проверьте Chromium-форки, и если вы администрируете инфраструктуру — добавьте KEV-каталог CISA в свой процесс патч-менеджмента.

Источники: The Hacker News | SOCRadar

Как это работает

Эмулятор исполняет реальный машинный код для процессоров Intel 8086. Тактовый генератор построен на CSS-анимациях в сочетании со style container queries, поэтому система работает автономно и не требует от пользователя никакого взаимодействия — программа крутится сама.

Логика реализована благодаря новым возможностям CSS, которые пока доступны только в экспериментальном виде:

• условные операторы if()
• style queries (стилевые запросы контейнера)
• кастомные @function

На странице проекта есть скрипт-тег, но он лишь ускоряет работу тактового генератора. Если отключить JavaScript, эмулятор продолжит работать — просто чуть медленнее и менее стабильно.

Запуск собственных программ

В эмуляторе можно запускать собственные программы. Достаточно написать код на C и скомпилировать его через gcc-ia16 с помощью скрипта из репозитория автора. На выходе — готовый HTML-файл со стилями, внутри которого исполняется ваш бинарник.

По умолчанию эмулятору доступно 1,5 КБ памяти, но этот лимит можно увеличить в конфигурации. Программа загружается по адресу 0x100, предусмотрены специальные адреса ввода-вывода для взаимодействия с «железом» — экранным выводом и клавиатурой.

Ограничения и совместимость

Практического применения у проекта нет — производительность крайне низкая. Зато это отличная демонстрация того, что современный CSS действительно стал тьюринг-полным.

Из-за использования экспериментальных CSS-функций запустить демку пока можно только в браузерах на базе Chromium (Chrome, Edge, Opera и т.д.). Firefox и Safari пока не поддерживают нужные спецификации, хотя все используемые фичи входят в официальный стандарт CSS.

Отдельно автор подчёркивает: проект создан полностью вручную, без использования ИИ. CSS написан в Sublime Text, а для генерации повторяющихся частей кода использовался Python-скрипт.

Попробовать эмулятор можно на сайте проекта, исходный код доступен на GitHub под лицензией GPL-3.0.

Зачем это нужно?

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

Автор посчитал, что большинство существующих гайдов либо слишком технические и детализированные, либо, наоборот, поверхностные. Поэтому он решил выбрать другой подход.

Руководство построено на небольших примерах, чтобы понять технические детали и сформировать интуитивное понимание работы браузеров.

Чтобы материал оставался кратким и по существу, автор намеренно опустил многие критические детали: разные версии HTTP-протокола, SSL, TLS, нюансы работы DNS и многое другое.

Браузеры работают с URL

Вы можете ввести в адресную строку буквально что угодно. Но под капотом браузеры работают с URL:

• Случайный текст вроде «pizza» будет преобразован в поисковый URL типа https://google.com/search?q=pizza
• Доменное имя вроде example.com будет нормализовано в полный URL: https://example.com

Чтобы увидеть, как это работает на практике, попробуйте ввести «pizza» или «example.com» в адресную строку браузера.

Превращение URL в HTTP-запрос

Когда браузер знает точный URL, который нужно посетить, он может отправить запрос на сервер, чтобы получить ресурс и отобразить его. Браузеры общаются с серверами по протоколу HTTP.

Чтобы понять, как URL переводится в формат HTTP-запроса, рассмотрим пример с полным URL вроде example.com.

HTTP-запросы содержат заголовки в таком формате:

Один из заголовков — это заголовок Host. Он используется для идентификации сервера, на который отправляется запрос: example.com.

Определение адреса сервера

Браузеры не могут отправлять запросы на имена вроде example.com.

Компьютеры общаются с IP-адресами, поэтому браузер сначала обращается к системе DNS, чтобы преобразовать доменное имя в IP-адрес, прежде чем подключиться к серверу и отправить HTTP-запрос.

Например, если вы введёте в терминале команду для разрешения домена, DNS вернёт соответствующий IP-адрес:

Установка TCP-соединения

После того как DNS предоставил браузеру IP-адрес, всё ещё требуется надёжное соединение с сервером. TCP — это протокол, который устанавливает такое соединение до того, как будут отправлены любые HTTP-данные.

TCP устанавливает соединение с помощью трёхэтапного согласия, которое подтверждает, что обе стороны готовы отправлять и получать данные:

1. SYN: клиент отправляет свой порядковый номер (seq=1000), чтобы открыть соединение
2. SYN-ACK: сервер подтверждает пакет, добавляя свой порядковый номер (seq=5000) и подтверждая номер клиента, увеличивая его на 1 (ack=1001)
3. ACK: клиент подтверждает номер сервера, увеличивая его на 1 (ack=5001), и соединение готово

Эти номера показывают, как клиент и сервер отслеживают диалог. Они считают байты, поэтому обе стороны согласны с тем, где начинается поток данных и что должно произойти дальше. Если какие-то данные не приходят, отправитель видит разрыв и повторно передаёт недостающие байты. Именно так TCP поддерживает порядок данных и надёжность после установки соединения.

Когда вы начинаете отправлять пакеты и пытаетесь нарушить работу сети, вы можете увидеть, как TCP справляется с потерями данных и восстанавливает передачу.

HTTP-запросы и ответы

После установки TCP-соединения браузер может отправить HTTP-запрос на сервер.

Представьте, что вы наблюдаете за тем, как HTTP-запрос путешествует к серверу, а HTTP-ответ возвращается в браузер:

БРАУЗЕР (КЛИЕНТ)

СЕРВЕР

Когда приходит HTTP-ответ, браузер читает сырой HTTP-ответ и начинает рендеринг HTML-контента.

Парсинг HTML для построения DOM-дерева

После того как приходит HTTP-ответ, браузер отделяет заголовки от тела и направляет HTML-байты в парсер. Парсер превращает теги вроде <h1> в токены и строит DOM-дерево.

Посмотрите, как HTML-поток парсится в DOM-дерево:

DOM-дерево:

Парсинг происходит потоково и устойчив к ошибкам: браузер начинает строить узлы ещё до того, как документ полностью загружен, и вставляет недостающие теги, чтобы дерево оставалось валидным. Когда появляется тег <script>, парсинг может приостановиться, чтобы выполнить скрипт.

DOM-дерево затем объединяется с CSS, чтобы создать render tree (дерево рендеринга), которое используется для расчёта layout и отрисовки пикселей.

О важности DOM

DOM — это внутренняя модель документа в памяти браузера. Это общий контракт между HTML-парсером, движком CSS-селекторов и средой выполнения JavaScript. Изменения в DOM немедленно влияют на layout, стили и то, с чем пользователи могут взаимодействовать.

DOM обеспечивает всё: от выборки элементов до динамической стилизации и обработки событий. Попробуйте отредактировать JavaScript-код и посмотрите, как меняется DOM:

Редактируемый JavaScript:

Живой DOM:

Layout, Paint и Composite

После того как DOM и CSS готовы, браузер запускает конвейер рендеринга: Layout (reflow) для расчёта размеров и позиций, Paint для заполнения пикселей, затем Composite для сшивки слоёв на GPU.

Не каждое изменение запускает все этапы заново. Изменение цвета обычно требует только перерисовки (repaint), тогда как изменение размеров заставляет пересчитывать layout и paint.

Этапы рендеринга:

1. Layout — пересчёт размеров и позиций
2. Paint — заполнение пикселей в слои
3. Composite — сшивка слоёв на GPU

Пример DOM:

Composite всегда смешивает слои в финальный кадр.

Именно поэтому страницы с большим количеством layout-операций ощущаются медленнее: больше работы нужно выполнить, прежде чем можно будет показать следующий кадр.

Вот и всё! Если вы разобрались со всеми примерами, у вас должна сформироваться чёткая ментальная модель работы браузеров.

Теперь вы понимаете путь от ввода URL в адресную строку до отображения пикселей на экране: разрешение DNS, установку TCP-соединения, отправку HTTP-запросов, парсинг HTML, построение DOM и конвейер рендеринга с этапами Layout, Paint и Composite.

Без установки, без танцев с бубном и без привязки к конкретной платформе. Игра работает на компьютерах, планшетах и смартфонах — достаточно открыть страницу и нажать «старт».

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

Быстрый запуск и минимальная загрузка

Одна из главных фишек версии — скорость старта. Для начала игры браузер загружает всего около 56 МБ данных. Остальные ресурсы подгружаются динамически по мере исследования игрового мира.

Благодаря этому Vice City запускается почти мгновенно даже на слабых устройствах и при нестабильном интернете.

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

Управление, язык и сохранения

В браузерной Vice City есть поддержка геймпадов и сенсорного управления. Это делает игру более удобной на мобильных устройствах и планшетах, где клавиатура и мышь недоступны.

Доступны две версии игры: оригинальная английская и полностью локализованная русская с озвучкой от студии GamesVoice. Сохранения можно хранить как локально, так и в облаке. Это опять же позволяет продолжить прохождение с любого устройства.

Как работает доступ и почему нужна оригинальная игра

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

Однако при попытке начать сюжет — после достижения первого чекпоинта в отеле Ocean View — игра попросит указать путь к файлу оригинальной GTA: Vice City, например gtavc.exe.

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

Зачем все это сделали

По словам авторов проекта, браузерная версия Vice City создана в образовательных и исследовательских целях. Она демонстрирует, на что способны современные веб-технологии и как сложные игровые проекты могут работать без установки и нативных клиентов.

Для игроков же это простой и эффектный способ вернуться в Vice City — быстро, удобно и буквально в пару кликов.

Вместо привычного хаотичного набора страниц, браузер анализирует контекст и превращает открытые вкладки в интерактивные веб-приложения. Первый ключевой механизм Disco называется GenTabs.

Проект ориентирован на пользователей, которые работают с большим количеством источников: исследуют темы, планируют поездки, собирают информацию или обучаются.

Google называет Disco «исследовательской платформой», а не готовым продуктом. Сейчас он доступен только для ограниченного числа пользователей — доступ можно попросить на специальной странице (но только на macOS).

Как работает GenTabs

GenTabs построен на базе модели Gemini 3 и использует сразу несколько источников контекста. В том числе текущие вкладки, историю взаимодействия и диалог с пользователем.

На основе всего этого ИИ определяет, какую задачу человек пытается решить и предлагает сгенерированный инструмент в виде мини-приложения. Например, GenTabs может:

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

При этом пользователю не нужно писать код — инструмент создается и настраивается через обычные текстовые запросы.

Все элементы GenTabs сохраняют связь с оригинальными веб-источниками, что позволяет проверить данные и избежать «черного ящика».

Вкладки как приложения, а не как список

Ключевая идея Disco — уйти от модели, где вкладки существуют сами по себе.

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

Google подчеркивает, что Disco не заменяет веб-сайты и не копирует их содержимое. GenTabs работает поверх интернета, связывая результаты с исходными страницами и сохраняя возможность перейти к первоисточнику в любой момент.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

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

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

Для максимально осторожных пользователей — это Chrome, из которого убрали всю телеметрию Google, отслеживание и облачные сервисы. Браузер работает, но требует ручной настройки: отсутствуют автоматические обновления и встроенная синхронизация между устройствами.

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

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

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

Миллионы людей продолжают использовать одни и те же слабые пароли на всех сайтах — или, что ещё хуже, держатся за классику вроде «123456». Даже сильные пароли мало помогают, если их повторяют или забывают. Конечно, большинство браузеров предлагают встроенные менеджеры паролей, но они ограничены, привязаны к одному браузеру и менее безопасны, чем специализированные решения.

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

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

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

Предлагает мониторинг даркнета, интеграцию VPN и плавный пользовательский опыт. Есть бесплатный тариф с ограниченными функциями, но премиум-версия конкурентоспособна.

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

Пропустите LastPass — когда-то фаворит, он упал в немилость после повторных утечек безопасности. Для душевного спокойствия лучше поискать в другом месте.

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

Одно из первых дел, которое стоит сделать после сборки ПК — убедиться, что компоненты соответствуют ожиданиям и работают корректно. К счастью, существует много инструментов, позволяющих мониторить, тестировать и настраивать железо.

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

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

Если требуется сохранять всю систему, терабайты медиа, состояние дисков используйте отдельные сервисы резервного копирования.

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

Простой для не-технарей — Carbonite, с возможностью быстрого восстановления и круглосуточной поддержкой.

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

Об этом сообщили специалисты Brave Software и независимые исследователи кибербезопасности.

Пром-инъекции — это метод, при котором злоумышленники внедряют команды прямо в текст или код страницы, чтобы влиять на поведение ИИ, не оставляя следов во вводе пользователя.

Модель «читает» такие инструкции как часть задачи и начинает им следовать, выполняя действия, не предусмотренные разработчиками.

«Не доверяй ИИ» вместо резюме

Brave назвала проблему «системной уязвимостью целого класса ИИ-браузеров».

В одном из тестов, исследователи встроили в Google-документ скрытую инструкцию. После этого Atlas, вместо запрошенного резюме, вывел фразу «не доверяй ИИ». Тем самым детище OpenAI продемонстрировало, что поведение агента можно подменить буквально одной строчкой текста.

По словам специалистов, аналогичные уязвимости замечены в других продуктах — включая Perplexity Comet и Fellou.

Реакция OpenAI

Руководитель направления безопасности OpenAI Дэйн Стаки подтвердил, что угроза существует:

Промт-инъекции остаются одной из ключевых нерешенных проблем в области ИИ-безопасности. Злоумышленники будут тратить значительные ресурсы, чтобы заставить ChatGPT-агентов поддаваться подобным атакам. Мы рассматриваем это как фронтир безопасности.

Стаки отметил, что компания внедряет новые методы защиты и обучения, но полностью исключить риск пока невозможно.

Что говорят эксперты

Исследователь ИИ-безопасности Йоханн Рехбергер, известный своими работами о промт-инъекциях, заявил, что подобные атаки «напоминают социальную инженерию, только против машин»:

Нет стопроцентной защиты. Поэтому важно внедрять фильтры не только в модель, но и на уровне инфраструктуры, а также сохранять человеческий контроль.

Он добавил, что OpenAI уже внедрила режимы с ограниченным доступом к данным и ведет активное тестирование Atlas, однако агентные ИИ-системы все еще находятся на ранней стадии развития, и новые уязвимости будут появляться регулярно.

WebAssembly в браузере: как всё начиналось

Прежде чем говорить о настоящем и будущем WebAssembly, вспомним, с чего он начинался. Технология создавалась исключительно для работы в браузере. WebAssembly использовался (и используется сейчас): для оптимизации производительности, миграции legacy-нативных приложений, запуска кода на языках, отличных от JavaScript.

Ярче всего успех этого подхода демонстрирует Figma — популярный редактор для дизайнеров интерфейсов. Для многих стало неожиданностью, что редактор Figma, будучи веб-приложением, написан на C++.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

На заре появления WASM многие ошибочно считали его то ли машиной для ускорения JS, то ли нативным модулем, который имеет доступ к операционной системе. Буквально чудо-коробочка, в которую можно поместить весь код, и он станет быстрее в три раза. Но в реальности технология столь ограничена в применении, что она до сих пор остается нишевой, хотя и очень перспективной.

До WebAssembly разработчики Figma использовали технологию asm.js — предшественника WASM. Специальный компилятор преобразовывал (транспилировал) код C++ в высокооптимизированный JavaScript, который браузерные движки могли выполнять с близкой к нативной производительностью. У этого подхода были недостатки: большой размер получаемого кода и затраты на его парсинг и компиляцию в браузере.

Переход на WebAssembly стал переломным моментом. Поскольку WASM — это бинарный машинно-ориентированный формат, он гораздо компактнее и требует меньше ресурсов для обработки браузером. В результате миграции с asm.js на WebAssembly, Figma получила трёхкратный прирост производительности.

Этот кейс наглядно показал, что WebAssembly — это не просто ещё одна веб-технология, а настоящий прорыв, который стирает границы между нативными и веб-приложениями. Успех Figma и подобных проектов заложил фундамент для следующего логического шага: если WebAssembly так эффективен в браузере, почему бы не запускать его где угодно?

Почему WebAssembly выходит за пределы браузера

WebAssembly изначально создавался как безопасная, эффективная и портируемая платформа для компиляции высокоуровневых языков. Ключевые преимущества этого инструмента — изоляция выполняемого кода, платформонезависимость и высокая производительность — оказались востребованы не только в вебе.

Серверные и встроенные системы долгое время страдали от проблем совместимости, безопасности и сложности распространения кода. Традиционные подходы к изоляции (например, контейнеризация) требуют значительных ресурсов и не всегда дают достаточный уровень безопасности. WebAssembly предлагает альтернативу: песочницу с минимальными накладными расходами и встроенными механизмами безопасности.

Главным катализатором этого процесса стал стандарт WASI (WebAssembly System Interface), разработанный при участии Mozilla, Fastly и других компаний. WASI предоставляет стандартизированный интерфейс, где WebAssembly-модули взаимодействуют с операционной системой и решают проблему переносимости между различными платформами.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Открытая «кроссплатформенная» обертка WASI — это довольно большой прорыв в разработке, так как в текущем состоянии все современные продукты, выпускающиеся для разных ОС с одной кодовой базой, имеют большие, подчас legacy модули совместимости, или же запускаются внутри особых песочниц, сильно увеличивающих размер бандла. Например, браузерный движок Electron или React Native.

Как WebAssembly работает вне браузера

Вне браузера WebAssembly исполняется в специальных средах выполнения (runtimes), которые взаимодействуют с операционной системой через WASI. Известные примеры — Wasmtime от Mozilla, Lucet от Fastly и Wasmer.

Эти среды выполняют роль «концептуальной операционной системы», предоставляют модулям WebAssembly стандартизированный доступ к системным ресурсам: файлам, сети, случайным числам и другим функциям.

WebAssembly принципиально отличается от традиционных подходов тем, что изолируется на уровне инструкций, а не процессов. Каждый модуль выполняется в собственной песочнице с чётко определенными границами доступа к ресурсам. Это значительно снижает риск компрометации системы даже в случае уязвимостей в самом коде.

Безопасность как фундаментальное преимущество

Безопасность WebAssembly основана на нескольких уровнях защиты. Модули выполняются в изолированной среде, отделённой от хост-системы с помощью техник изоляции отказов. Это означает, что приложения выполняются независимо и не могут покинуть песочницу без явного разрешения через API.

Система контролирует выполнение кода с помощью статической проверки типов — все функции нужно явно объявлять перед использованием. Даже косвенные вызовы проверяются на соответствие сигнатурам прямо во время работы программы. Такой подход блокирует распространённые атаки — переполнение буфера и внедрение вредоносного кода.

Память в WebAssembly изолирована — напрямую с ней работать нельзя. Когда система обращается к памяти, она проверяет границы доступа, а локальные переменные хранятся в защищённом стеке вызовов.

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

Если запускать изолированные модули WebAssembly на своей инфраструктуре вместо публичного облака, можно безопасно обрабатывать чувствительные данные без риска утечки.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь явно подчеркивается безопасность платформы из коробки, но не стоит забывать, что на разработчике все еще лежит ответственность за безопасность данных и пользователей. Режим «разрешить все» — стандарт для любого MVP, и без аудита перед релизом тут все еще не обойтись. Платформа лишь гарантирует, что память процесса будет защищена от несанкционированного доступа, что уже давно делается во всех популярных операционных системах. Чтобы выйти за пределы стека или прочитать чужую память, надо использовать очень старые компиляторы или сильно низкоуровневые средства разработки.

Серверные применения WebAssembly

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

Микросервисы и бессерверные архитектуры

WebAssembly идеально подходит для микросервисных архитектур благодаря легковесности и быстрому запуску. В отличие от традиционных контейнеров, WASM-модули не требуют отдельной ОС и запускаются за миллисекунды.

Кейс: компания Fastly использует WebAssembly для исполнения пользовательского кода на серверах. Их технический директор Тайлер МакМаллен отмечает: «Мы рассматриваем WebAssembly как платформу для быстрого и безопасного кода в облаке на границе сети».

Безопасные расширения приложений

Многие приложения позволяют пользователям запускать собственный код через плагины и расширения. Но это создаёт риски для безопасности. В WebAssembly пользовательский код выполняется с минимальными рисками.

Веб-сервер Angie использует WASM для безопасности пользовательских модулей. Это решает проблему совместимости, характерную для традиционных модулей, написанных на C.

Экономическая эффективность таких вариантов становится решающим фактором. По данным на 2025 год, глобальный рынок больших языковых моделей (LLM), чьи backend-системы часто используют микросервисные архитектуры, демонстрирует колоссальный рост. Прогнозируется, что к 2033 году он достигнет $140,8 млрд.

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь все закономерно: бизнес всегда выбирал решения, где можно было написать код один раз и поставить его сразу на несколько платформ. Даже если сами решения сырые и небезопасные, дешевле было увеличить поддержку пользователей и настроить аудит безопасности, чем реализовать фичу для каждой платформы отдельно. Так на рынок вышли Python, Node.js, React Native, стремительно обгоняя конкурентов за счет скорости разработки.

WebAssembly в embedded-системах

WebAssembly успешно работает на серверах, но главные изменения происходят во встроенных системах. В IoT всегда была проблема совместимости: разные процессоры, операционные системы и периферийные устройства.

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

Удаленные интерфейсы и централизованный мониторинг

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

Согласно исследованию Qt Company, более 77% респондентов из промышленной автоматизации считают удалённое управление и централизованный мониторинг критически важными в ближайшие десять лет. WebAssembly предоставляет экономичный способ реализации таких решений.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А это, пожалуй, самая продающая фича: обычно у компаний, которые выходят на рынок со своими железками, базами данных и прочими продуктами, все продажи буквально построены на том, что программисты у клиента знают, как это быстро встроить. Так, бизнес готов платить деньги. Обычно у них есть проблемы с API для разных языков программирования, ОС и девайсов: либо хорошо все в JS, а в мобилках не заводится, либо наоборот. А то и вообще: стоит забросить поддержку платформы хоть на полгода, сразу всёперестает работать. Потому поставлять модуль для WASI должно быть дёшево, при этом потенциально можно закрыть даже платформы будущего. Это инновация сродни изобретению стандарта USB.

Прототипирование и сотрудничество

WebAssembly упрощает процесс прототипирования и обратной связи для embedded-устройств. Разработчики могут скомпилировать приложение, разместить его на веб-сервере и предоставить доступ всем заинтересованным сторонам. При этом не нужно распространять устройства или проходить сложные процессы публикации.

Компания Qt использует этот подход в Qt Design Viewer, позволяя разработчикам делиться интерактивными дизайнами, созданными в Qt Design Studio, с коллегами по всему миру.

Примеры внедрения: история ByteFog

Компания Inetra из Новосибирска разработала технологию peer-to-peer для доставки видео ByteFog. Система работает на множестве платформ: Windows, Linux, Android, iOS, Web и Tizen.

Изначально веб-версия использовала Netscape Plugin API, но когда основные браузеры прекратили поддержку этой технологии в 2015 году, компания осталась без веб-версии на два года. Поэтому в 2017 году они обратились к WebAssembly.

Используя компилятор Emscripten, разработчики перенесли существующее C++-приложение в браузер. Главной сложностью было разграничить транспортный слой и бизнес-логику через интерфейсы. Основной канал доставки видео заменили на AJAX, а P2P-слой — на WebRTC.

Результат компиляции — двоичный.wasm-файл и «клеевой код» на JavaScript, взаимодействующий с браузерными API. Это позволило запускать сложную P2P-систему Peers.TV напрямую в браузере без плагинов.

Fastly Terrarium: экспериментальная платформа для WebAssembly-приложений

В 2021 году инженеры Fastly выпустили Terrarium — экспериментальную платформу для запуска WebAssembly-модулей на периферийных устройствах (edge devices), над которой работали несколько лет. Сейчас проект всё ещё в демо-версии.

Terrarium показывает, как можно запускать пользовательский код в изолированных средах с минимальной задержкой. Платформа использует рантайм Lucet, разработанный инженерами Fastly, и поддерживает компиляцию из Rust, C++ и AssemblyScript.

Ключевая особенность подхода — стандарт WASI для системных вызовов, что помогаетпереносить модули между разными средами. Это особенно важно для edge-вычислений, где код должен работать на разнородном оборудовании.

По данным тестирования, время запуска модулей составляет около 50 микросекунд, а потребление памяти измеряется килобайтами на инстанс. Такие показатели достигаются за счёт изоляции на уровне инструкций, а не процессов.

Хотя Terrarium не стал коммерческим продуктом, его наработки повлияли на другие решения Fastly. Компания развивает направление WebAssembly-вычислений далее — экосистема постоянно обновляется.

Технические вызовы и ограничения

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

Эти компромиссы особенно заметны в embedded-среде, где каждое решение напрямую влияет на энергопотребление, стоимость и надежность системы.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Доступ к аппаратным ресурсам

WebAssembly ограничивает прямой доступ к аппаратуре во встроенных системах — это плата за безопасность. Это усложняет работу embedded-разработчикам.

Сообщество WebAssembly уже решает проблемы. Стандарт WASI продолжает развиваться, и в будущем появятся более гибкие способы работы с оборудованием.

Размер файлов и производительность

WebAssembly-модули могут иметь значительный размер, особенно при включении стандартных библиотек. В случае ByteFog размер бандла достигал 100 МБ, что создавало проблемы для инструментов сборки и загрузки в браузере.

Чтобы уменьшить размер, нужно тщательно удалять неиспользуемый код и подбирать настройки компиляции. Кроме того, передача данных между хост-системой и WebAssembly-модулем обходится дорого.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Тут имеется ввиду краеугольная проблема WASM модулей — ввод и вывод. Дело в том, что он довольно низкоуровневый, и если в случае с микроконтроллерами они буквально будут говорить на «одном языке» с железом, то более высокоуровневые системы, передающие данные в том же JSON, столкнутся с довольно затратным процессом сериализации данных. Чтение строки с английскими буквами это одно, а текст на разных языках — это уже задачка со звездочкой. Так что в случае LLM надо будет серьезно работать надо протоколом обмена данными.

Инструменты и экосистема

Экосистема WebAssembly вне браузера всё ещё развивается. Поддержка различных языков программирования неравномерна: лучше всего дела обстоят у C/C++ и Rust, с интерпретируемыми языками всё сложнее.

Отладка WebAssembly-модулей ограничена в сравнении с традиционными средствами. Разработчикам часто приходится использовать косвенные методы и работать с преобразованным кодом. Это особенно важно в контексте другой быстрорастущей тенденции — переносить выполнение ИИ-моделей с серверов на сами устройства пользователей (edge computing).

Например, современные компактные LLM, такие как Phi-4-mini-flash, демонстрируют впечатляющую производительность на мобильных чипах ARM, обрабатывая запросы за 90–100 мс прямо на устройстве без облака. Для подобных сценариев WebAssembly с его переносимостью и низким потреблением ресурсов выглядит идеальной средой, если сможет предложить более прямой и эффективный доступ к специфическим возможностям железа.

Будущее WebAssembly вне браузера

Перспективы WebAssembly вне браузера выглядит многообещающим. Стандарт WASI совершенствуется, поддерживая новые системные интерфейсы и возможности. Разработчики получают всё более мощные инструменты для создания и отладки WASM-модулей.

В embedded-сфере WebAssembly может стать стандартом для безопасного выполнения кода на различных устройствах IoT (интернета вещей). Его способность работать на ресурсо-ограниченных устройствах при изоляции делает инструмент привлекательной альтернативой традиционным подходам.

Майлз Боринс, технический директор руководящего комитета Node.js, видит потенциал WebAssembly в решении одной из наибольших проблем фреймворка: «Это способ достичь скорости, близкой к нативной, и повторно использовать код, написанный на других языках (C и C++), сохранять портативность и безопасность».

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Как я понял, под фундаментальными проблемами имеется в виду ограничение на кол-во операций с потоками и файлами в текущий версиях Node.js, что не дает серверам на «ноде» тягаться с Nginx на равных.

Итоги

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

У WebAssembly всё ещё есть проблемы с доступом к аппаратным ресурсам и большим размерам модулей. Однако инструменты и стандарты активно развиваются — скорее всего, эти ограничения постепенно устранят.

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

Как отмечает Шон Уайт, директор Mozilla по R&D: «WebAssembly уже меняет способы доставки людям новых видов привлекательного контента. С WASI преимущества WebAssembly получат больше пользователей и больше устройств в разных местах».

WebAssembly больше не ограничивается браузером — он становится универсальной платформой для среды, где код должен выполняться безопасно и эффективно везде: от облачных серверов до крошечных устройств интернета вещей.

В первую очередь, это ударило по популярным блокировщикам рекламы, таким как uBlock Origin, которые не хотят или не могут перейти на ограниченную архитектуру Manifest V3.

Если вы столкнулись с тем, что привычные расширения перестали работать после обновления браузера — вы не одни. Но решение пока что есть. Рассказываем, как оживить uBlock Origin и почему стоит начать присматриваться к альтернативам вроде Firefox.

Что изменилось в Chrome 140

До выхода 140-й версии, можно было активировать поддержку старых расширений с помощью скрытых флагов, вроде Temporarily unexpire M137 flags. Это позволяло запускать uBlock Origin и другие расширения, основанные на Manifest V2.

Теперь же эти флаги удалены. Даже если вы откроете chrome://flags, найти нужные параметры больше не получится. Google официально убивает поддержку MV2, несмотря на протесты разработчиков и сообщества.

Как запустить uBlock Origin даже в Chrome 140

Пока что осталась одна «дыра» — через ярлык запуска браузера. Для этого нужно:

1. Создать ярлык Chrome на рабочем столе.
2. Щелкнуть правой кнопкой мыши и выбрать Свойства.
3. В поле Объект (Target) в конце строки дописать: --disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled
4. Сохранить изменения и запустить Chrome через этот ярлык.
5. После этого можно установить uBlock Origin напрямую из Chrome Web Store (если оно у вас удалилось).

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

Firefox или uBlock Origin Lite?

Google активно продвигает Manifest V3 под предлогом безопасности и производительности. Но по факту, на новой версии манифеста блокировщики рекламы становятся менее эффективными: они ограничены по числу фильтров, не могут перехватывать запросы на лету и теряют гибкость.

uBlock Origin Lite — упрощенная версия под V3 — работает, но не обеспечивает той же степени блокировки, особенно на сложных или агрессивных сайтах. Разработчик самого uBlock, Рэймонд Хилл, признал, что полноценный функционал восстановить не удастся.

Firefox, в свою очередь, сохраняет поддержку Manifest V2 и не планирует отказываться от нее в обозримом будущем. Расширения вроде uBlock Origin работают там в полную силу, без ограничений.

Что делать дальше

Если вы:

• Не готовы мириться с ослабленной блокировкой рекламы.
• Зависите от специфических расширений на MV2.
• Не хотите вручную править ярлыки и флаги при каждом обновлении...

...то можно присмотреться к Firefox или хотя бы временным альтернативам, вроде Opera или Edge на старых версиях Chromium.

Google уже показал намеченный курс. Все идет к полной блокировке Manifest V2. Так что даже если сейчас удалось найти обходной путь — это лишь временное решение.

На старте он доступен только подписчикам Max-плана ($200 в месяц) и пользователям из списка ожидания.

Comet ставит ИИ-поиск Perplexity в центр интерфейса: краткие ответы, резюме по запросам и автоматизация задач через встроенного помощника Comet Assistant.

Он может читать письма, уведомления из календаря, управлять вкладками и взаимодействовать с содержимым страниц. В браузере предусмотрен специальный «сайдбар» для чата с ассистентом — прямо на фоне открытого сайта.

Цель — полный отказ от Google

С запуском Comet, Perplexity надеется миновать зависимость от Chrome и продвигать свой поиск напрямую. CEO компании заявил, что хочет «создать операционную систему, через которую можно делать всё». По его мнению, именно браузер обеспечит «бесконечное удержание» пользователей.

Выпуск Comet — логичный шаг на фоне роста. В мае Perplexity обработал 780 млн запросов, а месячный прирост аудитории превысил 20%.

Альтернатива от OpenAI и других

Comet выходит на перенасыщенный рынок. Так, в июне свой ИИ-браузер Dia показала команда The Browser Company, а OpenAI, по слухам, тоже работает над подобным решением. Более того, компания уже наняла разработчиков из оригинальной команды Chrome.

Ассистент — фишка, но с нюансами

Comet Assistant действительно помогает — например, пересказывает письма и подсказывает, когда выходить из дома, чтобы не опоздать на встречу из календаря.

Он умеет читать Google Docs, смотреть видео на YouTube и понимать контекст страницы. Уровень вовлечённости высокий.

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

Кроме того, как и другие агенты, Comet Assistant ошибается. В одном из примеров он не смог корректно забронировать парковку — ввёл неправильные даты и настоял на оплате, несмотря на конфликт. Подобные «галлюцинации» — пока стандартная проблема всех ИИ-агентов.

Стоит ли пробовать?

Comet — это интересный эксперимент на стыке браузеров и ИИ. Его успех зависит от готовности пользователей доверять машине, которая видит всё на экране и может действовать от вашего имени.

Для одних это долгожданная замена Chrome с ИИ во главе угла. Для других — потенциально небезопасный шаг к тотальной интеграции ИИ в личную жизнь.

Выбор — за вами.

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

*Инструкция для Windows. Надеюсь, проблем при установке ни у кого не возникнет.

Основные шаги по установке

Установка VS Code

1. Перейдите на оф. сайт https://code.visualstudio.com/ и скачайте последнюю версию. На главной странице должна отображаться кнопка Download for Windows.
2. Дальше стандартная установка по инструкции: Next > Next > Install.

Установка Node.js. Шаги аналогичные

1. Также перейдите на оф. сайт https://nodejs.org/en/download и скачайте последнюю версию Node.js. Я использовал Windows Installer (.msi).
2. Такая же стандартная установка: Next > Next > Install.

Создание проекта

1. Создайте пустую папку на ПК, где будет храниться проект для автоматизации.
   У меня для этого есть отдельная директория, так удобнее хранить все проекты в одном месте. Но её можно создать даже на рабочем столе, разницы никакой. Мой путь к папке — C:\Users\Pavel\Projects\TestProject.
2. Запустите VS Code и там выберите созданную папку.

Установка Playwright

1. Перейдите в раздел управления расширениями Extensions.
2. Введите Playwright в поисковой строке.
3. Нужно скачать тот, что верифицирован Microsoft (у него больше всего установок).

Но установка еще не закончена, дальше:

• Вызовите Command Palette. Можно через основное меню: View > Command Palette или комбинацией клавиш Ctrl+Shift+P.
• Введите Test: Install Playwright в появившейся строке.
• Выберите необходимые браузеры для установки.
• Я оставляю только Chromium, его вполне достаточно. Кликаем Ok и ждем окончательной установки Playwright (должен появиться терминал и начаться установка пакетов).

Создание тестов

1. В основном окне Explorer добавьте новый файл в модуле tests (правая кнопка мыши, новый файл).
   *Важно, чтобы название файла оканчивалось на spec.ts или .test.ts (расширение может быть и .js): так Playwright определяет тесты по дефолту. В примере добавил файл login.spec.ts.

1. Вставьте следующий код в созданный файл login.spec.ts.
   Это пример логина на платформе, который ± подходит под любой сайт: нужно только изменить URL, locators и данные для входа. Использую тестовую платформу https://demowebshop.tricentis.com/.

Осталось совсем немного. Только запустить созданный тест:

1. Перейдите в раздел Testing.
2. Выберите созданный файл и запустите тесты кликом Run test.

Можете добавить еще один тест в тот же файл и посмотреть его выполнение:

Вот и всё! Теперь у вас есть базовая автоматизация с Playwright! Дальше можно дописывать другие тесты. Например, посмотреть работу системы с незарегистрированным email, вынести credentials в конфигурационный файл и т.д. И, конечно, углубляться, разбираться во всем, чтобы стать уверенным автоматизатором. Можно продолжить изучение статей на оф.сайте Playwright. Главное, соблюдайте best-practices при работе с ним.

Система родительского контроля считает Chrome небезопасным и автоматически закрывает его при запуске.

Что произошло

Family Safety — это встроенная функция Windows, позволяющая родителям ограничивать доступ детей к «неподобающему» контенту и приложениям.

Но после выхода Chrome 137.0.7151.68 и 137.0.7151.69, система начала блокировать браузер полностью — независимо от версии.

Пользователи жалуются, что:

• Chrome самопроизвольно закрывается и не открывается снова;
• переустановка и чистка кэша не помогают;
• даже старые версии браузера не работают.

Проблема затрагивает в основном Windows 11, но есть жалобы и от пользователей Windows 10.

Что говорит Google

Менеджер сообщества Chrome, Эллен Т, подтвердила, что виной сбоя — Family Safety. Чтобы разблокировать Chrome, родителям нужно вручную изменить настройки фильтрации:

1. Зайти на сайт Microsoft Family Safety или открыть мобильное приложение;
2. Выбрать нужный аккаунт ребёнка;
3. Отключить фильтр «Filter inappropriate websites» в разделе Edge;
4. Или перейти в Windows → Apps & Games → разрешить Chrome.

Временный костыль

Некоторые пользователи смогли обойти блокировку, переименовав файл chrome.exe в chrome1.exe. Этот обходной путь сработал, но Microsoft пока не предложила официального исправления бага.

Пока же ситуация напоминает борьбу двух браузеров, в которой Family Safety неожиданно встал на сторону Edge.

Откуда возник CORS

Всё началось в начале 2000-х, когда веб-приложения становились всё сложнее, а разработчики чаще нуждались в данных с других доменов. Однако браузеры строго придерживались политики одного источника (Same-Origin Policy, SOP), запрещавшей доступ к сторонним ресурсам. Эта политика появилась ещё в 1995 году в Netscape Navigator 2.0 и была призвана защитить пользователей от атак вроде XSS. Проблема в том, что SOP блокировала не только вредоносные, но и вполне легитимные запросы, например, к внешним API. Разработчики пытались обойти ограничения с помощью JSONP или iframe, но такие решения были небезопасными и нестабильными.

В 2005 году инженер Мэтт Ошри предложил идею более надёжного и безопасного механизма, который в дальнейшем стал основой CORS. А в 2008-м Анн ван Кестерен подготовила черновик спецификации для W3C. В 2014 году CORS официально вошёл в стандарт Fetch API и с тех пор стал ключевым элементом работы с кросс-доменными запросами. Он помогает контролировать доступ к ресурсам, сохраняя баланс между открытостью веба и безопасностью пользователей.

Как устроен CORS

CORS работает как диалог между браузером и сервером, основанный на HTTP-заголовках. Когда фронтенд-приложение (например, на сайте frontend.com) запрашивает данные с другого домена (api.com), браузер автоматически добавляет к запросу заголовок Origin: https://frontend.com. Этот заголовок сообщает серверу, откуда пришёл запрос.

Сервер в ответ решает, разрешать ли доступ. Если он включает в ответ заголовок Access-Control-Allow-Origin и указывает там адрес запроса (например, https://frontend.com) или символ * (разрешение для всех доменов), то браузер пропускает ответ. Если такого заголовка нет или значение не совпадает, браузер блокирует ответ — даже если сервер технически его отправил.

Для так называемых «сложных» запросов, например, с методом POST или нестандартными заголовками, браузер сначала отправляет предварительный (OPTIONS) запрос, чтобы уточнить у сервера, допустим ли основной. В ответе сервер указывает, какие методы (Access-Control-Allow-Methods) и заголовки (Access-Control-Allow-Headers) разрешены.

Пример ответа сервера с разрешением:

Топ-7 самых частых ошибок в CORS и как их исправить

Для того чтобы определить оптимальные методы работы, лучше учиться на ошибках. Хорошая новость в том, что почти все CORS-ошибки легко понять и исправить — если знать, где искать. Ниже собрали 7 самых распространённых ошибок CORS, с которыми сталкиваются разработчики, и рассказали, как можно с ними справиться без боли и паники.

Нет заголовка Access-Control-Allow-Origin

Сообщение об ошибке:

"No ‘Access-Control-Allow-Origin’ header is present on the requested resource"

Когда ваш JavaScript-код пытается получить данные с другого домена, браузер ожидает, что в ответе будет заголовок Access-Control-Allow-Origin. Если его нет — браузер блокирует ответ, считая его небезопасным.

Решение 1: Настроить сервер на разрешение CORS

Если вы контролируете сервер, добавьте в ответ заголовок:

Access-Control-Allow-Origin: *

* — разрешение запросов с любого домена

Но для безопасности лучше указать конкретный домен:

Access-Control-Allow-Origin: http://example.com

Решение 2: middleware CORS в Express.js

Если вы используете Node.js с Express, добавьте:

Браузер блокирует preflight-запросы (OPTIONS)

Сообщение об ошибке:

"CORS policy preflight request did not succeed" или что-то похожее.

Иногда перед настоящим запросом браузер сначала отправляет preflight-запрос методом OPTIONS, чтобы проверить, разрешен ли основной запрос. Это происходит, если:

• Метод запроса не GET или POST (например, PUT, DELETE).

• В заголовках есть что-то нестандартное (например, Authorization или Content-Type: application/json).

Если сервер не умеет обрабатывать OPTIONS — все ломается.

Решение: Обработать OPTIONS-запросы на сервере

Пример для Express.js:

app.options('*', cors()); // Разрешаем preflight-запросы

Или настройка CORS с поддержкой OPTIONS:

Запросы с учётом сессий (credentials) блокируются

Сообщение об ошибке:

"The value of the ‘Access-Control-Allow-Origin’ header in the response must not be '*' when the request's credentials mode is 'include'"

Вы отправляете запрос с куками или авторизацией (credentials: 'include'), но сервер разрешает доступ всем (Access-Control-Allow-Origin: *). Это запрещено — нельзя слать credentials, если разрешено всем.

Решение: Указать конкретный домен и разрешить credentials

На сервере также добавьте:

Access-Control-Allow-Credentials: true

Смешанные протоколы — HTTP и HTTPS

Сообщение об ошибке:

"Mixed content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'."

Ваш сайт работает по HTTPS, а API — по HTTP. Браузеры считают, что это опасно, и банально блокируют запросы.

Решение:

• Переведите API на HTTPS.
• Обновите все ссылки с http:// на https://.

• Если работаете локально и сервер только HTTP, используйте ngrok, чтобы создать HTTPS-туннель.

CORS блокирует редиректы

Сообщение об ошибке:

"Redirect from '...api' to '...login' has been blocked by CORS policy."

API делает редирект, но в ответе на редирект нет CORS-заголовков. Браузер не знает, можно ли доверять редиректу, и блокирует.

Решение:

Убедитесь, что редирект тоже возвращает правильные заголовки:

Access-Control-Allow-Origin: http://example.com

Если используете fetch, добавьте:

Неверно настроен Access-Control-Allow-Headers

Сообщение об ошибке:

"Request header field <X> is not allowed by Access-Control-Allow-Headers"

Ваш запрос содержит нестандартный заголовок (например, Authorization), а сервер не пропускает его.

Решение:

На сервере укажите, какие заголовки разрешены:

Метод запроса запрещён сервером

Сообщение об ошибке:

"Method PUT is not allowed by Access-Control-Allow-Methods"

Вы отправляете запрос методом PUT, PATCH, DELETE, а сервер разрешает только GET и POST.

Решение:

На сервере явно разрешите нужные методы:

Больше новостей в нашем тг-канале Представляешь

Как это происходило

Пользователь заходил на сайт с установленным Meta* Pixel или Яндекс.Метрикой, и в этот момент JavaScript-скрипт пытался установить соединение с приложением через локальные порты. Через WebRTC (в случае Meta*) или HTTP (в случае Яндекса) передавались cookies, Android Advertising ID и другие идентификаторы. Это позволяло деанонимизировать пользователя, даже если он не был авторизован, использовал режим инкогнито или регулярно очищал cookies. Сессии с разных сайтов можно было связать в одну, а история посещений становилась доступной для дальнейшего анализа.

Уязвимость заключалась в том, что другие приложения, установленные на том же устройстве, могли подключаться к тем же портам и перехватывать передаваемую информацию. Это нарушало не только пользовательскую приватность, но и фундаментальные ожидания безопасности, встроенные в браузеры. Chrome, Firefox и Edge оказались уязвимы, а Brave и DuckDuckGo блокировали такие попытки благодаря собственным механизмам защиты.

Методика отслеживания, по данным исследователей, действовала минимум с 2017 года. Meta использовала WebRTC STUN с ноября 2024-го, затем перешла на TURN в мае 2025-го. Только 3 июня компания полностью отключила отправку данных на localhost, удалив соответствующий код. Яндекс использовал HTTP-метод с 2017 года и перешёл на HTTPS в 2018-м. Трекинг через порты также подтверждён и со стороны Яндекса. Оба вендора не документировали эти механизмы, и пользователи не были о них информированы.

По информации BuiltWith, Meta* Pixel встроен на 5,8 миллиона сайтов, а Яндекс.Метрика — почти на 3 миллиона. При сканировании топ-100 000 доменов Meta* пыталась установить соединение с localhost более чем на 13 тысячах сайтов в США и почти на 12 тысячах в Европе. Яндекс зафиксирован на более чем 1000 сайтов в каждом из этих регионов.

Стало известно, что эти механизмы отслеживания работали даже без входа в учётные записи, при активном режиме инкогнито и при удалении всех cookie. Это делает обнаруженные схемы особенно тревожными — обходятся ключевые инструменты защиты приватности и поднимаются серьёзные вопросы о допустимости подобных практик.

* Компания Meta и её продукты признаны экстремистскими, их деятельность запрещена на территории РФ

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

Что такое SSL/TLS сертификат

Еще десять лет назад протокол HTTPS использовали преимущественно банки и платежные системы. Сегодня даже простейший блог без шифрования трафика вызывает предупреждения в браузерах и теряет доверие посетителей.

SSL/TLS сертификаты для каждого сайта выполняют три важные функции: обеспечивают шифрование данных, подтверждают подлинность сайта и гарантируют целостность передаваемой информации. Без них любая форма авторизации или даже обычная переписка становятся уязвимыми для перехвата. Особенно актуально это в эпоху публичных Wi-Fi сетей и сложных цепочек маршрутизации, когда трафик может проходить через десятки промежуточных узлов.

Технологии защиты постоянно развиваются. Если в 2010-х основным стандартом был TLS 1.2, то сейчас все больше ресурсов переходят на TLS 1.3 с его оптимизированным «рукопожатием» и отказом от устаревших алгоритмов. Параллельно ужесточаются требования поисковых систем — Google еще в 2018 году начал помечать HTTP-сайты как небезопасные, в 2025 году такие ресурсы практически не имеют шансов попасть в топ выдачи.

Но важность SSL/TLS выходит за рамки технических аспектов. Для пользователей значок замка в адресной строке стал визуальным маркером доверия. Исследования показывают, что около 85% посетителей сразу покидают сайт при появлении предупреждения о небезопасном соединении. В коммерческих проектах это напрямую влияет на конверсию и доходы.

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

Сертификат содержит несколько ключевых элементов:

• Публичный ключ — используется для шифрования данных, отправляемых на сервер.
• Данные владельца — информация о компании или физическом лице, которому выдан сертификат.
• Цифровую подпись центра сертификации (CA) — подтверждает, что документ был проверен и подписан доверенным удостоверяющим центром.
• Срок действия — обычно от нескольких месяцев до нескольких лет, после чего требуется обновление.

Выдачей SSL/TLS сертификатов занимаются центры сертификации (Certificate Authorities, CA). Это организации вроде DigiCert, Sectigo или Let’s Encrypt, чьи корневые сертификаты предустановлены в браузерах и операционных системах. Если CA подтверждает валидность домена и, при необходимости, проверяет юридические данные владельца, он выпускает сертификат, который браузеры распознают как доверенный.

Хотя аббревиатура SSL (Secure Sockets Layer) до сих пор широко используется, сам протокол считается устаревшим с 2015 года из-за уязвимостей. Его современная замена — TLS (Transport Layer Security), но термин «SSL-сертификат» остался в обиходе как дань традиции.

Без такого сертификата любая передача данных — будь то логины, платежные реквизиты или персональные сообщения — становится уязвимой для атак типа «человек посередине» (MITM). Современные браузеры активно борются с незащищенными соединениями: Chrome и Firefox, например, помечают сайты без HTTPS как «небезопасные», а с 2023 года некоторые из них и вовсе блокируют смешанный контент.

Интересно, что с 2024 года ряд CA начали внедрять сертификаты с укороченным сроком действия (менее 30 дней) для повышения безопасности. Это усложняет жизнь злоумышленникам, но и требует более гибкой инфраструктуры обновления у владельцев сайтов.

Проверить наличие сертификата можно, кликнув на значок замка в адресной строке — там будет указана информация о его издателе и уровне проверки. Но важно понимать: сам факт наличия SSL/TLS не делает сайт автоматически безопасным, он лишь обеспечивает шифрование канала передачи данных.

Как работает шифрование с SSL/TLS

Когда браузер устанавливает соединение с сайтом, защищенным SSL/TLS, происходит не просто обмен данными — запускается сложный криптографический механизм, обеспечивающий конфиденциальность и целостность информации.

В основе лежат два типа шифрования: асимметричное (для аутентификации и обмена ключами) и симметричное (для быстрой передачи данных).

Асимметричное шифрование используется на начальном этапе. Сервер обладает парой ключей: открытым (public key), который доступен всем, и закрытым (private key), хранящимся в секрете.

Когда браузер запрашивает защищенное соединение, сервер отправляет свой SSL-сертификат, содержащий публичный ключ. Браузер проверяет подлинность сертификата через центры сертификации (CA), встроенные в ОС или сам браузер. Если все в порядке, он генерирует временный симметричный ключ, шифрует его публичным ключом сервера и отправляет назад.

Здесь важно, что расшифровать этот ключ может только владелец закрытого ключа — то есть сам сервер. Так решается проблема безопасного обмена ключами без риска перехвата. Современные системы чаще всего используют алгоритмы вроде RSA (2048 или 4096 бит) или ECC (на основе эллиптических кривых), поскольку они обеспечивают достаточную стойкость при приемлемой скорости работы.

После обмена начинается фаза симметричного шифрования. Теперь обе стороны используют один и тот же ключ (например, AES-256 или ChaCha20), который применяется для кодирования всего трафика. Симметричные алгоритмы быстрее асимметричных, что критично для производительности — представьте, если бы каждый пакет данных шифровался RSA.

Процесс установки соединения (TLS handshake) занимает доли секунды, но включает несколько этапов:

1. Приветствие клиента (ClientHello) — браузер сообщает серверу, какие алгоритмы шифрования он поддерживает.
2. Приветствие сервера (ServerHello) — сервер выбирает наиболее безопасный из доступных вариантов и отправляет свой сертификат.
3. Проверка сертификата — браузер убеждается, что сертификат подписан доверенным CA и не просрочен.
4. Обмен ключами — как описано выше, создается симметричный ключ.
5. Завершение рукопожатия (handshake) — стороны подтверждают готовность к шифрованному обмену.

Весь процесс обеспечивает три ключевых аспекта безопасности: конфиденциальность (данные недоступны третьим лицам), целостность (информация не изменяется при передаче) и аутентификацию (уверенность в подлинности сайта).

С 2023 года большинство браузеров перешли на TLS 1.3 (выпущен в 2018), где процесс установки соединения оптимизирован — теперь он требует всего одного обмена данными вместо двух в TLS 1.2. Это не только ускоряет загрузку страниц, но и исключает уязвимости, связанные с устаревшими алгоритмами вроде SHA-1 или CBC-режимов.

Современные браузеры дополнительно проверяют сертификат на соответствие стандарту HSTS (HTTP Strict Transport Security), который запрещает незащищенные соединения. С 2024 года многие сайты используют механизм «ожидающего сертификата» (Certificate Transparency), позволяющий отслеживать неавторизованные выпуски.

Важный факт. Даже если злоумышленник перехватит зашифрованный трафик, без закрытого ключа расшифровать его будет практически невозможно. Например, взлом AES-256 методом полного перебора потребует времени, превышающего возраст Вселенной, — при условии, что ключ сгенерирован правильно.

Однако SSL/TLS — не панацея. Если на сервере неправильно настроены параметры (скажем, разрешен слабый алгоритм RC4), или приватный ключ скомпрометирован, защита рушится. Поэтому важно не только наличие сертификата, но и его корректная настройка. Проверить это можно через инструменты вроде SSL Labs Test — они анализируют параметры соединения и выявляют потенциальные уязвимости.

В итоге, когда вы вводите платежные данные или логин на сайте, SSL/TLS гарантирует, что информация дойдет до сервера в зашифрованном виде, а подлинность сервера подтверждена центром сертификации. Без этого интернет-платежи, авторизация в банках и даже мессенджеры были бы куда рискованнее..

Типы SSL/TLS сертификатов

Существует несколько разновидностей SSL/TLS сертификатов, отличающихся уровнем проверки и областью применения. Основное разделение происходит по степени верификации, которую проводит удостоверяющий центр перед выдачей документа.

Самый простой вариант — сертификаты с проверкой домена (DV). Они подтверждают только право владения доменным именем, без какой-либо информации о владельце. Получить такой сертификат можно автоматически — достаточно подтвердить контроль над доменом через email или DNS-запись. DV-сертификаты подходят для блогов, небольших сайтов и тестовых сред, где не требуется демонстрация юридического статуса организации.

Для коммерческих проектов чаще используют сертификаты с проверкой организации (OV). В этом случае центр сертификации проверяет официальные регистрационные данные компании — название, юридический адрес, право на использование домена. Процесс занимает 1-3 рабочих дня. В отличие от DV, информация о владельце включается в сертификат и доступна для просмотра в деталях соединения.

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

По охвату защищаемых доменов сертификаты делятся на несколько категорий:

• Стандартные (Single-name) работают только с одним конкретным доменным именем.
• Wildcard-сертификаты распространяются на основной домен и все его поддомены — удобное решение для сложных веб-приложений.
• Мультидоменные (SAN или MDC) позволяют защитить несколько независимых доменов одним сертификатом — оптимальный выбор для компаний с разветвленной структурой онлайн-ресурсов.

Отдельно стоит отметить бесплатные сертификаты, которые предлагают такие организации как Let’s Encrypt. Они относятся к категории DV и выдаются на короткий срок (обычно 90 дней), что требует автоматического продления. Хотя по уровню шифрования они не уступают платным аналогам, отсутствие информации о владельце делает их непригодными для коммерческих проектов.

Выбор конкретного типа зависит от задач проекта. Информационному порталу достаточно DV, интернет-магазину среднего размера — OV, финансовой организации — EV. Главное помнить: сам по себе сертификат не делает сайт безопасным, а лишь обеспечивает защиту передаваемых данных. Дополнительные меры вроде регулярного аудита кода и защиты от DDoS-атак остаются ответственностью владельца ресурса.

Почему важно использовать SSL/TLS

В современном интернете SSL/TLS сертификаты перестали быть опциональной функцией — они стали обязательным стандартом безопасности. Причин для их использования несколько, и каждая касается как технических аспектов, так и взаимодействия с пользователями:

Защита данных

Прежде всего, SSL/TLS защищает передаваемые данные от перехвата. Без шифрования злоумышленник, получивший доступ к сетевому трафику (например, через публичную Wi-Fi сеть), может просматривать логины, пароли, банковские реквизиты и другую конфиденциальную информацию.

Протокол TLS исключает такую возможность, преобразуя данные в криптографически стойкий формат, который невозможно расшифровать без специального ключа. Особенно это актуально для MitM-атак (Man-in-the-Middle), где злоумышленник пытается вклиниться в соединение между клиентом и сервером.

Фактор SEO

Поисковые системы давно учитывают наличие HTTPS как фактор ранжирования. Google еще в 2014 году объявил, что защищенные соединения получают небольшой, но значимый приоритет в выдаче.

Сейчас это требование стало еще строже — сайты без SSL/TLS практически не имеют шансов попасть в топ поисковой выдачи. Более того, некоторые функции современных веб-API (например, геолокация или доступ к камере) в браузерах по умолчанию блокируются для незащищенных HTTP-соединений.

Обязательные требования

Технические стандарты также диктуют свои условия. PCI DSS (требования безопасности для работы с платежными картами) прямо предписывают использование TLS не ниже версии 1.2 для всех операций с финансовыми данными. Аналогичные нормы есть в GDPR и других регуляторных документах — отсутствие шифрования может стать основанием для штрафов и юридических последствий.

Интересно, что SSL/TLS важен не только для внешних, но и для внутренних сервисов. В 2025 году это стало особенно актуально с ростом числа удаленных сотрудников и облачных сервисов.

Важно понимать: SSL/TLS — не просто «галочка» для браузера или SEO. Это базовая технология, обеспечивающая конфиденциальность, целостность данных и аутентификацию сервера. При этом современные решения вроде Let’s Encrypt или автоматического продления сертификатов в панелях хостинга свели сложность внедрения к минимуму — сегодня нет рациональных причин отказываться от HTTPS.

Как получить и установить сертификат

Процесс получения SSL/TLS сертификата начинается с выбора типа защиты, соответствующего потребностям вашего проекта. Для личных блогов и небольших сайтов оптимальным решением станут бесплатные варианты от Let’s Encrypt — они обеспечивают базовое шифрование без сложных процедур верификации.

Коммерческим проектам потребуются платные сертификаты с проверкой организации (OV) или расширенной проверкой (EV), особенно если работа связана с обработкой платежей или персональных данных.

Порядок действий при заказе платного сертификата выглядит следующим образом:

1. Необходимо сгенерировать запрос на выпуск (CSR) через панель управления хостингом или используя OpenSSL. В запросе указываются данные о домене и организации.
2. CSR отправляется в выбранный центр сертификации вместе с документами, подтверждающими право владения доменом и юридический статус компании. Для DV-сертификатов проверка ограничивается подтверждением домена, тогда как EV требует предоставления учредительных документов и может занимать несколько рабочих дней.
3. После проверки центр сертификации выдает файлы самого сертификата и цепочки доверия (CA bundle).
4. Эти файлы необходимо загрузить на сервер через административную панель хостинга или вручную, прописав соответствующие директивы в конфигурации веб-сервера. Для Nginx потребуется указать пути к файлам сертификата и приватному ключу в блоке server, а в Apache — использовать директивы SSLCertificateFile и SSLCertificateKeyFile.

Особое внимание стоит уделить автоматическому продлению. Большинство современных центров сертификации, включая Let’s Encrypt, выдают сертификаты на ограниченный срок (обычно 90 дней). Для автоматического обновления можно использовать Certbot или встроенные инструменты панелей управления типа cPanel. Они самостоятельно проверяют срок действия и обновляют сертификаты без вмешательства администратора.

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

После установки обязательно проверьте корректность работы через онлайн-инструменты вроде SSL Labs Test. Они покажут не только правильность цепочки доверия, но и выявят потенциальные уязвимости в настройках. Особенно важно проверить поддержку актуальных версий TLS (1.2 и выше) и отключить устаревшие алгоритмы шифрования, которые могут снижать уровень безопасности.

Как проверить корректность SSL/TLS

После установки сертификата важно убедиться в его правильной работе. Самый простой способ — обратить внимание на адресную строку браузера. Закрытый замок и пометка «Безопасное соединение» свидетельствуют о корректной настройке. Однако для профессиональной проверки потребуются специальные инструменты.

Онлайн-сервисы вроде SSL Labs предоставляют детальный анализ конфигурации. Достаточно ввести адрес сайта, и система проверит не только срок действия сертификата, но и поддерживаемые версии протоколов, алгоритмы шифрования, правильность цепочки доверия. Результат отображается в виде оценки от A+ до F, где низкие баллы указывают на критические уязвимости.

Частая проблема — несоответствие имени в сертификате и фактического домена (mismatch). Это происходит при использовании одного сертификата для нескольких ресурсов или ошибках в настройках. Браузеры жестко реагируют на такой сценарий, блокируя доступ или выводя предупреждения. Проверить соответствие можно через консоль разработчика во вкладке «Безопасность».

Срок действия — еще один важный параметр. Просроченные сертификаты (expired) вызывают предупреждения в браузерах и могут полностью заблокировать доступ к сайту. Современные системы мониторинга, такие как Uptime Robot, позволяют настроить уведомления об истечении срока заранее.

Самоподписанные сертификаты (self-signed) — особая категория. Они не проверяются центрами сертификации, поэтому браузеры не доверяют таким соединениям. Проверить подпись можно через командную строку с помощью openssl x509 -text -noout -in сертификат.crt.

Для комплексной проверки стоит обратить внимание на несколько аспектов:

1. Корректность цепочки сертификатов — промежуточные звенья должны быть правильно установлены на сервере.
2. Поддержку актуальных версий TLS (1.2 и выше) при отключении устаревших протоколов вроде SSLv3.
3. Настройку перенаправления с HTTP на HTTPS без смешанного содержимого.

Мифы и заблуждения о сертификатах

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

Сертификаты дают 100% защиты

Один из самых живучих мифов — убеждение, что наличие сертификата делает ресурс полностью защищенным. На самом деле, SSL/TLS обеспечивает лишь безопасность передачи данных между клиентом и сервером.

Это не панацея от SQL-инъекций, XSS-атак или других уязвимостей веб-приложений. Сертификат не заменяет необходимость регулярного аудита кода, обновления ПО и других мер безопасности.

Сертификаты снижают производительность

Распространено заблуждение о сильном влиянии шифрования на производительность. Современные протоколы, особенно TLS 1.3, оптимизированы настолько, что разница в скорости между защищенным и незащищенным соединением практически незаметна.

Более того, HTTP/2 и HTTP/3, требующие обязательного использования TLS, часто работают быстрее незашифрованных соединений за счет более эффективных механизмов передачи данных.

Платные сертификаты лучше

Некоторые уверены, что бесплатные сертификаты менее надежны, чем платные. На самом деле, решения вроде Let’s Encrypt используют те же криптографические алгоритмы, что и коммерческие альтернативы. Разница лишь в уровне проверки владельца и сроке действия — технически уровень шифрования идентичен.

Сертификаты обеспечивают долговременную защиту

Отдельно стоит миф о «вечной» защите после установки. Сертификаты имеют ограниченный срок действия не просто так — это важный элемент безопасности. Кроме того, криптографические стандарты постоянно развиваются: алгоритмы, считавшиеся надежными пять лет назад, сегодня могут быть уязвимы. Регулярное обновление сертификатов и параметров шифрования обязательно для поддержания реальной защиты.

Сертификаты нужны не всем

Еще одно ошибочное мнение — что SSL/TLS нужен только сайтам с формами ввода. Современные браузеры помечают все HTTP-страницы как небезопасные, независимо от их содержания. Более того, многие функции (геолокация, push-уведомления) в Chrome и других браузерах заблокированы для незащищенных соединений.

Это сложно

Наконец, существует миф о сложности установки и обслуживания. Современные хостинг-провайдеры и панели управления предлагают автоматизированные решения, где получение и обновление сертификата занимает несколько кликов. Даже ручная настройка через Let’s Encrypt и Certbot перестала быть сложной задачей благодаря подробной документации.

Разобравшись с этими заблуждениями, проще принимать взвешенные решения о защите сайтов. SSL/TLS — важный, но не единственный элемент безопасности, который нужно рассматривать в комплексе с другими мерами защиты данных.

Частые проблемы и уязвимости

Даже правильно настроенные SSL/TLS сертификаты могут стать источником проблем, если не учитывать ключевые аспекты их работы. Одна из самых распространенных ситуаций — истекший срок действия.

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

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

Устаревшие протоколы и алгоритмы представляют отдельную угрозу. Поддержка TLS 1.0 и 1.1, сохраняемая для совместимости со старыми системами, создает бреши в безопасности. Эти версии содержат известные уязвимости (BEAST, POODLE), позволяющие злоумышленникам частично расшифровывать трафик. Современные стандарты требуют отключения этих протоколов и использования TLS 1.2 или 1.3 с устойчивыми алгоритмами вроде AES-GCM и ChaCha20-Poly1305.

Особая категория проблем связана с доверенными центрами сертификации. Система предполагает, что все браузеры и операционные системы доверяют определенному набору корневых сертификатов. Однако известны случаи, когда центры сертификации выдавали документы мошенникам или становились жертвами взлома. Например, инцидент с DigiNotar в 2011 году привел к компрометации сотен сертификатов, включая ресурсы спецслужб.

Технические уязвимости в реализации протоколов тоже заслуживают внимания. Атака Heartbleed (2014), пользуясь ошибкой в OpenSSL, позволяла читать память сервера, включая приватные ключи. Уязвимости в криптографических библиотеках (ROBOT, DROWN) демонстрируют, что даже правильно настроенное шифрование может оказаться под угрозой из-за фундаментальных проблем в коде.

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

Важно не только правильно настраивать сертификаты, но и регулярно проверять их состояние, отслеживать отзыв списков (CRL) и обновлять конфигурацию сервера в соответствии с актуальными рекомендациями. Инструменты мониторинга вроде SSL Pulse помогают отслеживать общую ситуацию с безопасностью в интернете и вовремя реагировать на новые угрозы.

Безопасность безопасностью, но как писать код, который не стыдно показывать? Всё для фронтендеров и бэкендеров в одном месте.

Вместо него Chrome полностью переходит на Manifest V3, который серьезно ограничивает функциональность таких расширений, как uBlock Origin и другие блокировщики.

Почему это важно

Manifest V2 — основа, на которой работали самые эффективные средства блокировки рекламы. С его отключением расширения вроде uBlock Origin потеряют доступ к мощным средствам фильтрации.

В версии V3 у расширений нет возможности полноценно перехватывать сетевые запросы — вместо этого используется declarativeNetRequest, который ограничивает количество фильтров и не позволяет гибко обрабатывать правила.

Авторы uBlock Origin уже подтвердили, что расширение не может быть полноценно перенесено на V3. Это означает, что миллионы пользователей Chrome больше не смогут использовать проверенные способы блокировки рекламы — в том числе для ускорения загрузки страниц, экономии трафика и защиты от трекеров.

Как реагирует сообщество

На Reddit новость вызвала бурную реакцию. Пользователи считают решение Google попыткой заблокировать конкурентов своему рекламному бизнесу:

«Это не апгрейд — это деградация»

«Чувствую, как у меня отнимают свободу»

Некоторые ожидают, что браузеры на базе Chromium (например, Brave или Vivaldi) могут отказаться от Manifest V3 или форкнуть проект. Но большинство признает: против Google с его 60% рынка мало кто может пойти.

Что делать пользователям

Тем, кто хочет сохранить возможность блокировать рекламу, придется либо:

• перейти на Firefox, который по-прежнему поддерживает Manifest V2 и полноценные блокировщики;
• использовать сторонние приложения для фильтрации рекламы на уровне системы;
• смириться с потерей функциональности в Chrome.

Почему Google это делает

Формально Google заявляет, что цель Manifest V3 — повысить безопасность и стабильность браузера. Однако эксперты и правозащитные организации, такие как EFF, уверены: дело в деньгах. Ограничив возможности блокировщиков, компания защищает свои рекламные доходы.

Сейчас против Google уже идет антимонопольное расследование Минюста США. Некоторые надеются, что под давлением регуляторов компания может пересмотреть свои решения — но таких прецедентов пока не было.

Это первый «агентный» браузер компании: он не просто отображает сайты, а сам бронирует отели, заполняет формы и даже может создать веб-приложение с нуля.

Три части: Chat, Do и Make

Neon состоит из трех компонентов:

• Neon Chat — встроенный чат-бот, как Copilot или ChatGPT. Он может найти нужную информацию, объяснить, что происходит на странице или предложить действия.
• Neon Do — продолжение идеи «Browser Operator». Этот модуль анализирует содержимое сайта и сам выполняет действия: бронирует поездки, делает покупки, вводит данные — все это работает локально, без отправки данных в облако.
• Neon Make — самое необычное. Он выполняет сложные задачи в облаке: может создать сайт, игру, отчет или даже хостить готовый проект. Причем без необходимости писать код — достаточно описать идею.

Больше, чем просто ИИ-помощник

Opera уверяет: Neon не просто копирует чат-ботов, он по-настоящему понимает структуру сайтов — работает с DOM-деревом и данными о разметке, а не с пикселями, как это делают некоторые другие решения. Благодаря этому Neon и быстрее, и приватнее аналогов.

Платная модель и ранний доступ

Из трех модулей, только Neon Make будет платным. Пока Opera открыла лист ожидания для ранних пользователей — подробности и цены компания пообещала раскрыть позже.

Это была эпоха, когда «выйти в сеть» означало посвятить этому весь вечер: отключить телефон, запустить модем и надеяться, чтобы соединение не оборвалось на 99% загрузки. Пользовались сетью далеко не все — это было привилегией, доступной единицам.

Но именно эти ограничения сделали нас изобретательными. Мы сохраняли страницы на диск, читали письма и тексты офлайн, чтобы не тратить драгоценные минуты, и знали наизусть коды доступа вроде *17#. Если бы переместились из того времени в сейчас, мы бы посчитали возможности современной сети волшебной халявой. Интернет 2000-х не только развлекал — он закалял. О том, как это происходило на практике, читайте в нашем материале.

Интернет 2000: как это было

В 2000 году интернет в России был скорее экзотикой, чем повседневностью. По данным исследования ФОМ, лишь 3,6% населения пользовались им регулярно, а каждый пятый вообще не знал о его существовании. Для большинства это была загадочная «всемирная паутина», о которой слышали, но вряд ли юзали на практике.

Те, кому посчастливилось подключиться, делали это с помощью технологии dial-up — медленной, капризной и дорогой. Стандартная скорость в 56 кбит/с означала, что загрузка чего-либо весом больше, чем страница в браузере, будет длительным и проблематичным мероприятием. Провайдеры предлагали помегабайтную тарификацию, и необдуманный клик по баннеру мог стоить половины дневного бюджета.

Покупка домена или хостинга была уделом избранных: например, регистрация в зоне.ru обходилась в $50 (по курсу 2000 года — около 1500 рублей), а размещение сайта на виртуальном сервере — еще дороже. При этом в Рунете насчитывалось не так много активных сайтов — в миллионы раз меньше, чем сегодня.

В эпоху dial-up развлекательные порталы становились культовыми, несмотря на вопиющее отсутствие юзабилити. Anekdot.ru, udaff.com с его знаменитой «Нетленкой», Krovatka собирали тысячи посетителей, хотя сегодня их дизайн вызывает недоумение: мигающие баннеры, неоновые шрифты и коллажи из голливудских хитов. Особое место занимал «албанский язык» с его «преведом» и «аффтаром» — это была эпоха, когда контент ценился выше формы, а вырвиглазные цветовые схемы считались нормой.

Интересно, что даже среди пользователей мало кто воспринимал интернет как коммерческое пространство: покупки онлайн как таковые были недоступны. Основными точками входа были интернет-кафе и компьютерные клубы, где час онлайн-сеанса стоил 30–50 рублей.

Домашним подключением пользовались редко: абонентская плата в $20–30 при средней зарплате в 3000 рублей делала его недоступным для многих. Чтобы «выйти в интернет», нужно было не только заплатить внушительную сумму, но и проделать ряд ритуальных действий.

К счастью, с каждым годом с начала 2000-х, ситуация становилась все лучше (прогресс все-таки). Для сравнения: к 2015 году, по данным того же ФОМ, интернетом пользовались уже 66% россиян. Но в 2000-м он был территорией первопроходцев — тех, кто готов был мириться с обрывами связи, долгим ожиданием загрузки и бесконечными настройками модема.

Подключение — только для избранных

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

Телефонная линия как провод в цифровой мир

Эпоха dial-up началась с характерного звукового сопровождения — многотонального «пения» модема, пытающегося установить соединение. Этот звук, напоминающий треки экспериментальной электроники, стал настоящим символом нового времени. Процесс подключения занимал от 30 секунд до нескольких минут, причем успешное соединение с первого раза было скорее исключением, чем правилом.

Телефонная линия становилась полностью занятой во время интернет-сессии. В семьях это порождало конфликты: пока один член семьи «сидел в интернете», другие не могли позвонить по телефону. Особенно остро проблема стояла вечером, когда одни хотели поболтать с друзьями, другие — проверить почту. Некоторые пользователи применяли хитрости вроде кода *43# для отключения ожидания линии, но это работало не на всех АТС.

Модемы выглядели примерно так:

Странные звуки, которые сопровождали процесс — результат трансформации цифрового сигнала в аналоговый и обратно.

Продвинутая версия:

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

Интересный факт: некоторые провайдеры предлагали «ночные тарифы» с 01:00 до 07:00 по сниженной цене. Именно в это время наиболее активны были закачки через DC++ и первые версии µTorrent.

ADSL — революция, но не для всех

Появление технологии ADSL в середине 2000-х казалось настоящим прорывом. Теперь можно было одновременно говорить по телефону и пользоваться интернетом. Однако реальность оказалась сложнее ожиданий.

Главным ограничением стало расстояние до телефонной станции. При удалении более 3-4 км скорость соединения падала в разы. Провайдеры ввели градацию тарифов: чем дальше от АТС, тем дороже обходился одинаковый по скорости доступ. В некоторых случаях абонентам вообще отказывали в подключении, ссылаясь на «плохое качество линии».

Первые «безлимитные» тарифы появились именно в эпоху ADSL, но слово «безлимитный» приходится брать в кавычки.

Обычно провайдеры устанавливали:

• ограничение на скорость после достижения определенного объема трафика (5-10 ГБ в месяц);
• полную блокировку P2P-сетей в дневное время;
• ночной безлимит только в определенные часы (чаще с 01:00 до 07:00).

Стоимость таких тарифов колебалась от 800 до 1500 рублей в месяц, что для многих оставалось неподъемной суммой. При этом реальная скорость редко превышала 1-2 Мбит/с даже по самым дорогим тарифам.

Кабельный интернет и локальные провайдеры

Параллельно с ADSL развивалось кабельное подключение через коаксиальные сети и FTTB. В каждом районе появлялись мелкие провайдеры, которые предлагали «стабильный высокоскоростной интернет» за 500-700 рублей в месяц. Реальность часто отличалась от обещаний: оборудование перегревалось, кабели повреждались, а техподдержка работала по принципу «все починим, когда будет время».

Многие локальные провайдеры исчезали так же внезапно, как появлялись. Типичный сценарий: компания собирала предоплату за несколько месяцев, после чего ее офис закрывался, а телефоны переставали отвечать. Особенно страдали жители новостроек, где конкуренция между провайдерами была наиболее жесткой.

В ответ на это пользователи создавали собственные «пиратские» сети. В спальных районах энтузиасты организовывали раздачу интернета через свитч, подключенный к одному выделенному каналу. Скорость делилась на всех участников, зато стоимость получалась в 2-3 раза ниже официальных тарифов. Такие схемы работали до первых жалоб в Роскомнадзор или до момента, когда кто-то начинал злоупотреблять торрентами.

Интернет по карточкам: эпоха предоплаты

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

Принцип работы был прост:

1. Покупаешь карту номиналом 5, 10, 20 или 50 часов.
2. Стираешь защитный слой, чтобы увидеть логин и пароль.
3. Вводишь данные в программе дозвона.
4. Таймер начинает отсчет оплаченного времени.

Средняя стоимость часа по карточкам составляла все те же 30-50 рублей. Некоторые провайдеры предлагали «бонусные» тарифы: ночные часы по сниженной цене или дополнительные минуты при покупке карт большого номинала.

Согласно городским легендам, можно было отыскать точку со скоростным интернетом (например, университет с выделенной линией), открыть сразу 3-4 окна браузера для активации, быстро ввести в каждом данные и получить по одной карточке сразу несколько лимитов. Но такие подключения если и работали, то провайдеры быстро пресекали обман.

Тарифы, скорость, сервис

В эпоху, когда гигабайты и мегабиты стали чем-то обыденным, трудно представить, что всего 20 лет назад каждый байт интернет-трафика приходилось буквально выгрызать зубами. Это было время, когда подключение к сети требовало не только технических навыков, но и разработки оптимальной финансовой стратегии.

Тарифы: цифровая экономика во времена dial-up

Помегабайтная тарификация превращала интернет-серфинг в игру с высокими ставками. В 2001 году средняя стоимость 1 МБ трафика в Москве составляла 6-8 рублей (при курсе доллара около 29 рублей). Для сравнения: литр бензина АИ-92 тогда стоил 7 рублей. Скачивание одного MP3-файла (около 4 МБ) обходилось в 24-32 рубля — цена нескольких обедов в студенческой столовой.

Особенно болезненной была плата за входящий трафик. Некоторые провайдеры (например, «МТУ-Интел») брали 5 рублей за каждый полученный мегабайт. Открытие сайта с десятком картинок могло «съесть» 50-70 рублей.

Первые «безлимитные» тарифы появились лишь в 2004-2005 годах. Компания «Корбина Телеком» предлагала ночной безлимит за 990 рублей/месяц, но с важными оговорками:

• действовал только с 1:00 до 7:00;
• максимальная скорость — 128 кбит/с;
• запрещалось использовать файлообменные сети.

Договоры с провайдерами отличались любопытными ограничениями. Так, «Стек» в 2003 году прямо запрещал использование прокси, запуск любых серверных приложений и одновременное подключение более одного устройства.

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

В целом среднестатистический россиянин с зарплатой 3000 рублей мог в месяц приобрести себе 50 часов сети днем и 100 часов ночью при условии, что он не будет покупать продукты, одежду и платить за коммунальные услуги.

Скорость: искусство ожидания

В 2000-м средняя скорость передачи данных составляла от 32 до 128 Кбит/с. ADSL-подключение на 256 кбит/с, появившееся в 2004 году, казалось чудом техники. Для загрузки фильма в формате DivX (700 МБ) требовалось около 6 часов непрерывного соединения.

Пользователи разработали целые ритуалы для сохранения закачек:

• отключение всех автоматических обновлений;
• использование менеджеров закачек с докачкой (например, ReGet);
• охлаждение модема с помощью вентиляторов (на всякий случай).

Особой популярностью пользовались ночные закачки. Многие провайдеры (как «Ситилайн» в Москве) предлагали бесплатный трафик с 2:00 до 7:00.

Энтузиасты составляли графики:

• 23:00 — запуск µTorrent
• 01:30 — проверка соединения
• 05:00 — установка будильника для перезапуска упавших закачек

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

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

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

Для удовлетворения духовных потребностей в виде кино, музыки, текстового контента нужно было потратить немало сил и средств. Молодые люди, родившиеся после 2000 года, даже не представляют, каково это. Для них просмотр фильма и прослушивание любого музыкального трека — это пара кликов. Причем сделать это можно в любом месте и в любое время, имея под рукой мобильное устройство в виде смартфона или планшета.

Техподдержка: школа терпения

Службы поддержки работали по принципу «терпение и еще раз терпение». Среднее время ожидания ответа в 2003-2005 годах составляло 40-60 минут. Типичный диалог выглядел так:

— У меня третий день не открываются страницы.

— Вы пробовали очистить кэш DNS?

— Да, и три разных браузера пробовал.

— Наверное, у вас вирус. Установите антивирус Касперского.

— Но у всех в подъезде та же проблема!

— Это разные случаи. Ваш тарифный план…

Мифы о «ночном интернете» имели техническое обоснование. Многие провайдеры действительно отключали системы DPI (глубокого анализа трафика) после 00:00, перераспределяли каналы в пользу домашних пользователей, перезагружали перегретое оборудование.

Особой «любовью» пользовались фразы операторов:

• «У нас на стороне все работает» (при массовом отключении).
• «Попробуйте другой браузер» (при проблемах с PPPoE).
• «Это особенности вашей операционной системы» (в 90% случаев).

Каким был интернет 2000-х: цифровая археология медленных соединений

В 2003 году при подключении к интернету через dial-up загрузка главной страницы Яндекса могла занять 5-10 минут. Это было время, когда каждый байт трафика имел ценность, а ожидание становилось неотъемлемой частью цифрового опыта.

Что значит «медленный» на самом деле

Скорость в 33.6 кбит/с — стандарт для dial-up соединения — означала, что загрузка одной песни в MP3 (около 4 МБ) занимала около 15 минут непрерывного соединения. При помегабайтной тарификации (5-7 руб/МБ) это стоило как две поездки на метро.

Типичные сценарии использования:

• открытие почты Mail.ru: 2-3 минуты ожидания;
• загрузка трекера ICQ: 45 секунд;
• загрузка простой веб-страницы: 30-40 секунд.

На скачивание демоверсии игры (какой-нибудь «Heroes of Might and Magic III») можно было потратить несколько ночей подряд, поскольку соединение нередко обрывалось на 80% загрузки. Фильм в формате DivX (700 МБ) мог качаться с торрента несколько суток.

Оптимизация всего: война за каждый килобайт

Многие пользователи регулярно отключали загрузку изображений в браузерах. В ходу были радикальные методы:

• текстовые браузеры вроде Lynx — для чтения новостей на Gazeta.ru и других сайтах;
• ручная правка hosts-файла для блокировки рекламных серверов;
• специальные сборки с вырезанным Flash и Java.

Популярность ICQ (в народе — «аськи») объяснялась не только культурными причинами. Технически она была идеальна для медленных соединений:

• клиент весил менее 1 МБ;
• одно сообщение — около 100 байт;
• работала даже через прокси-сервер.

Характерное «у-у » при получении сообщения до сих пор вызывает ностальгию у тех, кто проводил множество часов под эти звуки. Есть версия, что этот сигнал каким-то образом воздействовал на мозг, сбивая внутреннее ощущение времени. В итоге пользователь мог не заметить, что провел в мессенджере всю ночь, и ему уже пора идти на учебу или на работу.

Культура ожидания: цифровой аскетизм

Музыка скачивалась по трекам не из жадности, а по необходимости. Альбом (60-80 МБ) при помегабайтной тарификации мог обойтись в 300-400 рублей — почти дневная зарплата. Поэтому юзеры искали треки на файлообменниках типа Napster, Soulseek, Gnutella, качали ночью (когда тарифы дешевле).

Фильмы в формате DivX (700 МБ) загружались по частям несколько дней. Распространенной практикой было:

• разбивать файл на части архиватором RAR;
• качать ночами через Download Master;
• склеивать через HJ-Split (программка для объединения и разделения файлов).

Пиратство стало вынужденной мерой — легальные альтернативы либо отсутствовали, либо стоили неподъемных денег. Лицензионный диск с игрой мог стоить треть зарплаты. Поэтому пиратство процветало — на диски записывали не только игры, но и взломанный софт.

Сайты и браузеры

Сегодня нам кажется, что в браузерах всегда были вкладки, но это не так. В Internet Explorer такая функция появилась только в 2006. Те 40 вкладок, которые сейчас открыты на вашем компе, в начале 2000-х были бы отдельными окнами.

Правда, тогда никто бы не стал открывать столько окон сразу — на это просто не хватило ресурсов интернета. Более того, браузеры не были бесплатными по умолчанию — за них либо платили, либо (что было гораздо чаще) пользовались взломанными версиями.

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

Сайты 2000-х отличались дизайном с фоновыми GIF-анимациями («падающий снег», «звездное небо»), счетчиками посещений («Ваш визит № 1245»), разделом «Мои друзья» со ссылками. Вместо комментариев были гостевые книги. И кнопки навигации в каждом углу.

Поисковики вроде Rambler и Aport выдавали в топе не релевантные сайты, а ресурсы с примитивным SEO (часто это был откровенный спам). Пользователи записывали адреса ресурсов на бумагу или сохраняли в «Избранное» (закладки синхронизации еще не изобрели).

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

Итоги

Опыт 2000-х научил нас ценить то, что сегодня кажется обыденным. Современные 100 Мбит/с — это не просто скорость, а результат эволюции, которую прошли те, кто помнит звук подключения модема и помегабайтную тарификацию.

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

Спасибо тому медленному, капризному, но такому важному интернету — без него мы бы не стали теми, кто сегодня с легкостью осваивает новые технологии, помня, с чего все начиналось.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Рассмотрим, в чем особенность пушей и почему командам стоит к ним присмотреться.

Почему сначала пуши, а потом СМСки

Казалось бы, мы уже настолько привыкли к пушам из приложений, что СМСки кажутся прошлым веком. Однако многие компании продолжают ими пользоваться — это в какой-то степени логично, поскольку не все устанавливают приложения. Но часто бывает и такое, что бизнес в принципе не стал внедрять подобную функцию.

А зря: во-первых, СМС — всегда сильная зависимость от оператора связи. Пуши же — более гибкая опция, поскольку при их отправке используются ваши собственные каналы связи. Плюс стоимость отправки push-уведомлений значительно ниже, чем у СМС, при этом данные шифруются, а значит, злоумышленники не смогут украсть важные коды.

После 2022 года выбор сервисов для push-уведомлений стал сложнее из-за санкций. Долгое время компании пользовались и по инерции продолжают пользоваться сервисом Firebase Cloud Messaging от Google, но сейчас этот канал не может быть единственным для отправки push, так как могут возникнуть определенные санкционные риски и для бизнеса, а также другие проблемы:

• Одноразовые коды и другие уведомления — чувствительная информация. Зарубежные сервисы передают данные за пределы России, что может быть рискованно.
• Условно-бесплатные аналоги, такие как FCM, не гарантируют доставку и не предоставляют аналитику.
• Некоторые сервисы вовсе заблокированы в России, а другие не работают в Китае, где многие сейчас ведут бизнес.

Как работают push-уведомления: техническая основа

Push-уведомления основаны на клиент-серверной архитектуре, где сервер отправляет данные на устройство через специализированные сервисы. Процесс начинается с регистрации: при запуске приложения устройство генерирует токен (device token) и отправляет его на сервер разработчика. Этот токен используется для маршрутизации сообщений.

Доставка происходит через платформо-зависимые сервисы:

• APNs (Apple Push Notification service): Для iOS и macOS, требует сертификата от Apple и поддерживает богатые уведомления с изображениями и действиями.
• FCM (Firebase Cloud Messaging): Для Android, кросс-платформенный сервис от Google, интегрируется с другими каналами.
• HPK (Huawei Push Kit): Альтернатива для устройств Huawei, особенно актуальна в регионах без Google Services.
• RuStore и Aurora: Российские аналоги для Android, ориентированные на локальный рынок и совместимые с санкционными ограничениями.

Для веб-приложений используются Web Push Notifications на базе Service Workers и протокола Push API, совместимого с браузерами Chrome, Firefox и Edge. Сообщения шифруются с помощью VAPID (Voluntary Application Server Identification) для аутентификации отправителя.

Модель Pub/Sub (Publish/Subscribe) лежит в основе масштабируемых систем: издатели публикуют сообщения в топики, а подписчики (устройства) получают их асинхронно. Это позволяет обрабатывать миллионы подключений без перегрузок. WebSocket или long-polling обеспечивают постоянное соединение для минимальной задержки – часто менее 0,1 секунды.

Вызовы включают:

• Оффлайн-доставку: Если устройство выключено или без интернета, сообщение может потеряться; ретраи (повторные попытки) и каскадирование (переключение на альтернативные каналы) решают эту проблему.
• Географические ограничения: Сервисы вроде FCM могут блокироваться в некоторых странах, требуя омниканальных подходов.
• Безопасность: Уведомления с чувствительными данными (коды аутентификации) нуждаются в end-to-end шифровании, чтобы предотвратить перехват.
• Пользовательский контроль: Пользователи могут отключать пуши, поэтому важно соблюдать регуляции вроде GDPR или 152-ФЗ, избегая спама.

Преимущества пушей над SMS: низкая стоимость (почти нулевая для больших объемов), мгновенная доставка, поддержка мультимедиа (изображения, кнопки действий) и аналитика (открытия, клики).

Омниканальность и лучшие практики внедрения

Омниканальные системы объединяют несколько каналов в единую платформу, обеспечивая доставку независимо от устройства или региона. Это включает каскад: если основной канал (например, собственный WebSocket) недоступен, система переключается на FCM или APNs. Такие подходы достигают 99,9% доставки, с ретраями и мониторингом.

При выборе системы учитывайте:

• Масштабируемость: Поддержка высоких нагрузок, как во время пиковых событий (распродажи, новости).
• Аналитика: Реал-тайм отчеты о доставке, конверсии и отказах для оптимизации кампаний.
• Кастомизация: Deeplink для перехода в конкретный раздел приложения, добавление изображений, ссылок или персонализированного контента.
• Интеграция: REST API и SDK для популярных фреймворков (React Native, Flutter), чтобы внедрение заняло минимум времени.
• Соответствие регуляциям: Локализация данных, сертификаты безопасности (PCI DSS, ФСТЭК) для работы с финансовыми или государственными данными.

Лучшие практики: сегментируйте аудиторию по поведению, тестируйте A/B-варианты сообщений, интегрируйте с CRM для персонализации. Для бизнеса в e-commerce пуши идеальны для напоминаний о корзине, в банках – для транзакций, в медиа – для новостей.

MULTIPUSHED как пример омниканальной платформы

В качестве примера рассмотрим российскую систему MULTIPUSHED от МУЛЬТИФАКТОР, ориентированную на доставку уведомлений в условиях санкций и локальных требований. Она использует SaaS-модель с инфраструктурой в дата-центрах Tier3 (DataLine, Selectel, LinxCloud), защищенной от DDoS через NGENIX.

Архитектура включает Pub для приема сообщений по HTTPS API, Broker для распределения и Router для маршрутизации по каналам: собственный PUSHED, APNs, FCM, HPK, RuStore, Aurora. Sub-серверы поддерживают WebSocket Secure для онлайн-доставки, с каскадированием для оффлайн-случаев.

Процесс: устройство регистрируется, получает токен; отправитель передает сообщение Pub; система маршрутизирует и подтверждает доставку. Совместима с iOS, Android, Aurora, РОСА МОБАЙЛ, KasperskyOS и веб. SDK для Android, iOS, React Native, Flutter, Aurora и Web упрощают интеграцию.

Функции: аналитика в реальном времени, кастомизация (deeplink, изображения), глобальная доставка (включая Китай и регионы РФ). Сообщения шифруются, соответствует 152-ФЗ и PCI DSS, внесена в реестр российского ПО.

Итоговые рекомендации

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

При внедрении тестируйте на реальных сценариях, мониторьте метрики и адаптируйте под регуляции – это минимизирует риски и максимизирует отдачу.

Узнаем, что собой представляет технология, как формируются AJAX запросы, как работает инструмент, каковы его преимущества, недостатки и ограничения.

Основные компоненты AJAX

Термин AJAX используется в программировании с 2005 года, хотя подобные способы обмена данными применялись и ранее. Это универсальное решение для веб-приложений, которое объединяет несколько компонентов. Именно благодаря AJAX реализованы такие проекты, как современные соцсети, Google Maps, Gmail, Google Docs и многие другие.

Основная задача AJAX — запросы к серверу в обход перезагрузки страницы. Это уменьшает время отклика и позволяет веб-приложению работать в интерактивном режиме. Несмотря на присутствие в названии отсылки к XML, использовать этот язык разметки не обязательно.

Технология реализуется через JavaScript — происходит заданный скриптом асинхронный обмен данными между сервером и браузером. Именно на JS создаются запросы для коммуникации с сервером и динамического изменения страницы.

Асинхронность — ключевое условие запросов AJAX. Они выполняются в фоновом режиме, пока пользователь продолжает работу с сайтом. Загрузка и обработка данных выполняются параллельно.

Код на JavaScript — не единственный компонент AJAX. В него также входят форматы хранения данных XML или JSON. При этом JSON для отправки запросов AJAX используется чаще, поскольку код у этого формата короче, что существенно упрощает передачу данных.

Важнейший компонент технологии — объект XMLHttpRequest, который отвечает за все запросы AJAX. Этот API предоставляет клиенту полноценный функционал для взаимного обмена данными с сервером. Раньше XHR поддерживали не все браузеры — разработчикам приходилось дополнительно подключать библиотеку jQuery с встроенным объектом. Сейчас большинство популярных браузеров, включая Chrome и Firefox, работают с XMLHttpRequest напрямую.

Примечание. В современных программных веб-продуктах вместо XHR нередко используют Fetch AP, но говорить о массовом тренде преждевременно.

Передача данных выполняется через стандартный протокол взаимодействия клиента и сервера HTTP. Браузер инициирует запрос, получает в ответ HTML-страницу, либо сообщение об ошибке (если в запросе есть неточности). Используются стандартные методы получения данных — GET и POST. Первый (GET) применяется при получении данных от сервера, второй (POST) используется для отправки данных на сервер в теле HTTP-запроса.

Благодаря способности AJAX работать с разными форматами, типами данных и серверными API, эта методика универсальна. Асинхронный обмен позволяет веб-приложениям быстро загружаться, плавно работать и не перезагружаться после каждого запроса пользователя к серверу. Это особенно актуально для приложений, требующих постоянного взаимодействия с сетевым устройством — социальных сетей, онлайн-магазинов, браузерных версий мессенджеров.

Как работает AJAX

Магия асинхронных запросов AJAX базируется на взаимодействии с DOM-объектами браузерной страницы. Процесс выглядит следующим образом:

1. С помощью JavaScript браузер отправляет HTTP-запрос на сервер, где происходит обработка данных и отправка ответа. Чтобы отправить запрос, потребуется создать объект XMLHttpRequest — без него отправлять запросы и получать ответы без перезагрузки не получится.
2. При этом запрос необходимо настроить — указать метод GET/POST, URL и перейти на асинхронный режим работы.
3. Сервер возвращает данные, с которыми начинает работать JavaScript. Когда браузер принимает исходный код страницы, он выстраивает множество виртуальных элементов на базе этого кода — сюда входят заголовки, изображения, текст, ссылки и прочее.
4. При этом к каждому компоненту виртуальной модели можно обращаться отдельно с целью изменить его свойства или содержание. JavaScript позволяет поменять фон страницы, изменить заголовок и внести другие изменения, не перегружая страницу.

Простой пример запроса AJAX выглядит следующим образом (используется метод получения данных GET):

В этом примере мы создаем объект XMLHttpRequest, настраиваем запрос, обрабатываем ответ и данные, отправляем запрос на сервер. Данные выводятся в консоль без перезагрузки страницы — обновляется только нужный элемент интерфейса.

В следующем примере показан код для отправки формы с использованием запроса AJAX:

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

Отладка AJAX-запросов

Для эффективной разработки и поддержки приложений программистам важно научиться отлаживать и тестировать запросы AJAX. Для этого необходимы встроенные инструменты браузеров Chrome, Firefox, Edge и других.

Эти инструменты позволяют:

• просматривать отправленные на сервер запросы во вкладке Network;
• проверять атрибуты запросов/ответов и их содержимое;
• следить за временем выполнения отправленных запросов, выявлять узкие места и оптимизировать процессы.

Для тестирования запросов полезно создавать фейковые API или проверять работу реальных интерфейсов вне контакта браузера с помощью библиотек MSW или Postman.

Прогерам будут полезны ценные советы по оптимизации процессов при работе с запросами:

• Используйте кэширование, чтобы уменьшить количество запросов. Это снижает нагрузку на сервер и повышает производительность.
• Применяете сжатие данных для снижения объема отправляемой информации. Это ускоряет процесс передачи и обработки данных.
• Всегда обрабатывайте ошибки для улучшения пользовательского опыта. Лучше заранее предусмотреть все варианты, чтобы снизить риск возможных проблем при использовании приложения.

Преимущества AJAX

Перечислим основные плюсы технологии:

• Обновление данных без необходимости перезагружать страницу. Это улучшает опыт пользователей и делает взаимодействие с приложением более плавным и быстрым. Юзерам гораздо удобнее видеть обновление на той же странице, чем загружать новую.
• Уменьшение трафика. Поскольку браузер получает от сервера не всю страницу полностью, а только ограниченную запросом информацию, тратится меньше ресурсов на передачу данных.
• Снижение нагрузки на сервер. Если приложение открывает страницы «на лету», достаточно один раз прогрузить стандартные элементы (шапку, меню, подвал), а остальные части загружать по необходимости.
• Быстрота и отзывчивость приложений. Чем меньше данных в запросе AJAX, тем быстрее придет ответ от сервера. В современных продуктах скорость и удобство — ключевые конкурентные преимущества.
• Экономия ресурсов. Безлимитный интернет есть не у всех и не везде, а запросы AJAX используют ресурсы в минимальном режиме.

Необходимо также понимать, что технология не универсальна и подходит не для всех ситуаций и приложений.

Недостатки AJAX

В числе основных минусов AJAX:

• Потенциальные проблемы с SEO-контентом. Содержание страниц, которое подгружается с помощью AJAX, часто недоступно для поисковиков, что негативно сказывается на индексации. Поисковые системы видят исходный ход, но не данные с серверов. Это может быть проблемой для сайтов, которые нуждаются в привлечении пользователей. Для сеошников работа с сайтами на AJAX — головная боль.
• Кэширование. Динамическое содержание может создать сложности с кэшированием, что приводит к загрузке неактуальных данных.
• Зависимость от JavaScript. Пользователь может отключить JavaScript, что ограничит функциональность сайта. Данные не смогут прийти с сервера, интерактивного обновления не получится.
• Усложнение проекта. Работа с запросами AJAX требует от разработчиков определенной квалификации. Они должны предвидеть различные внештатные ситуации, связанные с асинхронными запросами, и заранее прописать скрипты на такие случаи. Потребуется также продумать бэкенд — ответы сервера на различные запросы.

При нестабильной связи AJAX может не получить ответа от сервера либо не отправить запрос. Такая ситуация нарушает логику загрузки страницы — ее придется все-таки перезагружать и начинать все с нуля.

Где используется AJAX

Технологию используют для улучшения пользовательского опыта при работе с сайтами и веб-приложениями. AJAX-запросы решают множество подзадач:

• Динамическое обновление. С помощью AJAX обновляются отдельные элементы страниц — таблицы, списки, графики. Это особенно удобно на сайтах, где применяются фильтры — например, на страницах онлайн-магазинов.
• Автозаполнение и поиск. AJAX используется для мгновенной выдачи результатов поиска. Юзер только начинает вводить текст в поисковую строку и уже видит релевантные варианты. Это удобно для формирования точных и подробных поисковых запросов.
• Отправка формы. Чтобы отправить данные заполненных форм, пользователю не нужно ждать обновления, что делает работу более плавной. Например, можно залогиниться после просмотра сайта, оставшись на той же странице.
• Загрузка данных для конкретного пользователя. В соцсетях или на сайтах с интерактивными опциями новые сообщения, уведомления и комментарии подгружаются без обновления страницы.
• Динамические интерфейсы. Этот процесс вы можете наглядно наблюдать на Гугл-картах и в подобных приложениях — по мере прокрутки подгружаются новые части территории. Аналогичная опция реализована на сайтах с интерактивными прогулками по гостиницам, музеям и другим локациям.

Иными словами, AJAX-запросы используются везде, где требуются обновления содержания без перезагрузки: чтобы получить список новых сообщений в чате или в общей ленте; подгрузить позиции на витрине товаров; увидеть рекламные баннеры и т.д.. В Ютубе на этой технологии основано сворачивание видео в компактный плеер в углу.

AJAX — незаменимый инструмент для разработки динамических интерфейсов и улучшения пользовательского опыта. Механизм основан на асинхронности работы браузера и сервера. При нормальной скорости интернета данные передаются мгновенно, так что пользователям даже не приходится ждать. При этом AJAX универсален и может работать с разными форматами данных и серверными API.

Как это реализуется на практике? Есть несколько способов работы с информацией. Наиболее востребованные из них — это cookies, localStorage и sessionStorage. Эти инструменты отличаются друг от друга, но далеко не все разработчики могут объяснить разницу между ними.

Узнаем, что собой представляют cookies, localStorage и sessionStorage, каковы их основные характеристики и особенности, как они применяются и какой способ работы с данными лучше.

Cookies

На заре интернета cookies были безальтернативным вариантом хранения данных на стороне клиента. Файлы куки представляют собой элементарные пары типа «ключ-значение» и используются для:

• управления текущими сессиями;
• персонализации пользователя;
• отслеживания его активности.

При этом данные не просто остаются в хранилище в браузере, но и передаются на серверы в виде HTTP-заголовков, выступая частью спецификации протокола. Cookies поддерживают все браузеры — это универсальный способ работы с информацией. И хотя объем данных для хранения ограничен, производительность этого способа — крайне важный показатель для работы современных веб-ресурсов.

По сути куки — это ограниченные по размеру текстовые файлы, которые сайт сохраняет на устройстве пользователя. Объем данных в «печеньках» лимитирован — это не больше 4 КБ, при этом у них есть срок хранения, который устанавливает разработчик ресурса.

Например, в Google есть файлы аналитики для сбора информации, которые хранятся от 6 до 24 месяцев. Некоторые cookies действуют только в период работы в браузере и при закрытии автоматически уничтожаются, другие хранятся в течение всего перерыва между сессиями — их срок жизни зависит от выполняемых задач.

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

Развитие этого инструмента продолжается. Например, в экосистеме Chromium доступна версия, которая поддерживает общую память и асинхронный API CookieStore — им можно пользоваться без блокировки главного потока.

Закрепим основные характеристики cookies:

• сохраняют данные, которые передаются на сервер с помощью заголовков;
• локальные и сессионные куки-хранилища существуют только на стороне клиента;
• сроки хранения устанавливаются заранее при создании куков;
• объем ограничен (4 КБ);
• бывают защищенные куки, но в этом случае их содержимое будет недоступным на клиентской стороне — такой формат используется для аутентификации пользователей при хранении их токенов.

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

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

Разработчики на JavaScript используют свойство document.cookie, которое предоставляет строковый формат для работы всех cookies, связанных с текущим процессом. Пример кода:

В этом примере для установки cookie разработчик присваивает строку свойству document.cookie. Можно задать дополнительные свойства — например, срок действия, путь или домен.

У файлов cookie довольно широкая область применения — хранение настроек юзера, удержание посетителей сайта, хранение сведений о текущем сеансе, показ целевой рекламы. При этом файлы устанавливает конкретный сервер, и только он может их прочитать.

Разработчики устанавливают и читают cookie через заголовки Set-Cookie и Cookie непосредственно в протоколе HTTP. В приложениях куки устанавливают и считывают с помощью соответствующего API либо модуля файлов cookie на одном из серверных языков — например, Node.js.

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

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

Чтобы минимизировать риски, юзеру при посещении незнакомых сайтов или при использовании публичных сетей лучше отказаться от автоматического приема куки-файлов. Альтернативный вариант — входить инкогнито.

LocalStorage

Это более продвинутый формат хранилища в браузере, позволяющий сайтам сохранять больше информации без ущерба для трафика. LocalStorage создали в качестве альтернативы cookie, чтобы обойти ограничения последних. А именно — небольшой объем хранилища, необходимость постоянно передавать данные с сервера в браузер и обратно. В localStorage работа с данными стала проще и эффективнее.

В локальном хранилище, в отличие от сеансового, данные сохраняются после закрытия и повторного открытия страницы. Файлы работают до тех пор, пока пользователь их не очистит или это не сделает код на JavaScript.

Информация хранится в формате «ключ-значение» в виде строк. Даже если ввести числовые или логические данные, они преобразуются в строчные. Для использования хранилища в JavaScript используют объект localStorage.

Пример кода:

Запись напоминает код для сеансового хранилища. Метод setItem() используется для хранения данных, метод getItem() — для их получения, removeItem() — для удаления конкретных элементов, clear() — для полной очистки данных. Несмотря на то, что в localStorage сохраняются только строки, с помощью JSON разработчики могут взаимодействовать и с более сложными типами данных.

Основные характеристики localStorage:

• данные хранятся бессрочно;
• очистить хранилище можно только принудительно — через код JavaScript или полную очистку браузерного кэша пользователем;
• объем данных для хранения — 5-10 МБ (по этому показателю localStorage лидирует среди всех хранилищ);
• старыми браузерами не поддерживается — например, на IE7 это локальный ящик не работает;
• действует по принципу ограничения домена — сохраненная информация доступна лишь одному источнику.

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

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

SessionStorage

Способ работы с данными sessionStorage во многом аналогичен localStorage, но есть принципиальное отличие — после закрытия браузера данные полностью удаляются. Это не означает, что sessionStorage — хуже, просто у него другая сфера применения. В частности формат идеален для хранения данных, актуальных в рамках конкретной сессии — например, информации при заполнении формы или вводе данных банковской карты.

Объем хранилища ограничен, но в большинстве случаев этого достаточно для хранения инфы в пределах одного сеанса. Данные по сути не защищены, так что вопрос приватности — забота пользователя.

Хранилище сеансов поддерживается всеми актуальными браузерами — данные находятся в полной доступности, пока открыты вкладки и окна. Если пользователь закрывает окно, происходит автоматическая очистка.

Для подключения сеансового хранилища разработчики на JavaScript используют объект sessionStorage и методы для получения, установки и удаления данных.

Пример кода:

Как видите, есть определенное сходство с localStorage, поскольку у хранилищ одинаковый алгоритм работы. Метод setItem() применяется для сохранения данных (первый аргумент — ключ, второй — значение), метод получения — removeItem(), для очистки используется метод clear().

Основные характеристики sessionStorage:

• данные хранятся в течение одной сессии, после закрытия браузера очищаются;
• хранилище использует контекст браузера верхнего уровня, то есть в каждой вкладке содержатся уникальные данные;
• объем данных — 5 МБ;
• старые браузеры формат не поддерживают.

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

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

Сравнение cookies, localStorage и sessionStorage

Принципиальная разница между способами хранения понятна из предыдущих разделов, осталось рассмотреть конкретные критерии.

Размер хранилища

• Файлы cookie. Здесь размер минимальный. Для каждого домена куки могут хранить ограниченный объем данных — как правило, не больше 4 КБ.
• LocalStorage. Максимально возможный объем данных для каждого домена — не менее 5 МБ, а при использовании определенных настроек и больше.
• SessionStorage. Здесь хранится больше данных для одного домена в сравнении с cookies. Размер — не более 5 МБ.

Срок хранения

• Файлы cookie. Данные куки могут быть сеансовыми или постоянными в зависимости от настроек. Постоянные имеют свой срок действия, который исчисляется месяцами или даже годами, сеансовые уничтожаются сразу после завершения сеанса.
• LocalStorage. Данные в локальном хранилище остаются после закрытия браузера и его повторного открытия. Удалить их может только пользователь или код JavaScript.
• SessionStorage. Информация в сеансовом хранилище остается, пока открыта вкладка сайта. При закрытии данные удаляются.

Работа с данными

• Файлы cookie. Разработчик может установить срок действия для файлов, после которого браузер автоматически очистит куки.
• LocalStorage. Нельзя запрограммировать автоматическое удаление данных или другие действия с ними. Они сохраняются, пока не будут удалены принудительно.
• SessionStorage. Здесь нет механизма автоматического истечения срока действия. Поэтому данные будут актуальны, пока открыта страница.

Доступ к данным

• Cookies. Доступ к файлам можно получить и изменить через JavaScript API, но существуют определенные ограничения для третьих лиц.
• LocalStorage и sessionStorage. Есть прямой доступ к информации в хранилищах через API JavaScript, который позволяет манипулировать данными.

Сетевой трафик

• Cookies. Данные автоматически отправляются на север после каждого HTTP-запроса для соответствующего домена, что увеличивает загрузку трафика.
• LocalStorage и sessionStorage. Данные не отправляются на сервер, а остаются на стороне клиента, что сокращает объем лишнего трафика.

Когда использовать cookies, localStorage и sessionStorage

Использование различных способов хранения информации зависит от целей обращения с данными. На сайтах с авторизацией и значимой историей просмотра (например, в крупных онлайн-магазинах) важно, чтобы пользовательские данные сохранялись в большом объеме и как можно дольше, поэтому предпочтительным инструментом выступает localStorage.

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

Разницу в жизненном цикле cookies, localStorage и sessionStorage используют в соответствии с задачами хранения. Ограниченный срок действия cookies и данных сессионного хранилища могут стать преимуществами в одном случае и недостатками в другом. С данными localStorage аналогичная ситуация — если нужен полный контроль времени хранения, этот формат идеально подходит.

Проблемы и перспективы хранилищ данных

Все хранилища потенциально уязвимы для XSS-атак. В cookies применяют дополнительные меры защиты: флаги HTTPOnly и Secure запрещают доступ из JavaScript к файлам, чувствительным к безопасности. Для отправки таких файлов используется передача по шифрованным каналам HTTPS.

Для защиты от атак CSRF (подделка межсайтовых запросов) используют атрибут SameSite, проверку HTTP_Referer/Origin или применение синхронизированных токенов.

В localStorage для обеспечения безопасности важно соблюдать принцип одного источника и тоже пользоваться зашифрованными HTTPS-соединениями. При этом эксперты все равно не рекомендуют сохранять конфиденциальные данные в localStorage.

Учитывайте, что куки могут замедлять загрузку, особенно если у пользователей низкая скорость интернета. LocalStorage на HTTP-запросы не влияет, что положительно отражается на производительности веб-ресурса.

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

Однако вместо пошаговой инструкции по удалению браузера, страница представляет собой перечень преимуществ Edge, таких как интеграция с Copilot, вертикальные вкладки и встроенный VPN.

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

Многие восприняли такой подход как попытку удержать пользователей от перехода на другие браузеры, такие как Google Chrome или Mozilla Firefox.

Вместо предоставления информации о том, как удалить Edge, Microsoft использует страницу для продвижения своего продукта.

Возможность удаления Edge

Отметим, что официально у Microsoft нет простого способа удалить Edge, поскольку браузер интегрирован в операционную систему Windows.

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

Также, вполне легально, удалить Edge могут жители Евросоюза.

Цель проекта — укрепить открытое развитие Chromium и стимулировать создание новых браузеров на его основе.

Chromium, запущенный в 2008 году, является основой для таких популярных браузеров, как Google Chrome, Microsoft Edge и Opera. Однако до сих пор проект оставался в основном под контролем Google.

Задачи и структура инициативы

Новая инициатива создаст нейтральное пространство для сотрудничества разработчиков и сообщества с открытым исходным кодом. Основные положения:

• Существующие проекты на основе Chromium останутся под управлением их владельцев.
• Новые браузеры будут размещаться под управлением Linux Foundation.
• Инициатива будет следовать открытой модели управления, вдохновлённой успешными проектами Linux Foundation.

Для руководства проектом будет создан Технический консультативный комитет (TAC), который займётся поддержкой сообщества и развитием экосистемы Chromium.

Поддержка крупных компаний

Проект уже получил поддержку таких технологических гигантов, как Google, Microsoft и Opera. Компании пообещали финансирование и участие в разработке.

Заявления участников

• Париса Табриз, вице-президент Google по Chrome:«С поддержкой Linux Foundation мы можем создать устойчивую платформу для дальнейшего развития экосистемы Chromium».
• Меган Перез, вице-президент Microsoft Edge:«Мы рады присоединиться к этой инициативе, которая укрепит сотрудничество в экосистеме Chromium».
• Джим Землин, исполнительный директор Linux Foundation:«Этот проект предоставит финансирование и поддержку, необходимые для открытого развития проектов Chromium».

Изменение подхода Google

В 2021 году Google ограничил доступ к некоторым API Chrome для браузеров на базе Chromium, что вызвало критику со стороны разработчиков.

Новая инициатива сигнализирует о более открытом подходе, возможно, связанном с антимонопольными разбирательствами против Google в США.

Если Chromium станет действительно открытым, это может устранить претензии к Google о чрезмерном контроле над экосистемой браузеров и рекламы.

Новинка позволяет запускать Linux-приложения и работать с файлами в полностью функциональной среде без необходимости установки операционной системы на компьютер.

Как работает WebVM 2.0

WebVM 2.0 создан на базе WebAssembly, что позволяет ему использовать мощные возможности браузера для быстрой работы даже с относительно ресурсоемкими Linux-приложениями.

Веб-система запускается на стороне пользователя, что обеспечивает безопасность и производительность, так как вся обработка данных происходит локально.

WebVM 2.0 поддерживает достаточно широкий спектр утилит и приложений, доступных в Linux, включая компиляторы, редакторы и другие инструменты для разработчиков.

Пользователи могут загружать файлы, запускать программы и писать код, работая с удобным интерфейсом, похожим на традиционное терминальное окно Linux.

Основные возможности и преимущества

Одной из ключевых особенностей WebVM 2.0 является его доступность на любых устройствах, где есть веб-браузер — будь то ноутбук, планшет или даже смартфон.

Это делает платформу полезной для разработчиков, студентов и IT-энтузиастов, которым требуется доступ к Linux-инструментам «на ходу».

Кроме того, WebVM 2.0 не требует сложной установки или настроек, что позволяет запустить окружение буквально в пару кликов. Отличный вариант на случай, когда надо быстро протестировать код или выполнить определенные команды в Linux.

Ранее популярной функцией потокового перевода видео могли похвастаться только некоторые браузеры, такие как Яндекс.Браузер.

Однако теперь аналогичное решение доступно и пользователям Google Chrome и Safari — благодаря расширению voice-over-translation, созданному энтузиастом-разработчиком и доступному бесплатно на GitHub.

Возможности voice-over-translation

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

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

Как установить voice-over-translation:

1. Откройте ваш браузер — Chrome или Safari.
2. Установите менеджер скриптов: для Chrome — Tampermonkey; для Safari — UserScripts.
3. Скачайте и установите скрипт voice-over-translation с GitHub.
4. Откройте видеоролик на английском языке.
5. Активируйте перевод — в окне видео появится баннер, в котором нужно нажать «Перевести».

Преимущества использования расширения

• Быстрая установка: процесс занимает всего несколько минут.
• Совместимость: работает с любыми видеоплатформами, включая YouTube и Vimeo.
• Удобство: переводы осуществляются без необходимости переключаться на другой браузер.

Что изменится в Manifest V3?

Третья версия манифеста вносит значительные изменения в работу расширений. Они касаются не только Google Chrome, но и всех браузеров на базе Chromium, таких как Microsoft Edge, Opera, Яндекс.Браузер, Arc и других. Основные изменения следующие:

1. Переход на сервис-воркеры: теперь расширения работают не на основе фоновых страниц, а с использованием сервис-воркеров, которые запускаются по необходимости, а не функционируют постоянно. Это должно сделать работу браузера более эффективной.
2. Новый способ управления сетевыми запросами: вместо webRequest API, который позволял гибко модифицировать и блокировать запросы, используется declarativeNetRequest. Теперь браузер сам выполняет фильтрацию, а расширения лишь предоставляют списки правил. Это ограничивает возможности блокировщиков рекламы, таких как uBlock Origin, которые использовали более 300 000 правил, тогда как новая версия позволяет задать не более 30 000.
3. Запрет на использование удалённого кода: расширениям разрешается выполнять только код, включённый в пакет изначально. Это усложняет работу блокировщиков, так как обновления фильтров должны проходить модерацию в Chrome Web Store, что может занять недели.

Влияние на пользователей

Изменения в Manifest V3 могут негативно сказаться на эффективности блокировщиков рекламы и других полезных, но давно не обновляющихся расширений.

Разработчик uBlock Origin уже выпустил облегчённую версию расширения — uBlock Origin Lite, адаптированную под новые правила, но с ограниченной функциональностью.

Переход на Manifest V3: сроки и альтернативы

Google начала работу над Manifest V3 ещё в 2018 году и процесс внедрения продолжается.

К июню 2025 года все версии Chrome полностью перейдут на новый манифест. Другие браузеры на основе Chromium могут иметь свои сроки перехода. Например, Vivaldi и Brave планируют сохранить поддержку MV2 дольше.

Для пользователей, желающих сохранить текущие расширения, есть несколько альтернатив: переход на Firefox или Safari, где поддержка MV2 сохраняется, или использование корпоративных политик, позволяющих временно сохранить поддержку устаревших расширений.

Исследователи из AhnLab выяснили, что злоумышленники воспользовались неизвестной ранее уязвимостью в Internet Explorer для распространения вредоносного ПО среди пользователей в Южной Корее.

Как была осуществлена атака

В мае хакерская группа APT 37 (или ScarCruft) воспользовалась уязвимостью «нулевого дня» в Internet Explorer, чтобы запустить масштабную атаку.

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

Уязвимость через компоненты Internet Explorer

Несмотря на то, что Internet Explorer отключен на большинстве ПК с Windows, его компоненты всё ещё можно найти в режиме IE, встроенном в Microsoft Edge, и в сторонних модулях.

Это дает хакерам возможность эксплуатировать устаревший браузер.

Злоумышленники использовали факт того, что многие пользователи в Южной Корее устанавливают бесплатное ПО с рекламными модулями, что в конечном итоге и давало возможность злоупотреблять компонентами Internet Explorer.

Опасность устаревших технологий

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

Microsoft уже выпустила патч для устранения этой уязвимости в августе, однако остаётся риск, что злоумышленники смогут найти другие способы эксплуатации компонентов Internet Explorer.

Этот инцидент подчёркивает, что даже устаревшие браузеры могут оставаться источником угроз для пользователей.

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

Цели и особенности IPA

IPA позволяет обрабатывать статистические данные без раскрытия информации о конкретных пользователях.

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

Это нововведение было внедрено с целью предложить рекламодателям альтернативу слежке за пользователями, что часто происходит в попытке увеличить доходы.

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

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

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

Как отключить IPA в Firefox 128

Функция включена по умолчанию, но её можно деактивировать следующим образом:

1. Откройте меню Firefox, нажав на значок ≡.
2. Перейдите в раздел «Настройки».
   
3. Выберите вкладку «Приватность и защита».
   
4. Найдите опцию «Разрешить веб-сайтам проводить измерение рекламы с сохранением приватности» и отключите её.
   

Дополнительные нововведения в Firefox 128

Кроме интеграции IPA, в Firefox 128 был добавлен инструмент Firefox Translation, который теперь умеет переводить отдельные фрагменты текста на странице.

Также улучшен дизайн окна для очистки данных об использовании браузера.

Эти вирусы маскируются под официальные обновления, что делает их особенно коварными и опасными.

Механизм атаки

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

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

Эта страница, как правило, предлагает загрузить ZIP-архив, содержащий вредоносное ПО.

Пример атаки

На поддельной странице обновления браузера (например, chatgpt-app[.]cloud) пользователь видит ссылку на скачивание файла Update.zip.

Этот файл, размещенный на Discord, автоматически загружается на устройство пользователя. В архиве содержится JavaScript-файл (Update.js), который запускает выполнение PowerShell-скриптов, загружающих дополнительные полезные нагрузки с удаленного сервера в виде файлов PNG.

Распространение через Discord

Анализ компании Bitdefender выявил более 50 000 опасных ссылок в Discord, которые распространяли вредоносное ПО, фишинг-кампании и спам только за последние шесть месяцев.

Вредоносные программы

• BitRAT: Многофункциональный троян удаленного доступа, позволяющий атакующим собирать данные, добывать криптовалюту, загружать дополнительные бинарные файлы и удаленно управлять зараженными устройствами.
• Lumma Stealer: Доступен за $250-1000 в месяц и может захватывать информацию из веб-браузеров, криптокошельков и других источников.
  

Постоянство и загрузчик

PowerShell-скрипты обеспечивают постоянство вредоносного ПО на устройстве и запускают загрузчик на базе .NET, который используется для выполнения конечного этапа вредоносной программы. Загрузчик рекламируется как «сервис доставки вредоносного ПО», что позволяет распространять как BitRAT, так и Lumma Stealer.

Рекомендации по безопасности

Специалисты по кибербезопасности рекомендуют пользователям:

• Проверять подлинность уведомлений об обновлениях.
• Скачивать апдейты только из доверенных источников.
  
• Быть внимательными к подозрительным ссылкам и сообщениям.
  

Что за фишки?

Защита от вирусов и фишинга теперь в реальном времени.

Раньше Chrome сравнивал адрес сайта со списком опасных, который обновлялся раз в полчаса. А мошенники наловчились создавать левые сайты на пару минут, успевая делать гадости.

Сейчас же Chrome мгновенно сверяется с базой Google, где хранится инфа о «плохих» сайтах. Результат: на 25% больше заблокированных мошеннических страниц.

При этом, что важно, ваши данные при этом никто не видит. Google обещает, что вся проверка происходит анонимно и безопасно. Обновление вот-вот появится в Chrome для компьютеров и iOS. А в течение месяца еще и на Android.

Enhanced Protection

Вместе с тем в браузере появится режим «супер-защиты» — Enhanced Protection. Он еще умнее, сканирует файлы на вирусы и даже ругает вредные расширения для Chrome.

Не забыли в Google и про пароли

Chrome на iOS теперь проверяет пароли не только на утечки, но и на слабые или одинаковые (которые вы используете на разных сайтах).

Как включить всё это добро?

Новые фишки включатся сами. Но если хотите проверить:

• Открываем Chrome
• Идем в Настройки
  
• Жмем «Проверка безопасности» и смотрим, чтобы защита была включена.
  

Работать фича будет просто: соответствующая кнопка будет всплывать в контекстном меню (чтобы его включить, зайдите в Настройки -> Инструменты -> Контекстное меню). Иначе, пользуйтесь горячими клавишами:

• Alt + R — исправить ошибки;
• Alt + U — улучшить;
• Alt + Y — сократить (работает для текстов от 100 символов).

Во-вторых, браузер научился пересказывать текстовое содержимое страниц (раньше он обрабатывал только видео).

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

Ну и по мелочи: Алиса научилась генерировать картинки по пользовательскому запросу (скорее всего, к ней привязали яндексовский Шедеврум). А чтобы перейти по QR-коду из видео, телефон больше не потребуется — браузер сам обнаружит код в видеопотоке. И предложит либо скопировать ссылку, либо сразу по ней перейти.

Функцию планируют добавить в Google Chrome, чтобы предотвратить переходы на вредоносные сайты и сократить количество используемых данных, чтобы пользователи не подгружали нежелательный контент.

Также предварительный просмотр можно будет открыть в боковом меню браузера или в новой вкладке.

Идею назвали «Эфемерными окном и вкладками». Она будет выглядеть примерно так же, как работает предпросмотр вкладок в мобильном браузере.

Opera One основана на движке Chromium. В браузере был полностью переработан дизайн, который теперь стал модульным.

Раньше обработка анимаций приводила к подвисаниям браузера. В Opera One эту проблему решили при помощи многопоточного компоновщика, и в Opera обещают, что браузер справляется с нагрузками при отрисовке страниц безо всяких проблем.

Собственный ИИ Opera полностью интегрирован в Opera One как в версии для ПК, так и для Android-приложения. Чат-бот Aria полностью бесплатный, он обучен на актуальной информации и доступен в 180 странах.

Также в Opera One с помощью ИИ комбинируются вкладки. Также в боковой панели предлагаются сайты для веб-серфинга, актуальность которых также определяется при помощи ИИ.

Кроме того, Opera One предлагает встроенные VPN и блокировщик рекламы. Они абсолютно бесплатны.

В новом браузере показали новый дизайн с модульной архитектурой, кучей анимаций и автоматической группировкой вкладок.

Браузер будет сам группировать открытые сайты на основе того, что находится на странице. Но пользователи смогут группировать свои «острова» и вручную.

Вот как будут работать «острова».

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

В новом браузере компания делает упор для ИИ-помощников: в Opera One добавили боковую панель для чат-ботов. Первыми туда интегрируют ChatGPT и ChatSonic.

Пока доступна только ранняя версия для разработчиков. Но совсем скоро обещают выпустить полноценную версию для всех популярных платформ.

Опрос: Как вам новый браузер от Opera? Перешли бы на Opera One, когда выйдет полноценный релиз?

PWA — промежуточная технология между сайтами и нативными мобильными приложениями. По сути, это «прокачанная» копия веб-сайта, размещенная на устройстве пользователя и не требующая отдельной разработки для iOS или Android.

«Прогрессивное web-приложение (англ. progressive web app, PWA) — технология в web-разработке, которая визуально и функционально трансформирует сайт в приложение (мобильное приложение в браузере)»

Так описывается технология в Wikipedia, но нам этого мало, так что давайте подробнее разберем, что это такое.

PWA-приложение не нужно отдельно разрабатывать для iOS и Android: оно устанавливается на главный экран смартфона, — для этого нужно заложить технологическую базу на этапе Frontend-разработки. Можно сказать, что PWA — это сайты с расширенной функциональностью, которая позволяет им быть похожими на нативные мобильные приложения.

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

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

Задачи, которые решает PWA:

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

Однако любую из этих задач может решить и нативное мобильное приложение, так что в случае с PWA-разработкой можно поставить знак равенства между PWA Frontend developer и Mobile developer, поскольку они решают одни и те же задачи.

История PWA

Технология была создана компанией Microsoft еще в 2000 году. В 2007 сотрудники Apple разработали свой вариант HTML-приложений.

Изначально приложения для оригинального iPhone разрабатывались именно на платформе web. Однако успеха технология не сыскала по причине скудного UX, и в скором времени появился App Store, который по факту отложил развитие PWA.

Ожила и приобрела широкую известность технология только в 2015 году благодаря расширению возможностей браузера Google Chrome и продвижению Service Worker и Web App Manifest. Тогда же дизайнер Фрэнсис Берримэн и инженер Google Chrome Алекс Рассел придумали термин PWA.

Затем поддержку прогрессивного веб-приложения начали добавлять во все браузеры и операционные системы. К примеру, в Windows, начиная с 10 версии, появилась возможность распространения PWA через Microsoft Store.

Но все же основная причина развития данной технологии — привлечение и удержание мобильного трафика: так, в России мобильный трафик по итогам 2021 года составил рекордные 83%.

Примеры PWA

Существует огромное множество прогрессивных веб-приложений — Telegram, Pinterest, Tinder, Starbucks.

Появились и отдельные сайты-каталоги PWA, например appsco.pe и findpwa.com. Другие ресурсы для тех, кто интересуется разработкой прогрессивных веб-приложений — pwastats.com и web.dev, раздел Case Study.

На этих сайтах можно прочитать про множество успешных кейсов применения PWA с цифрами и с результатами. Один из примеров — как Starbucks смогли в два раза увеличить количество ежедневных пользователей.

Структура PWA

Чаще всего PWA состоит из Service Workers, Application Manifest, Офлайн-кэширования, различных PWA-технологий, адаптивного дизайна, фоновой синхронизации, Push-уведомлений, Media API и Geolocation API.

Модификаций структуры множество, однако минимальные требования для работы PWA — это:

• Валидное и защищенное HTTPS-подключение (у домена должен быть установлен SSL-сертификат).
• Успешно установленный файл Service Worker`а.
• Правильно установленный и валидный JSON-файл манифеста.

Любой сайт можно дополнить данными составляющими и тем самым получить прогрессивное веб-приложение.

Service Worker

«Сердце» PWA — Service Worker. Это проксирующий слой между фронтэндом и бэкэндом, находящийся в браузере. Все запросы браузера идут через него.

Из хранилищ у Service Worker’a есть доступ к Cache-хранилищу для web-ресурсов, и IndexDB для данных. Но, самое главное, — полная свобода для реализации бизнес-логики.

С точки зрения написания кода, Service Worker представляет собой Javascript-файл. В нем разработчик определяет логику работы с приходящими из фронтэнда запросами и другую функциональность.

Web App manifest

Web App manifest — JSON-файл, декларативно определяющий для браузера название приложения, иконку, как будет выглядеть PWA (fullscreen, standalone и другие варианты отображения) и некоторые другие параметры. Позволяет «установить» PWA как отдельное приложение на домашний экран смартфона.

Технические особенности PWA

Способы установки PWA

Существует три способа установки PWA: при помощи автоматического уведомления, через «…» (три точки) в меню браузера, при клике на кнопку установки на странице.

Так выглядит установка с помощью автоматического уведомления

Пример установки через «…» (три точки) в меню браузера

Отображение PWA

PWA работают на базе WebView, который предоставляют браузеры. WebView очень популярный способ для отображения интерфейсов.

Браузер, который будет открывать PWA после установки приложения, определяется операционной системой iOS или Android.

Для Android используется Google Chrome, а для iOS — Safari.

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

Поддержка PWA

По данным caniuse.com, 94% устройств пользователей поддерживают service workers, возможность установки на домашний экран есть у 87% пользователей.

Функциональность PWA

PWA поддерживает множество способов взаимодействия с аппаратной частью телефона.

Такие функции как доступ к контактам пользователя, NFC, считывание QR, поддержка AR/VR пока недоступны, но в ближайшее время их должны добавить.

Подробнее обо всех функциях с примерами кода можно узнать на сайте whatpwacando.today.

Фреймворки и библиотеки

Для PWA необходимо только два файла — Service Worker и Web App manifest, — поэтому для разработки подойдут все актуальные реактивные фреймворки. Для каждого из них есть плагин, который добавляет предустановленный файл манифеста, предустановленный файл service worker’a и дополнительную функциональность.

Также есть фреймворки конкретно для работы с PWA:

• React PWA Library
• Angular PWA Framework
• Vue PWA Framework
• Ionic PWA Framework
• Svelte PWA Framework

PWA Builder

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

Отличительные качества PWA

Ограниченный доступ к аппаратной части

К недостаткам PWA можно отнести ограниченный доступ к аппаратной части мобильного устройства.

Поскольку прогрессивные веб-приложения запускаются в браузере, они не имеют прямого доступа ко всем возможностям платформы (операционной системы и аппаратным возможностям), к которым имело бы доступ нативное приложение, созданное с использованием SDK-платформы.

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

Установка в обход магазинов приложений

PWA, хоть и можно добавить в сторы, но их дефолтный способ установки — через браузер, т.е. они устанавливаются в обход сторов.

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

Фоновая установка обновлений

Больше не нужно заставлять пользователей устанавливать обновления. Когда вы выпускаете новую версию своего приложения, все ваши пользователи автоматически получают новую версию.

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

Меньший размер приложения

Размер PWA-приложения, как правило, не превышает 1-3 мегабайт. Это меньше, чем мобильное приложение. Средний размер мобильного приложений, по данным 2017 года, 38 Мб для iOS и 15 Мб для Android.

Меньшие затраты на разработчиков

Для компаний, бизнеса разработка и поддержка PWA финансово выгоднее.

В общем, PWA имеет свои отличительные особенности и недостатки.

В связи с ограничениями аппаратной части, PWA не может полностью заменить нативные приложения, но четыре ключевые функции PWA-приложений закрывают потребности 90% мобильных пользователей:

• Отправка Push-уведомлений, чтобы вернуть пользователей.
• Установка иконки на домашний экран, чтобы дать пользователям быстрый доступ к приложению.
• Доступ к некоторым нативным аппаратным функциям, например, камеры, микрофона.
• Возможность работы офлайн.

Мы рекомендуем разрабатывать PWA-приложения когда нужно:

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

Как интегрировать PWA в сайт: инструкция для начинающих

Собрали полезные ресурсы, которые помогут разработать и запустить прогрессивное веб-приложение на любом стеке.

1. Добавить файлы manifest и serviceworker

• Инструкция по добавлению файла manifest в проект. Пояснение по полям файла,
• Ресурс для генерации файла manifest.
• Документация по manifest от разработчиков Mozilla. Примеры файла manifest, пояснение по полям, совместимость с браузерами.
• Инструкция по добавлению файла serviceworker, его регистрация, жизненный цикл.
• Документация по serviceworker от разработчиков Mozilla. Примеры файла, архитектура, жизненный цикл, кеширование, запросы.

2. Подключить и настроить библиотеки workbox

• Документация по всем способам и вариациям подключения workbox.
• Все возможные фреймворки и библиотеки, интегрированные с workbox.

3. Добавить кнопки на сайте для установки приложения

• Инструкция по добавлению кнопки установки приложения.
• Инструкция по добавлению кнопки установки приложения.

4. Запросить разрешения на отправку push-уведомлений

• Документация о push-уведомлениях со всеми тонкостями.
• Инструкция от разработчиков Mozilla по добавлению push-уведомлений.

Последующие пункты необязательны, но могут пригодиться для дополнительных этапов интеграции.

5. Настроить различные стратегии кэширования для статичных файлов

• Инструкция по настройке стратегий кеширования с примерами и пояснением.
• Вариации стратегий кеширования, пояснение каждой.

6. Настроить показ уведомлений при обновлении кеша

Документация от разработчиков Mozilla по событию обновления кеша.

7. Запись и чтение данных в IndexedDB

• Документация от разработчиков Mozilla по IndexedDB, интерфейсам, спецификацией.
• Документация по IndexedDB с примерами использования.

Итог

Разработка PWA мало чем отличается от обычной веб-разработки и со стороны написания кода, и со стороны дизайна, — разработчику необходимо написать чуть больше кода, а дизайнеру буквально отрисовать иконку для отображения на главном экране.

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