В этой статье я изложу то, что почерпнул из чтения RFC 9111 (2022 год) — последнего стандарта по HTTP-кэшингу.
Он определяет HTTP-заголовок Cache-Control, предписывающий способ хранения и повторного использования HTTP-запросов касательно не только кэша браузера, но и всех промежуточных кэшей наподобие прокси и CDN, которые могут существовать между клиентом и исходным сервером.
Кто-то знает и пользуется, а кому-то, возможно, короткая статья освежит в памяти этот лайфхак. Я так пользуюсь постоянно.
Допустим на сайте есть форма авторизации. А на форме есть поле ввода пароля. И пароль на сайте сохранён в браузере, и подставляется автоматически, и отображается спецсимволами. И, возможно, на этом сайте сохранены несколько данных для ввода, или вы сомневаетесь, что там сохранено, или ошибка, или любые другие варианты…
Хорошо, если в поле ввода пароля есть стандартная кнопка «Отобразить пароль»，и можно посмотреть, что подставляется в поле ввода пароля:
Сколько будет корень из нуля? Даже школьник ответит не задумываясь: ноль. Но если задать этот вопрос JIT‑компилятору Maglev внутри движка V8, то при определённых обстоятельствах он сначала скажет: «ноль», а потом решит сэкономить на проверке безопасности и отдаст злоумышленнику доступ к памяти браузера.
Меня зовут Паша Кузьмин, я занимаюсь практической безопасностью Яндекс Браузера и проекта Chromium. В нашей команде мы регулярно разбираем уязвимости и исследуем методы атак — чтобы защищать пользователей до того, как их атакуют злоумышленники. Сегодня расскажу про CVE-2025-9864 — уязвимость, которую я нашёл в движке V8.
Это история о том, как безобидный Math.sqrt(0) превращается в use‑after‑free, а затем в произвольное чтение и запись памяти. Разберём проблему по шагам: от теории до работающего эксплойта.
Будущее плиточных веб-макетов уже настало! После того, как Mozilla заложила фундамент, потребовались годы работы команды Apple WebKit и множество этапов обсуждений в CSS Working Group с разработчиками всех браузеров, чтобы стало понятно, как всё это должно работать.
Представляем вашему вниманию CSS Grid Lanes.
Несколько месяцев назад я писал о прокси-войне, которую Google ведёт против открытого веба при помощи XSLT. Совершенно неудивительно, что Google продолжает продвигать отказ от него, по-прежнему не давая никаких весомых причин, за исключением «мы наживались на FLOSS-библиотеке, в которой наконец нашли достаточное количество багов безопасности, чтобы это служило оправданием». Компания не объяснила, почему решила не устранять проблемы в самой библиотеке или использовать более современную библиотеку, написанную на безопасном языке, воспользовавшись возможностью проапгрейдить поддержку XSLT до более свежей, мощной и простой версии стандарта.
Вместо этого она решила предоставить «полифил» на JavaScript, который, предположительно, можно использовать для вытеснения функциональности. Однако любопытно, что компания не планирует выпускать эту альтернативу в браузере, что позволило бы выполнить прозрачный переход вообще без обсуждения XSLT. Нет, она осознанно отказалась это делать, потребовав от всех, кто использует XSLT, заменить вызов XSLT нестандартным вызовом полифила JavaScript, который должен его заменить.
Всем привет! Мы делаем проекты по Zabbix, накопили большую экспертизу и решили сделать переводы нескольких статей, которые нам показались интересными и полезными. Наверняка, будут полезны и вам. Также своим опытом делимся в телеграм-канале zabbix_ru, где вы можете найти полезные материалы и записи наших вебинаров, опубликованных на нашем ютуб-канале (прим. переводчика). Ниже ссылки на предыдущие статьи из цикла.
Миграция с MySQL на PostgreSQL
SELinux: интеграция с Zabbix и другими инструментами
Защита от ложных срабатываний триггеров в Zabbix с использованием функций min/max/avg
Zabbix – автоматизация управления пользователями (JIT)
Двухфакторная аутентификация (2FA) в Zabbix 7.0
Как настроить прием SNMP-трапов в Zabbix
В этой статье мы покажем, как установить и настроить Zabbix, чтобы он мог использовать потенциал нового элемента «Браузер». Подробности под катом.
В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.
Когда вы заходите на сайт, ему нередко нужно знать, какой у вас браузер и устройство. Это помогает показывать подходящую версию страницы, например мобильную или полную, а также включать только те функции, которые может поддерживать ваш браузер.
Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.
На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.
Поддержка Windows 10 официально завершилась в октябре 2025 года, при этом около 240 млн компьютеров в мире не совместимы с аппаратными требованиями Windows 11. У этих пользователей остаётся два основных варианта: покупать новый компьютер (с блэкджеком и AI-процессором) или переходить на Linux. Вероятно, многие выбирают второй вариант.
Косвенно это затрагивает и мобильный рынок, потому что многим нравится использовать одинаковые браузеры на ПК и смартфона, с поддержкой синхронизации табов, единой учётной записью и др.
И вот тут пришло время Firefox.
Веб-разработчики нередко воспринимают браузер как «черный ящик», который каким-то чудом превращает HTML, CSS и JS в интерактивные веб-приложения. На самом деле современный браузер — будь то Chrome (на базе Chromium), Firefox (Gecko) или Safari (WebKit) — представляет собой чрезвычайно сложное программное решение. Он управляет сетевыми запросами, разбирает (парсит) и выполняет код, рендерит графику с ускорением на графическом процессоре (GPU) и изолирует контент в отдельных процессах для обеспечения безопасности.
В этой серии статей мы подробно рассмотрим, как устроены современные браузеры, сделав акцент на архитектуре и внутреннем устройстве Chromium, но также отметим ключевые отличия в других браузерах. Мы рассмотрим весь цикл: от сетевого стека и конвейера парсинга до рендеринга с помощью Blink, выполнения JS с помощью движка V8, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".
Всем привет! Меня зовут Максим Иванов. Сегодня я хотел бы провести небольшой исторический экскурс и объяснить, почему Document Picture-in-Picture — это не просто способ отображать видео в формате «картинка в картинке», а новое и любопытное API, которое потенциально может заменить привычный всем window.open.
Возможность выводить видео в режиме PiP появилась еще в сентябре 2018 года в Chrome 69. С тех пор прошло более семи лет активного тестирования и развития. В 2019 году подобный механизм появился в Safari, а к 2020-му — и в Firefox.
Теперь, когда почти каждый браузер умеет открывать видео в отдельном плавающем окне, возникает логичный вопрос: могут ли браузеры с той же легкостью открывать в отдельном окне интерактивный HTML-контент, а не только видео? И если да, то каким образом? Давайте поговорим об этом ниже.
Веб-разработчики нередко воспринимают браузер как «черный ящик», который каким-то чудом превращает HTML, CSS и JS в интерактивные веб-приложения. На самом деле современный браузер — будь то Chrome (на базе Chromium), Firefox (Gecko) или Safari (WebKit) — представляет собой чрезвычайно сложное программное решение. Он управляет сетевыми запросами, разбирает (парсит) и выполняет код, рендерит графику с ускорением на графическом процессоре (GPU) и изолирует контент в отдельных процессах для обеспечения безопасности.
В этой серии статей мы подробно рассмотрим, как устроены современные браузеры, сделав акцент на архитектуре и внутреннем устройстве Chromium, но также отметим ключевые отличия в других браузерах. Мы рассмотрим весь цикл: от сетевого стека и конвейера парсинга до рендеринга с помощью Blink, выполнения JS с помощью движка V8, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".
Буквально утром 1-го числа Opera анонсировала интеграцию Gemini, Edge продолжает пихать Copilot во все щели, а Chrome просто... есть. И вот сидишь ты перед монитором с десятком открытых вкладок «Сравнение браузеров 2025» и понимаешь: выбор браузера в 2025-м — это не про «какой быстрее», а про «с каким меньше бесишься и кому готов отдать свои данные».
Разберёмся, что реально происходит на рынке браузеров к концу года, какие появились адекватные альтернативы и почему 90% людей всё равно сидят на Chrome, хотя ругают его за прожорливость.
В комментариях к предыдущей статье многие писали:
«Я не буду доверять какому-то боту» «Любой сторонний сервис — риск» «Номер можно подменить»
Это нормальная и абсолютно здравая позиция.
Поэтому в этой статье — максимально честный и технически конкретный разбор:
🔹 какие угрозы реально существуют при бытовых переводах,
🔹 почему обычная пересылка номера в мессенджере — тоже уязвима,
🔹 как можно построить архитектуру, в которой сервис не касается денег,
🔹 и какие механизмы защиты позволяют минимизировать риск подмены номера.
Наверно, большинство людей, стремящихся избавиться от сервисов и приложений Google, озабочено приватностью. Приватность в Интернете — довольно расплывчатая концепция, однако один из её аспектов определённо заключается в защите от передачи информации о веб-браузинге между разными организациями. Например, я не хочу, чтобы моя страховая медицинская компания знала, что я гуглил ишемическую болезнь сердца. И хотя, вероятно, речь не идёт о моей личной безопасности и свободе, я не хочу никоим образом помогать глобальному рекламному монстру, предоставляя рекламодателям доступ к более подробной информации обо мне.
К сожалению, хотя дистанцирование от Google и его сервисов действительно будет необходимым первым шагом по защите своей приватности, он окажется далеко не последним. Потребуются и другие меры, предпринимать которые становится всё сложнее из-за браузерного фингерпринтинга.
Статья об опыте и возможных преимуществах использования окон веб-браузера вместо вкладок веб-браузера.
Речь пойдёт о нюансах использования Web Audio API и Web MIDI API для синтеза звука в браузере, методах датабендинга и сонификации, UX при использовании клавиатуры и мыши в музыкальных целях, а также почему браузер ungoogled-chromium лучше Google Chrome
Пользователи всегда хотят большего, и количество самых разных запросов постоянно растёт. Но есть некоторые функции, которые пользуются особой популярностью. Вот такие запросы мы и реализовали в новой версии браузера Vivaldi 7.7 для Android.
Недавно в ходе рутинной разведки угроз я наткнулся на необычную фишинговую страницу, которая комбинирует социальную инженерию и коварный payload под видом обычной JPEG-картинки, убеждая пользователя самостоятельно выполнить вредоносный код.
В типичных сценариях злоумышленники пытаются заставить жертву скачать исполняемый файл из сети — но тут всё хитрее. Страница прячет в кэше браузера вредоносный файл, замаскированный под изображение, а затем просит жертву выполнить «безобидную» команду, которая извлекает payload из кэша. В результате получаем локальный запуск кода, который не фиксируется средствами сетевого мониторинга.
По сути, атака умело сочетает две техники: принуждение к локальному исполнению (ClickFix/FileFix) и контрабанду кэша (Cache Smuggling). В статье я подробно разберу каждый из этих приемов и покажу, как можно сделать доставку полезной нагрузки еще более незаметной.
Ваш браузер — это окно в интернет или двустороннее зеркало? По умолчанию многие из них спроектированы как настоящие терминалы для сбора данных.
Внутри статьи — детальный разбор телеметрии, оценка уровня шпионажа и, самое главное, исчерпывающее практическое руководство. Вы узнаете, как превратить Firefox в крепость с помощью about:config и настроить AdNauseam для тотальной блокировки слежки. Пора вернуть контроль над своей приватностью.
