Re: [DISCUSS] Opt-in, anonymous usage telemetry for JMeter

[Milamber <mi...@apache.org>]

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 privacy@apache.org for review,
> and finally to VOTE if the change is significant.
>
> Looking forward to your thoughts.
>
> Thanks,
> Vladimir
>

Re: [DISCUSS] Opt-in, anonymous usage telemetry for JMeter

[Milamber <mi...@apache.org>]

Hi Antonio,

My suggestion is to conduct a survey instead of implementing telemetry in
JMeter directly.

We could potentially reconsider telemetry after reviewing the survey
results, especially if we include a question asking users whether they
would find such a feature useful or not.

Regarding GDPR, I agree that this is indeed a critical issue that we must
monitor closely.

Regards,

Milamber


Le mar. 2 juin 2026 à 15:33, Antonio Gomes Rodrigues <ra...@gmail.com> a
écrit :

> 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 <mi...@apache.org> 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 privacy@apache.org for
> > review,
> > > and finally to VOTE if the change is significant.
> > >
> > > Looking forward to your thoughts.
> > >
> > > Thanks,
> > > Vladimir
> > >
> >
> >
>

Re: [DISCUSS] Opt-in, anonymous usage telemetry for JMeter

[Antonio Gomes Rodrigues <ra...@gmail.com>]

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 <mi...@apache.org> 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 privacy@apache.org for
> review,
> > and finally to VOTE if the change is significant.
> >
> > Looking forward to your thoughts.
> >
> > Thanks,
> > Vladimir
> >
>
>