Hi Why launching a survey if telemetry is off by default? However, a quick warning regarding GDPR (Europe)
Le lun. 1 juin 2026 à 20:21, Milamber <[email protected]> a écrit : > Hi Vladimir, > > This proposal is indeed very interesting and aligns well with the models > used by the project Airflow with ASF Matomo. > > However, I would like to raise a point of caution: some large > organizations have strict security policies that prohibit the > transmission of any telemetry data, even on an opt-in basis. > > As an initial step, perhaps we could consider launching a survey (using > a tool like Google Forms) to gather feedback on JMeter usage, desired > features, and potentially obsolete elements. > > Additionally, we could include questions within that survey specifically > about this opt-in telemetry proposal to gauge whether users find it > useful, neutral, or if they are fundamentally against it. > > Regards, > Milamber > > > On 28/05/2026 13:27, Vladimir Sitnikov wrote: > > Hi all, > > > > I would like to gauge the community's appetite for adding **opt-in, > > anonymous usage telemetry** to JMeter. Nothing is built yet, and nothing > > would be built without rough consensus here first and sign-off from the > ASF > > Privacy Committee. This thread is to test the idea and shape the data we > > would collect. > > > > ## Why > > > > We make maintenance decisions with little evidence about how JMeter is > > actually used. Telemetry would let us: > > > > - see which samplers, controllers, and other elements people use, so we > can > > prioritise effort and retire dead features with data rather than > guesswork; > > - learn which Java and OS versions are still in the field, so we can set > > minimum-version policy responsibly; > > - measure how widely each UI locale is used, so translation effort goes > > where it helps; > > - understand how often tests run from the GUI versus the CLI, and at what > > scale. > > > > ## Principles > > > > The proposal is privacy-first by design: > > > > - **Opt-in, off by default.** Telemetry starts only after the user gives > > explicit consent. We also honour the `DO_NOT_TRACK` environment variable > > and a JMeter property to disable it. > > - **Headless and CI stay silent.** Non-GUI runs cannot prompt for > consent, > > so telemetry is off there unless a property explicitly enables it. > > - **No content, ever.** We never send property values, element or > test-plan > > names, file paths, hostnames, IP addresses, target URLs, or any free > text. > > - **Built-in identifiers only.** Third-party and custom classes, > functions, > > and property keys are mapped to `other` or dropped, so no proprietary > > package names leak. > > - **ASF infrastructure.** Data would go to the Foundation's > GDPR-compliant > > Matomo instance, with IP anonymisation, not to any third party we run. > > - **Transparent and auditable.** The payload schema is versioned and > > documented, and the user can log the exact payload before it is sent. > > > > ## What we would collect > > > > | Field | Type | Example | Why it is not personal data | > > |---|---|---|---| > > | `schema_version` | string | `1` | Constant, set by us. | > > | `jmeter_version` | string | `5.6.3` | Public release identifier. | > > | `run_mode` | enum | `gui`, `cli` | Coarse mode flag. | > > | `os_family` | enum | `linux`, `windows`, `macos` | Family only; no > build > > number. | > > | `java_runtime` | string | `Temurin 17` | Vendor and major version > only. | > > | `ui_locale` | string | `ru`, `de` | Language tag; no free text. | > > | `testplan_size_bucket` | enum | `10-100` | Bucketed element count. | > > | `thread_count_bucket` | enum | `100-1000` | Bucketed scale of the > test. | > > | `distributed` | bool | `false` | Whether remote testing is used. | > > | `builtin_element_counts` | map | `{HTTPSamplerProxy: 12}` | Counts per > > built-in class only. | > > | `builtin_function_counts` | map | `{__counter: 3}` | Built-in functions > > only. | > > | `modified_property_keys` | set | `[HTTPSampler.method]` | Keys of > changed > > built-in properties only. Values are never sent; unknown keys are > dropped. | > > | `run_count` | int | `4` | Test runs in the session. | > > > > ## What we would never collect > > > > Property values, element and test-plan names, file paths, hostnames, IP > > addresses, target URLs, credentials, custom or third-party class names, > > custom property keys, and any free text. The block list is enforced by an > > allowlist of built-in identifiers, not by a denylist. > > > > ## Open questions for the community > > > > 1. Is opt-in telemetry something the project wants at all? > > 2. Does the schema above cover what would actually help us, and is > anything > > in it more than we need? > > 3. How should we count distinct installs for questions such as locale > > adoption? A pseudonymous identifier is still personal data under GDPR, so > > the options range from no stable identifier and approximate counts to a > > rotating, salted per-day identifier. Input from anyone with GDPR > experience > > is welcome. > > 4. Where should the consent prompt live, and how do we make opting out > > obvious? > > > > If there is interest, the next steps are to refine the schema here, then > > take the mechanism and the GDPR specifics to [email protected] for > review, > > and finally to VOTE if the change is significant. > > > > Looking forward to your thoughts. > > > > Thanks, > > Vladimir > > > >
