Около десяти лет я занимаюсь русской локализацией Mozilla и сейчас возглавляю это направление. За это время я неоднократно наблюдал Firefox с точки зрения пользователей, сообщества, а также перевода интерфейса и документации. Однако в корпоративной среде браузер выглядит совершенно иначе. Там он не просто приложение для просмотра сайтов, а элемент рабочего места, через который проходят почта, внутренние системы, облачные сервисы, порталы, административные панели и множество других критически важных процессов.
Когда речь заходит о безопасности рабочего места, обычно вспоминают операционную систему, антивирус, средства защиты конечных устройств, контроль устройств, почту и сетевой периметр. Браузер часто остаётся на втором плане: «ну, его тоже нужно как-то настроить». На практике же именно браузер становится одним из самых уязвимых клиентских приложений. Он работает с данными, авторизацией, расширениями, загрузками, сертификатами, прокси, паролями, обновлениями, внешними сервисами и внутренними порталами.
У Firefox для этого предусмотрены корпоративные политики. Их можно описывать в policies.json, распространять по рабочим станциям и получать управляемый браузер. Но между утверждением «политики существуют» и тем, что «администратор или специалист по информационной безопасности может уверенно сопровождать их в реальной организации», лежит огромная пропасть.
Так появился Browser Policy Manager — свободный продукт под лицензией MPL-2.0 для управления корпоративными политиками Firefox.
Откуда возникла идея
Идея возникла не вчера. Впервые я задумался о создании отдельного инструмента для управления политиками Firefox примерно восемь лет назад.
Причин было несколько.
Во-первых, вручную писать и сопровождать policies.json неудобно. На уровне небольшого примера это кажется простым: открыть документацию, взять несколько политик, собрать JSON, поместить файл в нужное место. Но в реальной работе быстро возникают вопросы: почему выбраны именно эти настройки, что изменилось между версиями, можно ли сравнить два варианта, какие параметры относятся к безопасности, какие требуют согласования, какие появились только в новых версиях Firefox.
Во-вторых, вокруг корпоративных настроек Firefox мало удобной информации на русском языке. Сами возможности браузера есть, документация есть, но практического слоя для администраторов, интеграторов и специалистов по информационной безопасности не хватает. Особенно если человек хочет не просто скопировать готовый файл, а понять, как выстроить нормальный процесс.
В-третьих, мой опыт в информационной безопасности постоянно возвращал меня к теме безопасных конфигураций. В Spacebit я развивал продукт X-Config, связанный с безопасностью конфигураций программного обеспечения. Когда мы рассматривали возможность качественно добавить поддержку Firefox, стало заметно, что информации и инструментов вокруг этой темы недостаточно. Браузер вроде бы распространённый, важный, технически зрелый, но область управления его корпоративными настройками остаётся довольно узкой и фрагментированной.
Изначально я думал о Browser Policy Manager как о коммерческом продукте. Но для такого проекта нужны ресурсы: разработка, методология, документация, проверка на реальных сценариях, продвижение. Инвесторов найти не удалось, и идея осталась лежать в долгом ящике.
Вернулся я к ней уже в другой ситуации. За последние месяцы, находясь в активном поиске работы, я решил, что можно не ждать идеального момента и не пытаться сначала собрать команду. У меня есть предметный опыт, продуктовый опыт, понимание Mozilla и современные инструменты разработки с использованием искусственного интеллекта. Этого оказалось достаточно, чтобы начать создавать продукт самостоятельно.
Почему это не просто генератор JSON
Самый простой путь был бы очевиден: сделать форму, несколько полей, кнопку «Скачать policies.json». Такой инструмент можно написать достаточно быстро. Но в реальной эксплуатации этого мало.
Файл — это последний шаг. До него существует жизненный цикл конфигурации:
создать профиль;
выбрать целевой канал Firefox: Release или ESR;
настроить политики;
проверить результат;
сравнить с другим профилем;
понять, что изменилось;
сохранить версию;
передать коллегам;
выгрузить в policies.json;
при необходимости вернуться и внести изменения.
Поэтому Browser Policy Manager строится не вокруг файла, а вокруг профиля политик. Профиль — это отдельная сущность, у которой есть имя, состояние, версия схемы, набор политик, управляемые настройки, результаты проверки, жизненный цикл и несколько представлений.
Один и тот же профиль можно открыть через мастер, через библиотеку профилей, через сравнение, через полный каталог настроек или через JSON-редактор. Это разные рабочие поверхности, но они должны работать с одним источником данных. Иначе продукт быстро превратился бы в набор разрозненных экранов, где пользователь сам должен помнить, что и где было изменено.
Для меня это было ключевым продуктовым решением: Browser Policy Manager должен быть не «обёрткой над JSON», а рабочей средой для жизненного цикла браузерных конфигураций.
Лицензия и открытость
Проект распространяется под MPL-2.0. Для меня это естественный выбор по нескольким причинам.
Первая причина — связь с экосистемой Mozilla. Browser Policy Manager работает с Firefox, я давно участвую в локализации Mozilla, и сама предметная область проекта близка к этой культуре открытости.
Вторая причина — баланс. Я хотел сохранить продукт свободным, но не уходить в слишком жёсткую модель распространения. MPL-2.0 хорошо подходит для такого случая: продукт можно использовать в корпоративной среде и в производных решениях, но изменения в исходных файлах должны оставаться открытыми в рамках условий лицензии.
Третья причина — прагматичность. Для администраторов и специалистов по информационной безопасности важно, чтобы инструмент можно было проверить, развернуть у себя, адаптировать, встроить в собственные процессы. Закрытый «чёрный ящик» здесь выглядел бы хуже, особенно если речь идёт о настройках безопасности.
Основные вехи развития
Первая публичная версия была скорее проверкой идеи. Нужно было доказать, что из корпоративных политик Firefox можно сделать не просто набор полей, а управляемый профиль.
После MVP появились следующие важные этапы.
Мастер нужен для типовых сценариев. Не каждый пользователь хочет начинать с полного каталога политик или с JSON. Администратору часто нужно быстро собрать понятный базовый профиль: настройки доступа, обновлений, расширений, приватности, безопасности, поведения браузера.
Мастер решает именно эту задачу: он ведёт пользователя по шагам и скрывает избыточную сложность там, где она не нужна.
Когда профиль один, можно жить без библиотеки. Когда их несколько — для разных подразделений, уровней жёсткости, тестовых и рабочих окружений — нужна нормальная точка управления.
Библиотека профилей стала местом, где можно видеть сохранённые профили, открывать их в разных режимах, дублировать, архивировать, восстанавливать, экспортировать и переходить к сравнению.
Сравнение — одна из тех возможностей, которые кажутся необязательными только до первого реального внедрения. В корпоративной среде важно понимать не только текущее состояние, но и различия: между базовым и усиленным профилем, между старой и новой версией, между настройками для разных групп пользователей.
Поэтому в продукте появилась отдельная рабочая поверхность для сравнения профилей. Это не просто техническая таблица, а попытка сделать изменения видимыми и пригодными для обсуждения.
Следующим важным шагом стала поддержка CIS. Для специалистов по информационной безопасности это понятный ориентир: не просто «я включил какие-то настройки», а настройки связаны с рекомендациями по безопасной конфигурации.
Здесь важно не свести всё к кнопке «сделать безопасно». В реальных организациях требования нужно просматривать, адаптировать, иногда принимать исключения. Поэтому поддержка CIS в Browser Policy Manager развивается не как магический набор предустановок, а как часть рабочего процесса: профиль, рекомендации, ручная проверка, источники настроек и дальнейшее сопровождение.
Мастер хорош для типовых сценариев, но он не должен быть потолком продукта. Администратору или специалисту по безопасности иногда нужен полный контроль: найти конкретную политику, посмотреть доступные параметры, включить редкую настройку, проверить, как она будет выглядеть в итоговом policies.json.
Так появился полный каталог настроек Firefox. Но именно здесь проявилась одна из самых сложных продуктовых проблем: полный каталог полезен, пока он не превращается в бесконечную таблицу, в которой всё есть, но работать невозможно.
Эта проблема стала центральной для версии 0.8.8.
Что меняется в 0.8.8
Версия 0.8.8 сейчас находится в разработке и должна выйти примерно через две недели. По основной функциональности это уже близко к состоянию, которое можно считать кандидатом в стабильный выпуск.
Главная задача 0.8.8 — превратить All settings из длинного каталога в рабочую поверхность для настройки и проверки профиля.
Раньше полный каталог решал задачу доступа ко всем настройкам. Но когда в профиле появляются базовые политики, CIS, ручные правки, импортированные параметры и возможные ошибки проверки, пользователю уже недостаточно просто видеть всё подряд. Ему нужно понимать:
что требует внимания;
что уже настроено;
что пришло из базового профиля;
что связано с CIS;
что было изменено вручную;
какие настройки доступны, но ещё не используются;
где есть неподдерживаемые или неизвестные параметры;
как быстро перейти к нужной политике.
Поэтому в 0.8.8 All settings разделяется на несколько режимов.
Review — режим проверки. Он должен показывать в первую очередь то, что требует внимания: ошибки, ручные решения по CIS, неизвестные или импортированные параметры, спорные состояния.
Configured — режим настроенных параметров. Здесь пользователь видит не весь каталог, а то, что уже реально влияет на профиль. Это важно для анализа, согласования и сопровождения.
Catalog — полный каталог. Он остаётся доступным, но больше не является первым экраном для тяжёлого корпоративного профиля.
Это хороший пример того, как продуктовая логика меняет архитектуру интерфейса. Технически можно было просто добавить фильтры к таблице. Но продуктово задача другая: нужно разделить разные намерения пользователя. Проверить проблемные места, посмотреть уже настроенное и найти новую доступную политику — это три разных сценария.
Архитектура: почему именно такой стек
Browser Policy Manager сделан как веб-приложение на FastAPI. Это прагматичный выбор: FastAPI даёт удобный способ строить API, подключать проверку данных, развивать маршруты и при этом не перегружать проект лишней инфраструктурой.
Веб-интерфейс построен на Jinja2 и серверном HTML, а не на отдельном большом приложении на стороне браузера. Это осознанное решение. Для такого продукта важны понятные маршруты, предсказуемая структура, простое развёртывание и возможность одному человеку поддерживать кодовую базу. Отдельный сложный интерфейсный стек добавил бы скорости на отдельных участках, но одновременно увеличил бы число движущихся частей.
Сейчас в продукте есть несколько основных рабочих поверхностей:
библиотека профилей;
мастер создания и редактирования профиля;
сравнение профилей;
полный каталог настроек;
JSON-редактор;
импорт, экспорт и проверка.
Каждая поверхность решает свою задачу. При этом профиль остаётся единым. Это важнее, чем кажется: если мастер, каталог и JSON-редактор начинают жить разной жизнью, пользователь перестаёт доверять инструменту.
Для хранения используется SQLAlchemy, миграции управляются через Alembic, по умолчанию применяется SQLite. Для текущего этапа это разумная комбинация: можно развивать нормальную модель данных, иметь миграции, хранить профили и версии, но не требовать от пользователя отдельной тяжёлой инфраструктуры для первого запуска. При этом архитектура не должна закрывать путь к более серьёзному развёртыванию.
Отдельный слой связан со схемами политик Firefox. Browser Policy Manager должен понимать разные версии Firefox: Release и ESR. Выбранная схема влияет на проверку, доступные элементы интерфейса и итоговый экспорт. Это важно, потому что корпоративная среда часто живёт на ESR, а новые политики появляются в актуальных выпусках Firefox.
Единая модель профиля
Одна из главных архитектурных идей — единая модель профиля.
Пользователь может идти разными путями:
начать с мастера;
импортировать существующий policies.json;
открыть полный каталог;
изменить настройки через JSON-редактор;
сравнить профиль с другим;
выгрузить итоговый файл.
Но все эти действия должны сходиться в одном состоянии. Это позволяет не плодить отдельные «версии правды» для разных экранов.
Такой подход особенно важен для управляемых настроек Firefox. Есть политики, есть Preferences, есть настройки, которые пришли из импорта, есть будущие источники вроде CIS или базовых корпоративных профилей. Если всё это не свести в одну модель, интерфейс быстро станет противоречивым.
В версии 0.8.8 эта идея развивается дальше: для All settings появляется единая модель инвентаря настроек. Она должна описывать настройку не только как строку в таблице, а как объект с типом, категорией, состоянием, источниками, признаками внимания, связью с редактором и результатами проверки.
Иными словами, настройка в интерфейсе должна отвечать не только на вопрос «что это за параметр?», но и на вопросы «почему он здесь?», «откуда он пришёл?», «требует ли внимания?», «где его редактировать?» и «как он попадёт в итоговый файл?».
Почему интерфейс — одна из самых сложных частей
В проектах такого класса легко недооценить интерфейс. Кажется, что сложность в схемах, проверке и экспорте. На самом деле не меньше сложность в том, чтобы не перегрузить пользователя.
У Firefox много корпоративных политик и управляемых настроек. Если просто показать всё, получится справочник. Справочник полезен, но он плохо отвечает на вопросы реальной работы: что уже настроено, что опасно, что требует решения, что изменилось, что надо проверить перед внедрением.
Поэтому в Browser Policy Manager интерфейс развивается вокруг нескольких принципов.
Первый принцип — сначала сводка, потом детали. Пользователь должен сначала увидеть состояние профиля, а не утонуть в длинном списке.
Второй принцип — изменённое важнее доступного. Доступные настройки нужны, но в сопровождении профиля важнее то, что уже влияет на рабочие станции.
Третий принцип — детали по требованию. Длинные объекты, массивы, технические значения и полная JSON-структура должны быть доступны, но не обязаны занимать основной экран.
Четвёртый принцип — разные сценарии должны иметь разные входы. Мастер, библиотека, сравнение, полный каталог и JSON-редактор существуют не потому, что хотелось сделать больше экранов, а потому что у пользователя разные задачи.
Проверка качества
Для продукта, который управляет настройками безопасности, недостаточно принципа «на моей машине работает».
В Browser Policy Manager я держу покрытие кода на уровне 100%. Это не самоцель ради красивой цифры, но полезная дисциплина. Когда проект развивается быстро и значительная часть разработки идёт с помощью Codex