DevPace
БлогСправкаНовостиСкачатьДемоТарифыПривязка устройстваВойтиНачать

Открытый код агента DevPace: не верьте на слово, проверьте сами

Когда компания, которая следит за рабочим временем сотрудников, говорит «мы не читаем переписку и не делаем скриншотов» — это звучит как то, во что просто нужно поверить. Мы решили, что этого недостаточно, и сделали шаг, на который решается мало кто в этой нише: выложили исходный код фонового агента DevPace в открытый доступ — github.com/ak-alz/gla-client. Дальше в статье — не общие слова о прозрачности, а конкретный маршрут: что лежит в репозитории, в каких файлах искать код сбора данных, чем открытый агент отличается от закрытого на практике и как проверить эти утверждения самостоятельно, даже если вы не программист.

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

Ничего не скрыто — именно это и значит открытый код.

Обещание в политике — это только обещание

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

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

Что именно можно проверить

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

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

Где в репозитории искать код сбора данных

Не нужно читать весь репозиторий целиком, чтобы получить ответ на конкретный вопрос — достаточно знать, куда смотреть. Код разбит на отдельные модули (в терминах Rust — крейты), и у каждого своя узкая роль:

Это не абстрактная возможность «в теории можно посмотреть» — это конкретные пути внутри одного публичного репозитория, которые можно открыть прямо сейчас. На практике это занимает у человека, знакомого с Rust, минут двадцать: открыть crates/event-contract/src/payload.rs, увидеть там весь список полей одним экраном, затем открыть crates/windows-collector или crates/linux-collector и проследить, что ни в одной функции сбора не появляется ничего, что потом попадало бы в поля payload сверх заявленного. Это не требует знания всего проекта целиком — только умения прочитать один файл и один модуль рядом с ним.

Как проверить сетевой трафик самостоятельно

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

Подойдёт как встроенный в операционную систему монитор ресурсов (диспетчер задач в разделе «Сеть» на Windows, nethogs или аналог на Linux), так и специализированный прокси для анализа трафика. Смотреть стоит на две вещи: как часто агент вообще выходит в сеть и какого объёма пакеты при этом отправляет. Периодическая отправка небольшого пакета данных (по размеру — сопоставимого с текстовым сообщением, а не с изображением) хорошо согласуется с заявлением «мы передаём категории и счётчики». Регулярная передача пакетов, по размеру характерных для скриншотов или видео, была бы прямым противоречием этому заявлению — и её было бы видно даже без расшифровки самого содержимого трафика, просто по объёму данных.

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

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

Кросс-платформенность — тоже не просто слова

Агент собран на Rust и работает на Windows и Linux — это не абстрактный маркетинговый тезис, а конкретная вещь, которую видно прямо в структуре репозитория: отдельные модули под каждую платформу, общая логика сбора категорий и общий протокол отправки данных. На Linux с GNOME (Wayland), где активное окно нельзя узнать штатным системным способом, для этого написано отдельное небольшое расширение GNOME Shell — весь его код меньше 60 строк и читается целиком за пару минут, а по внутреннему протоколу оно отдаёт ровно то же самое, что X11 и Hyprland отдают на своих системах: идентификатор приложения и номер процесса, ничего больше. Для компании это означает, что заявление «поддерживаем обе ОС» — не рекламная строчка, а код, который можно скомпилировать и запустить самостоятельно, не дожидаясь релиза.

Открытый код против закрытого: что это меняет на практике

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

В открытом репозитории тот же вопрос имеет конкретный ответ: можно посмотреть историю изменений конкретных файлов — тех же normalization или event-contract — и увидеть, добавлялось ли туда что-то новое между версиями, а не просто поверить описанию в release notes. Это не разовая проверка «прочитал один раз и успокоился», а постоянно доступная возможность, которая никуда не девается с новой версией агента.

Если вы хотите системно проверить не только DevPace, а вообще любой инструмент учёта рабочего времени, который рассматриваете или уже используете в компании, — в материале «Bossware: что такое ПО для слежки за сотрудниками» есть подробный чек-лист именно для этого: какие вопросы задавать вендору, на какие классы инвазивности делятся такие программы и как отличить учёт времени по категориям от полноценной слежки за содержимым. Принцип там тот же самый, что и в этой статье, — просто сформулирован не для одного конкретного агента, а для рынка в целом.

Как это проверить, если вы не программист

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

Есть и дополнение внутри самого продукта, не требующее чтения кода вообще: вкладка «Конфиденциальность» в профиле показывает точный текст действующего согласия на обработку данных и позволяет выгрузить свои же накопленные данные в файл — можно сверить содержимое выгрузки с тем, что обещано, без единой строчки Rust. А что происходит с этими данными при отзыве согласия — отдельно и подробно разобрано в статье «Отзыв согласия — это удаление данных, а не галочка в настройках».

Итог

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

Код агента открыт и доступен для изучения по адресу github.com/ak-alz/gla-client — проверьте эти слова сами, покажите репозиторий тому, кто разбирается в коде лучше вас, или просто сравните объём сетевого трафика с перечнем полей из event-contract. А чтобы увидеть, что показывает сам продукт, а не только его код, — Посмотреть демо и посмотрите на данные, которые агент реально собирает про ваш собственный день.

Смотрите также

Опубликовано: 27 июня 2026 г.