The consent log and its proof

Consent law puts the burden of proof on the site: if a visitor or a data protection authority asks, you must be able to show that consent was given, when, and to what. If PXL could edit the log without anyone noticing, the log would prove little. You, an auditor or a court can check PXL Consent's log without having to trust PXL.

What is recorded

Each choice is one record: a random consent ID (also stored in the visitor's cookie), the categories allowed and refused, how the choice was made (accept all, reject all, custom, renewal, withdrawal, opt-out, Global Privacy Control), the banner version and privacy policy version shown, the time, the page address, the browser's user agent and language, the country, the kind of device (desktop, mobile, tablet or bot, worked out from the user agent), and the visitor's IP address truncated to its first two octets (IPv4) or first 32 bits (IPv6). No name, email or full IP address is stored.

Withdrawal is a new record, never an edit of an old one. Records are kept for the site's retention period (12, 24 or 36 months) and then deleted in bulk.

How it is protected

• Signed. Every record is signed with an Ed25519 key that belongs to the site. The public keys are published, so anyone can check a signature.
• Chained. Every record contains the hash of the one before it. Changing, inserting or removing a record breaks the chain from that point on.
• Sealed daily. At the end of each day the head of the chain is signed, and the signed head is time-stamped by an independent RFC 3161 time-stamping authority. This proves the log existed in that state on that day, so records cannot be rewritten and re-signed later.
• Append-only in the database. The service's database role can insert records but cannot update or delete them.

Signing keys can be rotated. If a key is suspected to be compromised, it is marked as such, and verification then reports every record signed with it as unproven.

Looking up a visitor's consent

For a data subject request, ask the visitor for their consent ID (your privacy page can show it with ccs.id()), and look it up in the site's Consents tab. You get the full history for that ID with each record's signature checked. Export any period as CSV from the same tab.

What visitors chose

The site's Analytics tab shows the choices day by day for the last 7, 30 or 90 days, split into accepted all, chose categories, rejected, and renewals. Under it, the same period broken down by device and by country, and which banner versions visitors answered — choices on an old version mean some pages still serve a cached script.

The figures come from counts rolled up hourly, not from reading the log, so they cost the same on a busy site as on a quiet one. Today fills in as the day goes on. The device is a class (desktop, mobile, tablet, bot) worked out from the browser's user agent; the country is the one our edge reports, and shows as unknown where there is none.

Verifying the log

Verify log in the Consents tab walks the whole chain: it recomputes every hash, checks every signature and daily head, and checks the time-stamps. It reports the number of records checked and any record that fails, with the reason.

Download evidence produces a zip an auditor can verify offline. It contains:

The public keys are the only trust anchor, so the bundle can be verified without PXL. PXL provides the verification tool to auditors on request.