The telemetry data content in Visual Studio Code

by

Summary

This postmortem analyzes a common enterprise issue: misunderstanding how Visual Studio Code telemetry works and how to lock telemetry settings for managed deployments. The confusion often leads to privacy concerns, Works Council escalations, and inconsistent developer environments.

Root Cause

  • Ambiguous interpretation of VS Code’s telemetry categories, especially the “all” level.
  • Lack of clarity on what data is pseudonymized and what is not.
  • Incorrect assumptions about GDPR compliance without reviewing Microsoft’s documentation.
  • Unawareness of VS Code’s built‑in mechanisms for locking settings via policy or configuration files.

Why This Happens in Real Systems

  • Telemetry is a loaded term in enterprise environments, often associated with employee monitoring.
  • Developers assume telemetry includes personal data, even when the product explicitly avoids collecting it.
  • VS Code is highly customizable, so organizations expect a centralized policy system similar to browsers or OS‑level MDM.
  • Documentation is scattered, making it easy to miss the parts about machine‑level settings and policy locking.

Real-World Impact

  • Deployment delays due to Works Council or Data Protection Officer reviews.
  • Inconsistent telemetry configurations across developer machines.
  • Unnecessary disabling of harmless telemetry, reducing product insights.
  • Increased support load when users override settings that should have been locked.

Example or Code (if necessary and relevant)

Below is an example of how organizations typically lock VS Code settings using a machine‑level settings.json:

{
  "telemetry.telemetryLevel": "off"
}

And an example of a policy‑style lock using product.json overrides:

{
  "configurationDefaults": {
    "telemetry.telemetryLevel": "all"
  }
}

How Senior Engineers Fix It

  • Clarify telemetry categories:
    • Error telemetry: crash dumps, stack traces (pseudonymized).
    • Usage telemetry: feature usage counts, extension activation events.
    • No personal content: no source code, no file names, no keystrokes.
  • Confirm pseudonymization: VS Code uses machine‑generated identifiers, not user identity.
  • Map telemetry to GDPR principles:
    • Data minimization
    • Purpose limitation
    • Pseudonymization
  • Provide Works Council documentation summarizing:
    • No employee monitoring
    • No behavioral profiling
    • No personal identifiers
  • Lock settings at deployment time using:
    • System‑level settings.json
    • product.json overrides
    • Preconfigured installation images
  • Verify immutability by testing that users cannot override the locked setting.

Why Juniors Miss It

  • They assume telemetry = spying, without reading the spec.
  • They don’t know about machine‑level configuration files VS Code supports.
  • They focus on user‑level settings, unaware that enterprise deployments require policy enforcement.
  • They don’t understand GDPR terminology, leading to unnecessary fear or over‑restriction.
  • They don’t test override precedence, so they miss how VS Code resolves conflicts between user, workspace, and machine settings.

Leave a Comment