How telemetry works in Baseline Investigator

When telemetry is sent

One telemetry message is sent when the application shuts down or once every 24 hours, whichever happens first. This includes when the application incurs a fault or crash — the application makes a best effort to send a telemetry message prior to shutdown.

If the application runs longer than 24 hours, it sends a telemetry message and then resets all session and telemetry fields, so that sessions can’t be correlated beyond a 24‑hour window.

What telemetry is sent

The message is designed to help Baseline Security Consulting approximate the size of the user base and which ‘major’ functionality is used in a session. Specifically, it includes:

• A number to indicate which application sent the message;
• The version number of the application;
• Yes / no flags of which ‘major features’ were used in the session;
• A random session identifier, which changes each time the app is started — or every 24 hours if the app is left open for extended periods; and
• [For commercial licensed users only] A fixed organization ID.

Here is an example message, with its values in hexadecimal format:

As a human‑readable telemetry message, it conveys the following:

“The application Baseline Investigator, v0.2.0, used the ENRICHMENT feature during session 2109F8DA, under a non‑commercial license.”

The full details of the telemetry message contents are included below. For all users, no user nor device identifiable information is collected. For commercial users, a company identifier is included in the message.

How telemetry is sent

Telemetry is sent via a DNS A record query that contains an encrypted version of the 13‑byte telemetry message, along with a 33‑byte ephemeral public key, both base32 encoded. The answer to the query is ignored by the application. Additionally, Baseline’s DNS servers answer these queries with localhost (i.e. 127.0.0.1 and ::1) to ensure no traffic is inadvertently sent externally.

The nine telemetry message bytes are encrypted using ECIES over the P‑256 public‑key cryptography scheme, and are not decryptable by any third party in transit nor at rest. The end‑user’s private key is ephemeral, generated by the app each session, and never stored on their host. Baseline’s private key is held securely in a cloud‑managed secrets store.

All telemetry is inserted into DNS queries for domains matching this pattern:

*.*.telemetry.blinesec.com

Once encrypted and encoded, an example telemetry message looks like this:

alludhh67rq4r7mafvgwnpicqd7nv4xyxmf6w.vowxtsqsvlpbhgomrydsena4omnfkwjnpxkje.telemetry.blinesec.com

How telemetry is used and stored

Authoritative DNS server logs for blinesec.com are collected by Baseline Security Consulting and decrypted as they are received. The decrypted logs are parsed and kept in cloud‑based blob storage, where they are used to build datasets and dashboards of user‑base statistics. Examples include:

• Application versions actively used;
• Overall session counts per hour / day / week / etc;
• Major feature usage, or lack of usage; and
• Multi‑feature cohort counts.

Retention

• Raw DNS authoritative logs are retained for 14 days, to allow for handling any disruptions in the processing pipeline or bugs in the end‑user application.
• Plaintext session telemetry is held for 30 days.
• Aggregate statistics are kept for one year.

Found a query to *.*.telemetry.blinesec.com in your logs?

You’re in the right place. Here’s what it is and what it means.

A query you saw will look something like this:

alludhh67rq4r7mafvgwnpicqd7nv4xyxmf6w.vowxtsqsvlpbhgomrydsena4omnfkwjnpxkje.telemetry.blinesec.com

What that random-looking string actually is:

• The two labels are a 13‑byte usage message plus a one‑time public key, encrypted with ECIES and base32‑encoded. Even we cannot tie it to a person or machine.
• It is sent at most once per session or once every 24 hours — not continuously. Seeing it occasionally is expected.
• Our DNS servers answer with 127.0.0.1 / ::1, so the application ignores the response and nothing is downloaded or controlled as a result.
• The most a query can reveal to us is a timestamp and the IP subnet of the resolver — and even that depends on your DNS provider.

If you’d rather it stop

• Disable telemetry in the app. Telemetry is opt‑in and off by default; turning it off in Baseline Investigator’s settings stops these queries at the source.
• Block it at the network. You can safely sinkhole or block *.telemetry.blinesec.com in your DNS resolver or firewall — the application tolerates the query failing and no functionality is lost.

Want the full picture? The rest of this page explains exactly what is collected, how it’s encrypted and sent, and how it’s stored and retained, with byte‑level details if you want to decode a message yourself.

Telemetry message format

All of the session data is packed into a 13‑byte session string to minimize both network traffic and its ability to contain any identifying information. Once encrypted, sessions, users, and other details cannot be differentiated from each other.

Major feature bit flags

These flags are set to understand which ‘major’ pieces of Baseline Investigator functionality were used in the session. No other details — how they were used, when they were used, how many times they were used, the data manipulated by the feature, etc. — are collected. A flag only answers the question: during the session, was the feature used at all?

Contact us

If you have any questions about the telemetry that aren't covered on this page or you're interested in using Baseline Investigator in your organization, please reach out to us at contact [at] baselinesecurityconsulting [dot] com. We are happy to answer any questions you may have.