Privacy and local accounts

bitcollector ships telemetry off the host every cycle, so what it declines to collect matters as much as what it collects. Process command lines are off by default; the process collector never reads environment variables or file contents; nothing derived from a password hash is ever carried; and the local-account collector publishes UIDs rather than login names unless you opt in. Process records are the exception in the binary you can download today: they carry the owning account's login name, and the next release stops publishing it by default — see what process records carry below, which is the section to read if login names are personal data in your assessment.

This page covers those defaults, and the local-account collector they bear on most. For everything else the agent gathers, see the bitcollector overview.

Privacy defaults

Data minimisation is the default state, not a hardening step you have to remember. This is what makes bitcollector deployable in France without an argument.

Process command lines are off by default. Command lines routinely carry plaintext credentials — mysqldump -pSECRET, --token=…, a DSN with an embedded password — and this agent ships telemetry off the host every cycle.

collectors:
  process:
    command_line: "off"          # off | redacted | full
    i_accept_secret_exposure: false

Mode	Behaviour
off	Default. Command lines are never collected.
redacted	Collected with known secrets stripped at capture, before the record exists.
full	Collected verbatim. The agent refuses to start unless i_accept_secret_exposure: true is also set.

And the rules around it:

• The process collector never collects environment variables or file contents, in any command-line mode.
• A mode that cannot honestly be delivered on a platform is refused, not faked. Windows has no faithful argv, so redacted refuses there rather than pretending to redact.
• Each record states which mode produced it, so absence is legible — an auditor can tell "nothing was there" from "we chose not to look".

Privileged and dormant accounts

Which accounts on this host can become root, whether their password can be used, and how long since anyone logged in as them — without anyone having to SSH in.

• Privilege is counted from UID 0 plus sudo/wheel/admin/root membership, taken both from the group member list and from primary GIDs. An account whose primary group is sudo appears in no member list at all, and is exactly the one you would miss.
• Dormancy is flagged past a configurable threshold — dormant_after: 2160h (90 days) by default, which is PCI DSS 8.1.4 and the usual ISO 27001 control. The threshold that produced each verdict is carried in the record.

No password hashes, ever

The /etc/shadow password field is handed to a single classifier that returns one of six constants (set, locked, no_password_login, empty, unrecognised, unknown). Nothing derived from the hash is carried — and the hashing algorithm is deliberately not collected either, because the algorithm identifier is a prefix of the hash. The record says so in its hash_algorithm field rather than leaving you to notice the absence.

The local-account collector publishes UIDs rather than login names by default.

collectors:
  accounts:
    identity: minimal            # minimal (default) | username

minimal publishes UIDs only; the record's own remedy string tells the operator to run getent passwd <uid> locally. identity: username publishes login names, is opt-in, is refused if mistyped, and stamps every record it produces. GECOS (full name, office, phone) and home directories are never read in either mode, and the tty and source address of a login are dropped at capture. On one reference host, 34 local accounts reduced to 2 published records.

What process records carry about the owning account

The control above governs the accounts collector only. The process collector is a separate code path, and in the binary you can download today it publishes the login name of the account owning each process:

{ "pid": 1421, "name": "nginx", "owner": "www-data", "…": "…" }

Correction: a per-collector suppression for owner now exists

An earlier version of this page carried a warning headed "This is not gated, and there is no key that turns it off". It said owner was set unconditionally on every process record, that collectors.accounts.identity did not apply to it, and — the sentence to re-read — that "a per-collector suppression for owner does not exist yet", leaving you two options: disable the process collector entirely, or accept and document the processing.

That last sentence has stopped being true. collectors.process.identity exists, it defaults to minimal, and in that mode the owning account's login name is never read at all. It is not in the published binary yet — see the next box, which is the part of the old warning that still stands — but it is no longer something this product does not have.

This is corrected in place rather than quietly reworded, because it is the kind of statement you may have acted on. If you turned the process collector off to keep login names on your hosts, or recorded in a DPIA or a customer answer that this processing could not be suppressed, that is the decision to revisit once you are running a build that has the key.

An earlier version of this page also said login names "stay on the host unless you opt in". That was true of the accounts collector and wrong about the agent as a whole, and it is corrected here rather than quietly reworded — a data-protection statement you relied on should not change without being told.

This section describes the NEXT release, not the binary you can download

collectors.process.identity is unreleased. It is not in 0.2.0-ga (commit 0821374), the newest published bitcollector binary, and not in any release before it. Run bitcollector version and compare before you plan around it.

What the binary you can download today does. Read from the code at commit 0821374:

• owner — the owning account's login name — is set on every process record, on every collection cycle, whenever the process collector is enabled, and it is enabled by default.
• collectors.accounts.identity does not apply to it. That key is read only by the accounts collector.
• Writing collectors.process.identity into a configuration file changes nothing there, and nothing tells you so. The field does not exist in that build and the agent's YAML loader ignores keys it does not recognise, so it starts normally and keeps publishing login names. There is no error, and no line in the log. Do not treat the key as a control until bitcollector version shows you are past 0.2.0-ga.
• owner_uid is 0 — which is root — on every Windows record and on every process whose uid could not be read. See owner_uid no longer defaults to root below.

On 0.2.0-ga the two options are still the ones named above: disable the process collector (collectors.process.enabled: false), or accept and document the processing.

From the next release, collectors.process.identity decides whether the login name leaves the host — deliberately the same key name, the same two values and the same fail-closed refusal as collectors.accounts.identity, so it is one concept on two collectors rather than two settings that look alike:

collectors:
  process:
    identity: minimal            # minimal (default) | username

Mode	What a process record carries
minimal	Default. owner_uid only — the owning account's uid. The login name is never read, so it reaches no exporter, no log and no in-memory copy of a record. Resolve a uid on the host itself with getent passwd <uid>.
username	owner (the login name — personal data under GDPR) and owner_uid. Opt-in, and stamped in every record it produces.

And the rules around it:

• Any other value refuses to start, in EN and FR. A privacy control that cannot be established fails closed rather than being resolved silently in either direction — a typo must not hide your explicit request for names, nor ship names nobody asked for.
• Every record stamps the mode that produced it in owner_identity_mode: minimal, username, unsupported or unavailable. The last two are per-record stamps the agent writes; they are not values you can set, and the refusal above rejects them if you try.
• If a dashboard or a query of yours reads owner, it will find it empty after you upgrade. That is this setting, not a broken collector. Set identity: username to publish names again.

minimal does not mean the same thing on Windows

Windows has no POSIX uid, so on Windows minimal publishes no owner identifier at all: owner_uid is -1 and every record is stamped owner_identity_mode: "unsupported", so the absence is legible rather than blank. Windows does have a pseudonymous account identifier — the user SID in the process token — and bitcollector deliberately does not collect it: nothing ships for a platform this project has not verified on. A Windows operator who needs owner attribution sets identity: username, and accepts that a Windows account name is personal data.

owner_uid no longer defaults to root

In 0.2.0-ga, owner_uid is left at Go's zero value whenever the uid is not read — and that value is 0, which is root. Every process record collected on Windows carried it, as did every record whose uid read was refused, with nothing to say the number had never been observed. From the next release the unobserved value is -1, and owner_identity_mode says why it is there: unsupported on a platform with no uid, unavailable when that one process could not be read. If you alert on owner_uid == 0, expect the count to fall.

Two honest limits, stated where you read them rather than discovered later:

• An unprivileged agent cannot read /etc/shadow (root:shadow 0640), so it reports password_status: unknown for every account and says why. The least-privilege fix is to add the agent's user to the shadow group.
• "No dormant accounts" and "we could not read last-login" are never the same answer. If lastlog is absent — shadow 4.16+ / Ubuntu 25.04+ replaced it with lastlog2 — every account reports dormancy unknown and the record names the replacement.

Next steps

• bitcollector overview — the rest of the nine collectors, and how to run the agent.
• Evidence an auditor can verify — including how long records stay on the host, and the storage-limitation bound that governs it.
• Data subject rights — how Cert-IX handles requests about personal data.