Телеметрия выключена. Кто еще ходит в сеть из вашей IDE

telemetry. telemetryLevel=off - самая популярная галочка приватности в редакторе. Она честно выключает три класса событий самой платформы VS Code: crash reports, error telemetry и usage data. И на этом ее действие заканчивается.

За пределами настройки остаются обновления, каталог расширений, Settings Sync, проверка лицензии, Git, реестры пакетов, схемы, webview, сами расширения и запрос к AI-провайдеру. Эти каналы не управляются флагом телеметрии платформы, потому что решают другие задачи.

Обратный вывод — «значит, любая IDE все равно все сливает» — ровно так же неверен. Обычная проверка обновлений не требует исходного кода. Факт TLS-соединения не доказывает отправку файла. А конкретная сборка в конкретном сценарии может не создать ни одного соединения: в трех 60-секундных запусках холодного старта я получил ноль наблюдаемых TCP/UDP-событий при работающем положительном контроле на том же измерительном пути.

Поэтому вопрос «есть ли в IDE телеметрия» бесполезен. Работает другой:

Какой процесс, после какого события, к какому получателю и какой состав данных отправляет?

Дальше — рамка, карта каналов, методика на пять уровней и результат для моей сборки Xynapse IDE: 0 событий Sysmon Event ID 3, 19/19 подтвержденных мер и 5/5 найденных границ применимости этого нуля.

Сначала рамка, иначе разговор скатится в «слив»

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

telemetry=off - утверждение о классе событий

Документация VS Code делит телеметрию на crash reports, error telemetry и usage data и отдельно предупреждает: расширения могут собирать собственную телеметрию и не обязаны подчиняться глобальной настройке редактора. На той же странице перечислены другие online services — обновления продукта, поиск и обновление расширений, Settings Sync, Natural Language Search, обращения встроенной поддержки npm и TypeScript к реестру пакетов. Их существование не противоречит выключенной телеметрии: это другие функции.

У JetBrains разделение такое же. Data Sharing описывает usage statistics, а настройки HTTP Proxy влияют в том числе на загрузку плагинов, проверку лицензии и синхронизацию настроек. AI Assistant идет третьим независимым маршрутом: чтобы облачная модель ответила, ему нужно отправить запрос и части кода провайдеру.

Есть и нюанс версии. Документация IntelliJ IDEA говорит, что отправка usage statistics в release-сборках по умолчанию выключена, а в EAP включена. Значит, ответ «у JetBrains это выключено» без указания канала релиза неполон.

Уровни all, error, crash и off в VS Code показывают, что crash report и usage data стоит проверять раздельно, даже когда ими управляет один переключатель.

telemetry=off — утверждение о классе событий, а не обещание офлайн-режима.

Что видно, даже если содержимое зашифровано

Абсолютное «любая IDE всегда что-то отправляет» неверно: редактор запускается без сети, локальная модель не требует внешнего API. Но если соединение состоялось, невидимым оно уже не будет:

• удаленный сервер видит адрес клиента или выходного прокси;

• ОС знает процесс, оба адреса и время соединения;

• сеть на участке видит следующее назначение, время, направление и объем;

• DNS-запрос может раскрыть доменное имя резолверу, если не защищен отдельно;

• TLS скрывает содержимое запроса от промежуточных узлов, но не сам факт обмена;

• конечный сервис получает то, что нужно для выполнения запроса: идентификатор версии, поисковую строку каталога или prompt и контекст для модели.

Обратное правило важнее. По IP-адресу нельзя восстановить payload. По факту TLS-соединения нельзя утверждать, что ушел исходный код. Для такого вывода нужны логи приложения, документация протокола, контролируемый прокси или анализ клиента.

Карта каналов

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

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

Три строки заслуживают комментария сверх таблицы.

Расширения — отдельный домен доверия. Расширение исполняется внутри доверенной среды редактора и может иметь собственные online services. Глобальный флаг телеметрии платформы не является сетевой песочницей для стороннего кода.

Settings Sync — функциональная передача чувствительных данных. В VS Code синхронизируются settings, keyboard shortcuts, user snippets, user tasks, UI state, extensions и profiles; после входа это происходит в фоне, отдельные категории исключаются. Это не скрытая аналитика, но список расширений и пользовательские snippets могут быть чувствительными. Аудит фиксирует не только факт входа, но и выбранные категории.

Дочерние процессы. Соединение создает не только главный образ IDE, но и git.exe, language servers, пакетные менеджеры и extension host. Встроенная поддержка npm и TypeScript в VS Code, по документации, может обращаться к registry.npmjs.org. Запрос имени пакета — не отправка файла, но он раскрывает используемую технологию или зависимость.

Что уходит из AI-IDE

AI-функция отличается от проверки обновлений тем, что полезная нагрузка часто и есть рабочий контекст. Минимум — prompt пользователя. Чтобы ответить по проекту, ассистент может добавить:

• выделенный фрагмент;

• активный файл и соседние участки кода;

• явно прикрепленные файлы и папки;

• дерево репозитория и результаты поиска;

• диагностику компилятора и language server;

• Git diff, commit или историю изменений;

• вывод терминала, тестов и других инструментов;

• правила проекта и историю текущего диалога.

Слово «может» здесь принципиально: поведение одного плагина не переносится на все AI-IDE. JetBrains, например, пишет, что AI Assistant отправляет запросы и части кода и может добавлять типы файлов, используемые frameworks и иной необходимый модели контекст; там же есть команда для просмотра текущего ai-assistant-requests.md.

Потоков данных два, и они независимы. Первый — рабочий запрос к модели: без него облачная функция не выполнится, внутри prompt и выбранный контекст. Второй — продуктовая аналитика самой AI-функции: метрики использования, ошибки и, при отдельном согласии, более подробные данные. Отключение второго не отменяет первый. Локальная модель убирает внешний рабочий запрос, но плагин все еще может отправлять usage telemetry.

Практический критерий: интерфейс AI-IDE должен отвечать на четыре вопроса — какой провайдер получит запрос, какие файлы вошли в контекст, какие инструменты доступны агенту и где посмотреть фактический запрос.

Как проверять поведение, а не настройки

Галочка в UI доказывает намерение разработчика, а не поведение релиза.

Уровень 1. Зафиксировать объект. Версия, канал, ОС, архитектура, способ установки, список расширений. Для своего продукта - commit, размер и SHA-256 бинарника. Иначе результат не привязан к артефакту.

Уровень 2. Разделить сценарии. Один запуск не отвечает на все вопросы.

Разрешенные и запрещенные классы соединений задаются до теста. Иначе после теста ожидаемым объявится любой увиденный домен.

Уровень 3. Связать сеть с процессом. IDE — семейство процессов: renderer, shared process, extension host, language servers, дочерние CLI. Нужна корреляция с PID и деревом процессов, а не только packet capture. В Windows один из вариантов — Sysmon: Event ID 3 фиксирует TCP/UDP-соединение с образом процесса и адресами, Event ID 1 восстанавливает создание процессов, Event ID 22 - DNS-запросы.

<Sysmon schemaversion="4.90">
  <HashAlgorithms>sha256</HashAlgorithms>
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <Image condition="end with">Xynapse.exe</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

Это минимальный пример фильтра по одному образу, а не конфигурация полного аудита: он не собирает ProcessCreate и DnsQuery и не видит helper-процессы с другими именами. Для полноценной проверки дерево связывают по ProcessGuid и дополняют наблюдение Windows Filtering Platform/ETW, прокси или packet capture.

Уровень 4. Проверить измеритель. Ноль без положительного контроля не доказывает ничего. Тем же путем сбора создается разрешенное тестовое соединение. Если событие не появилось, ноль означает ошибку фильтра, а не тишину в сети.

Уровень 5. Сопоставить runtime с исходниками и сборкой. Исправленный TypeScript не гарантирует, что новая версия попала в дистрибутив. Runtime-трасса отвечает на «что произошло», аудит исходников и bundle - на «почему этот путь был или не был достижим».

Кейс: Xynapse IDE

Xynapse - моя сборка на базе Code-OSS/Electron с адаптированным open-source runtime Continue, адаптерами YandexGPT и GigaChat и многоролевым планировщиком. Полную офлайн-работу я не доказывал: для облачной модели, Git, обновлений и каталога расширений сеть нужна по определению.

Проверял я узкое утверждение:

При холодном старте на чистом профиле, без workspace и пользовательских действий, процессы конкретной сборки Xynapse не создают наблюдаемых TCP/UDP-соединений.

Что выключено на уровне продукта

В product.json capability телеметрии запрещена, пользовательский default - off:

{
  "enableTelemetry": false,
  "configurationDefaults": {
    "telemetry.telemetryLevel": "off"
  }
}

В Workbench и Shared Process я заменил активные реализации на NullTelemetryService, в Shared Process также использую NullAppender. Эксперименты по умолчанию выключены, исполняемые регистрации Settings Sync удалены, рекомендации расширений переведены с инициализации при старте на отложенную.

Ассистента проверял отдельно: его общий telemetry facade работает как no-op, фабрика team analytics не выбирает внешний provider, opt-out проходит через настройки IDE и локальную конфигурацию ассистента. Наличие совместимого аналитического кода в исходниках доказательством активного маршрута я не считал — проверял достижимость отправителя в собранном bundle.

Объект и результат

• Xynapse 1.108.0;

• публичный commit 5f01a9fb0fdebc2a40c7843552c18aad189a0453;

• Windows 10 Pro 10.0.19045, Sysmon 15.21;

• размер Xynapse.exe: 210 825 216 байт;

• SHA-256: 20e1208038440b7795ecd9d4365a42ae961a87b20f8ff84f167306b2f50a447b;

• три независимых запуска по 60 секунд;

• 49 проверок жизнеспособности и 11 уникальных PID Xynapse в каждом запуске, всего 147 выборок активности процесса;

• Sysmon Event ID 3 для Xynapse: 0 во всех трех запусках;

• положительный контроль тем же измерительным путем: 2 события;

• статический аудит: подтверждены 19/19 заявленных мер, отдельно найдены и записаны 5/5 запланированных границ применимости.

Счетчик 49 — это опросы, подтверждающие, что семейство процессов Xynapse оставалось активным в течение каждого окна. Сетевые события Sysmon собирались событийно, а не с частотой этих опросов; 147 — сумма проверок активности за три запуска.

Что этот ноль не значит. Он относится только к этому бинарнику, этой ОС, чистому профилю и 60-секундному холодному старту. Он не доказывает отсутствия DNS, редкого отложенного таймера, соединения helper-процесса с другим именем или трафика при вызове пользовательской функции.

Границы обещания

Статический аудит обязан находить не только защиты. В проверенной версии остались:

1. действия ручного обновления;

2. GitHub как настроенный источник релизов;

3. внешний URL-template для webview content;

4. совместимый default allowAnonymousTelemetry=true, который в этой сборке блокируется последующими gates и no-op-реализацией;

5. activation event ассистента onStartupFinished как потенциальная точка регрессии.

Холодный старт не покрывает запросы к YandexGPT и GigaChat, Git, каталог расширений, ручной updater и webview. Для них нужны отдельные сценарии со своими allowlist и проверкой состава данных.

От разового теста к release gate

Следующий шаг — прогонять матрицу на каждом релизе. Контракт может выглядеть так:

cold-start:
  allowed: []

model-yandex:
  allowed: [documented YandexGPT auth and generation endpoints]

model-gigachat:
  allowed: [documented OAuth and generation endpoints]

git:
  allowed: [the configured test remote]

extensions:
  allowed: [the documented gallery and artifact CDN]

update:
  allowed: [the configured release source]

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

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

Чек-лист на десять минут

1. Пройдите настройки по словам telemetry, data sharing, crash, experiments, updates, sync, proxy.

2. Просмотрите список расширений: у каждого своя политика и свои endpoints.

3. Выясните, какие категории уходят в sync после входа в аккаунт.

4. Для AI найдите настройки провайдера, контекста, code sharing и журнал фактических запросов.

5. Запустите IDE на чистом профиле и смотрите соединения по процессам, а не общим packet capture. Затем повторите после открытия проекта, каталога, Git и AI-чата: это разные сценарии.

6. Сделайте положительный контроль, прежде чем поверить нулю. Не делайте выводов о составе данных по домену или IP.

Вывод

Для самой платформы выключенная телеметрия означает, что она не отправляет usage, error и crash events разработчику продукта. Сторонние расширения требуют отдельной проверки. Офлайн-режимом эта настройка не является и не управляет обновлениями, Git, sync, реестрами пакетов, webview и AI-провайдерами.

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

На Xynapse я получил ноль наблюдаемых TCP/UDP-событий в жестко ограниченном тесте холодного старта и работающий положительный контроль. Результат полезен именно потому, что не выдается за абсолютный: остальные каналы перечислены и проверяются отдельно.

Для IDE, которая работает с закрытым исходным кодом, лучший privacy claim — не «мы ничего никогда не отправляем», а воспроизводимая карта разрешенного исходящего трафика для каждого сценария и каждого релиза.

Источники

Документация проверена 15 августа 2026 года.

• Telemetry in Visual Studio Code

• Network Connections in Visual Studio Code

• Settings Sync in Visual Studio Code

• IntelliJ IDEA: Data Sharing

• IntelliJ IDEA: HTTP Proxy

• JetBrains AI Assistant: Data handling

• Microsoft Sysmon

• Sysmon events

• Исходный код Xynapse