Браузеры

Недавно выяснилось, что довольно легко на смартфоне (Android) передать IP VPS в РКН с учеом следующих вещей:

1. Многие российские сервисы превращаются в филиалы РКН.

2. Приложение на Android может получить список сетевых интерфейсов на устройстве через NetworkInterface/ConnectivityManager. После чего обнаружить IP-адрес путем выполнения сетевого запроса через найденный интерфейс: curl -shttps://ifconfig.me/ip --interface $interface либо найдя запущенный socks5 прокси без авторизации. И от этой проблемы страдают большинство клиентов

Но как обстоят дела на desktop?

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

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

Этот термин состоит из конкатенации двух слов: hash и tag. Hash - это прежде всего понятие про уникальность с шифрованием.

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

Такие функции не всегда могут однозначно давать уникальные ответы в виде строк, поэтому существуют так называемые коллизии.

Короче, здесь главный приоритет - уникальность, "не как у других".

Тег, или тэг - это обозначение какой-то метки.

В HTML используются теги верстки, в разработке через систему контроля версий тегами помечали стабильную версию кода. tag-1.2.3

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

dc.send(file) не означает, что файл уже доставлен. Между отправкой и реальной доставкой – буфер, relay, запись на диск, ACK, reconnect и потерянный после refresh File. Разбираю шесть production-проблем WebRTC-файлообмена, которые обычно остаются за пределами туториалов.

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

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

Хотя на практике браузер давно уже не просто программа для просмотра сайтов. Это рабочий шлюз ко всему: внутренним системам, облачным службам, корпоративной почте, документообороту, административным панелям, порталам, личным кабинетам и множеству других сервисов, через которые в компании реально проходят данные и процессы. Именно об этом я недавно писал в BIS Journal, где попытался показать браузер как важное, но часто недооценённое звено корпоративной кибербезопасности.

Для меня эта тема не случайна. Раньше я занимался развитием продукта X-Config в Spacebit — решения, связанного с безопасностью конфигураций программного обеспечения. Тогда мне пришлось довольно глубоко погрузиться в саму логику безопасной настройки: как появляются профили, как они согласуются, где заканчивается методология и начинается ручная рутина, почему даже хорошие требования без нормального инструментария быстро превращаются в набор разрозненных действий. В интервью для «Банковского обозрения» мы как раз обсуждали профили безопасного конфигурирования, роли специалистов по ИБ и администраторов, а также то, что такие профили должны жить не как памятка в PDF, а как часть управляемого процесса.

Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.

Почему-же тогда по Хабру гуляют, кхм… некие одиозные личности (не будем показывать пальцем) и рассказывают нам про то, что веб-компоненты это ужас-ужас и полный провал? Давайте разберемся.

Если у вас есть собственный сайт — вы наверняка проверяли его работу с телефона. Открыли, полистали, остались довольны: «Всё летает». Но это не гарантия, что так же быстро сайт загрузится у ваших посетителей.

Представьте: пользователь заходит на ваш сайт с iPhone (неважно, нового или трёхлетней давности) — и страница зависает, изображения грузятся по одному, скролл дёргается. Через 5–10 секунд он просто закрывает вкладку и уходит к конкурентам. Проблема не в вашем телефоне или интернете, а в скрытых особенностях браузера Safari и устройств iOS.

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

Привет, Хабр. Расскажу, как устроен мой сайд-проект — пиксельная аркада Прикольня, где у каждой компании друзей своя 3D-квартира с мебелью, аватарами и контентом на стенах. Под капотом — Next.js 16, Three.js через React Three Fiber, WebSocket-мультиплеер и PWA. Без единого .glTF файла — вся мебель процедурная.

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

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

Vivaldi 7.9 решает эту проблему самым очевидным образом.

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

Я разобрала, как с помощью ИИ-агента Claude Cowork и расширения для Chrome автоматизировать работу в браузере и освободить время для более важных задач.

Внутри - 10 готовых сценариев, которые можно применить уже сегодня.

Настройка электронной подписи (ЭП) в Linux — это всегда приключение. Но попытка завести плагин Госуслуг на свежей Ubuntu 24.04 LTS превращается в настоящий хардкорный квест. Официальные инструкции безнадежно устарели, инсталляторы выдают ошибки, а техническая поддержка обычно разводит руками.

В этой статье я пошагово разберу, как заставить всё это работать, когда «всё против вас»: от конфликтов OpenSSL 3.0 до капризов Wayland и Native Messaging.

Привет, Хабр!

Меня зовут Алекс, и я мейнтейнер Symbiote.js - библиотеки для создания UI-компонентов и изоморфных приложений на самых современных веб-стандартах. Сегодня я расскажу про наше важное мажорное обновление - версию 3.x.

Браузер — основная рабочая среда QA-инженера, но стандартные DevTools не всегда удобны для повседневных проверок. В этой статье собраны 10 полезных расширений Chrome, которые помогают быстрее проверять верстку, отслеживать визуальные изменения, анализировать ссылки, работать с API и генерировать тестовые данные. Подборка ориентирована на практическое использование и подойдёт как manual-, так и automation-QA.

12 февраля 2026 года я получил фишинговое письмо, замаскированное под уведомление Google Drive от юридической фирмы White & Case LLP. Вместо обычного credential harvesting за ссылкой скрывалась профессиональная система browser fingerprinting с anti-analysis cloaking. Рассказываю, как устроена атака изнутри — от email до перехваченного POST-запроса с эксфильтрированными данными.

Ты понимаешь, что баг хорош, если первым делом думаешь: «Как это вообще может происходить?»

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

Разумеется, сначала я обвинил в этом React.

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

Чтобы подтвердить свою теорию, я рассказал Claude¹, что загрузка дэшборда тормозит и что проблемы наверняка в React, попросив проанализировать их и ранжировать по степени серьёзности. Конечно же, Claude обнаружил в React кучу подозрительных аспектов — ненужный повторный рендеринг, отсутствующие мемоизации и так далее. К тому же он подсказал, что мы всё ещё не используем React Compiler. Я попросил Claude выполнить первый проход решения самых простых и самых серьёзных проблем React, но…

Практически ничего не поменялось. Возможно, дело всё-таки не в React.

Итак, я закатал рукава и начал тщательное расследование.

Notte — платформа для автоматизации браузера. Недавно мы выпустили CLI, который позволяет управлять браузерными сессиями, запускать AI-агентов, извлекать структурированные данные и развёртывать функции автоматизации — всё это прямо из терминала.

В этой статье разберём, что он умеет и как устроен.

Какую проблему мы решали

Большинство рабочих процессов автоматизации браузера начинаются локально. Вы пишете скрипт на Playwright или Puppeteer, он работает на вашей машине, а затем вы тратите время на его переработку под продакшн.

Notte CLI подключается напрямую к облачным браузерным сессиям. Браузер запущен не у вас — он работает у нас. Это означает, что то, что вы делаете в терминале, в точности совпадает с тем, что будет работать в продакшне.

Как работают сессии

Весь CLI построен вокруг сессий. Сессия — это живой экземпляр браузера (headless или headed), запущенный в облаке.

Запустить её можно так:

notte sessions start --headless

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

При запуске сессии поддерживается широкий набор настроек: кастомные viewport'ы, user agent'ы, ротация прокси, решение капч, файловое хранилище, переопределение CDP URL и сохранение профиля браузера.

Видимость

При запуске headless-сессии в выводе появляется viewer URL. Откройте его в браузере — и вы наблюдаете за живой сессией в реальном времени, пока команды выполняются в терминале. Удобно для отладки без переключения в отдельный интерфейс.

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

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

Firecrawl выкатили решение — Browser S andbox. И это уже инфраструктурный подход, а не «девтул».

Статья про то как контролировать загрузку статики у себя в продакшн сборке и предотвратить сайд-эффекты.

Меня зовут Сергей Игнатенко. В прошлой жизни — девлид, 20+ лет в разработке, от C# до Kafka. Сейчас — фаундер. Эта статья про то, как первое привело ко второму.

Последний год я активно работал в Cursor — IDE с ИИ-ассистентом. И в какой-то момент меня начало подбешивать.

Cursor переименовал режим «Code» в «Agent». Звучит красиво, но по факту — это тот же автокомплит на стероидах. Никакой автономности. Никакого планирования. Ты по-прежнему сидишь в IDE, по-прежнему руками переключаешь файлы, по-прежнему сам решаешь что делать дальше. Какой же это «агент»?

Тогда я решил попробовать Claude Code — инструмент от Anthropic, о котором в тот момент восторженно писал весь Twitter. Установил, столкнулся с блокировками (я в России, привыкли), пошёл к Claude с просьбой помочь обойти защиту. Claude сказал категорическое «нет» и добавил фразу, которая засела в голове:

Когда заходит разговор про WebAssembly, где-нибудь в начале дискуссии обычно появляется комментарий в духе «А что, собственно, произошло?»

Этот язык преподносили как нечто поворотное. Неужели это просто был яркий маркетинг? А может, очередной случай с обречённым на провал апплетом JVM?

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