Privacy Policy

1. Who we are

This Privacy Policy explains how Clearcote Labs (“we”, “us”) handles personal data for the Clearcote account services at clearcotelabs.com.

2. Data we collect

• Account data — your email address, optional display name and avatar, and a hashed password (we never store passwords in plain text).
• Authentication data — magic-link tokens, linked OAuth account identifiers (e.g. Google/GitHub) if you use them, and API key hashes.
• Preferences — your email subscription choices.
• Usage/technical data — basic logs and, on the marketing site, privacy-friendly analytics.

3. The browser fingerprint test & research dataset

The browser fingerprint test decides every check in your browser, without comparing you against a population. No account is needed to use the page.

If you press Run, your browser fingerprint is sent to us and we keep it. This is the important sentence on this page, so it is not buried: the audit is not a read-only local tool. Running it transmits enough detail to reproduce your browser’s identity. If you do not want that, do not press Run — reading the page sends nothing.

Three things leave your machine, all disclosed on the audit page itself before you run it:

• Your fingerprint profile. A full capture of what your browser exposes to JavaScript, stored so we can analyse it and build Clearcote browser profiles from real hardware. Detailed below.
• A coarse configuration record, kept separately, which is what lets the page tell you how rare your setup is. It contains one value that can identify a device — see below. Detailed below.
• The WebRTC check contacts a public STUN server (stun.l.google.com) to discover the address your media traffic exits from, and asks our own server which address your page request arrived from. Comparing the two is the only way to detect a WebRTC leak. The STUN operator (Google) necessarily sees your IP address; this is inherent to the measurement. Google does not receive anything else from us, and the address your media exits from is not stored. The address your page request arrived from is stored, as part of the fingerprint profile described below.

The fingerprint profile — what it contains

Effectively everything your browser exposes to JavaScript: your full user agent and all UA client-hint values; your screen and window geometry; your complete WebGL and WebGPU parameter, extension and precision tables including your GPU’s vendor and renderer strings; the Web Audio constant table; your installed speech voices; your detected fonts; your codec support; your CSS media-query results; your plugins; your keyboard layout; your timezone and locale; your network-connection and battery state; and reference canvas and clientRects measurements.

It also contains three things JavaScript cannot see, which is precisely why they are worth recording: your IP address, as our edge observed the connection; your TLS fingerprint (JA3/JA4, offered ciphers, extensions and ALPN) taken from the handshake your browser performed; and your HTTP request headers in the order your browser actually sent them, which the network stack writes below the runtime and no page script can read or forge.

Finally it records the result of the run itself — your coherence score and the verdict of every individual check — so a profile can be studied as an outcome rather than only as a static snapshot.

Stored with it are counters describing the shape of the interaction steps above the Run button: how many clicks, key events and dropdown changes arrived, and how many of them were synthetic rather than produced by the browser’s own input pipeline. Six checks are decided from these, and the raw counters are kept alongside their verdicts so that a check which starts misfiring on some browser or input method can be found and corrected rather than quietly convicting people.

What those counters are not is a record of what you did. They contain no key, no key code, no character, not the text you typed, and no timing series — the word the page asks for is a constant we chose, so typing it says nothing about you. Every field that leaves your browser is named individually in the server’s own validation, so there is no field there capable of carrying a keystroke.

This record is not anonymous, and we do not claim otherwise. A profile detailed enough to reproduce a real browser is, by construction, detailed enough to identify it — that fidelity is the entire point of collecting it. We treat it as personal data. We never publish it, sell it, or share it with anyone, in raw or aggregate form, and it is deleted after 12 months.

The coarse configuration record — what it contains

• GPU renderer string and ANGLE backend; WebGL and WebGPU capability vectors (limits, extensions, shader precision).
• Browser and operating system family and major version only (e.g. “Chrome 150”, “Windows 10”) — never the full version string.
• Device class, CPU core count, device memory, device pixel ratio, and a screen size rounded to 160-pixel steps.
• Whether the machine renders in software or on real hardware, whether canvas readback is being perturbed, and which coherence checks flagged (their identifiers only, not the values observed).
• A hash of one rendered test image (a canvas fingerprint). This is the one high-entropy value in this record, and it is called out separately because it behaves differently from everything above it. It lets us ask whether machines reporting the same GPU actually draw the same pixels, which is how altered canvas output is detected — a question no summary of the image can answer, only the value itself. It is not collected when your browser is perturbing canvas readback, because the hash would then be a fresh random number rather than a measurement. See the note on linkability below: this field is the reason that note changed.
• The date of submission — a date, never a time.

What the coarse record never contains

Your IP address (not stored, not hashed, not logged for this endpoint), your full user agent, your audio hash, your timezone, your language list, your fonts, your plugins, or any account or cookie identifier. To be clear about the scope of that sentence: it describes this record only. Several of those values are in the fingerprint profile described above, which is a separate record with none of these properties.

Linkability of the coarse record — this changed

This record used to be unlinkable by construction. Since we began storing the canvas hash described above, it is not. We are stating that plainly rather than quietly relaxing the wording, because the earlier version of this page made the stronger promise and some people will have relied on it.

A canvas hash is close to unique to a machine and stable across visits, so two coarse records carrying the same hash can be recognised as coming from the same device. Every other field here remains coarse, there is still no account or cookie identifier, still no IP address, and still a date rather than a millisecond timestamp — but the structural guarantee that two submissions could not be correlated no longer holds, and the guarantee was the point, so it does not survive being partially true.

What has not changed: coarse records are still stored separately from fingerprint profiles with no shared identifier, they are still never published, sold, or shared, the same retention applies, and the deletion token issued when you contribute still erases the whole record, canvas hash included. If a browser is perturbing canvas readback, no hash is stored for it at all and that record keeps the original property.

The honest limit of that separation: a profile and a coarse record created during the same visit share a date, so anyone holding both tables could correlate them on a quiet day. The design prevents a join key; it does not pretend to prevent that.

Why we collect each of them

The coarse record answers one question: how rare is this configuration? That is the anonymity-set question the page reports back to you. It also lets us measure which of our own checks produce false positives on real browsers — something we cannot know without real data. It is not a fraud database and is never used as one: a configuration we have not seen means unseen, never fake.

The fingerprint profile is kept for our own analysis and is used to build Clearcote browser profiles, so the product can present a real hardware identity rather than a synthetic one. We are stating the commercial purpose plainly because it is one: your fingerprint informs a product we sell.

Publication

We intend to publish research derived from the coarse dataset. Any publication is limited to aggregates gated at a minimum group size (k = 20); we do not publish raw records. A raw fingerprint corpus is a re-identification resource, which is precisely why it only ever leaves as aggregates.

Fingerprint profiles are never published in any form, aggregate or otherwise, and are never sold or shared with third parties. The k = 20 gate above cannot protect them — twenty identical full profiles will never exist — so the rule for profiles is simply that they do not leave.

Retention and erasure

Both records are deleted after 12 months. After the audit runs, the page shows you a separate one-time erasure token for each — the fingerprint profile and the coarse record — and you can delete either immediately, or keep the token and delete it later. Deleting costs you nothing: your results stay on screen.

Those tokens are the only handles to your records. Nothing links either row to you, which is deliberate for the coarse record and is why we cannot find your rows by any other means. If you lose a token we cannot locate the record to erase it (GDPR Art. 11). We say this plainly rather than imply a capability we do not have — so if you may want your profile removed later, save the token.

Legal basis

Consent, given by pressing Run after the audit page states — above the button, before anything is sent — that running the test transmits your fingerprint and that we keep it. Reading the page sends nothing; the choice not to consent is the choice not to run the test. We accept that this is a take-it-or-leave-it basis: there is no way to run the audit without sending the data, and we would rather say so than offer a toggle we then work around.

If you object to this arrangement, or want a record erased and have lost the token, write to us at privacy@clearcotelabs.com.

4. How we use data

• To create and operate your account and authenticate the Clearcote program.
• To send transactional and security email (e.g. magic links, account notices).
• To send product-update and marketing email only per your preferences, which you can change or unsubscribe from at any time.
• To secure, maintain, and improve the Service and comply with law.

5. Legal bases

Where applicable (e.g. under GDPR), we process data to perform our contract with you, for our legitimate interests in operating and securing the Service, with your consent (for marketing), and to comply with legal obligations.

6. Sharing

We share data with processors that help us run the Service — for example our database host, our email provider (Resend), and identity providers you choose to link. We do not sell your personal data.

7. Retention

We keep account data for as long as your account is active and as needed for legal and operational purposes. You can delete your account from the dashboard; we then delete or anonymize associated data, subject to legal retention.

8. Your rights

Depending on your location you may have rights to access, correct, delete, or export your data, and to object to or restrict certain processing. To exercise them, contact privacy@clearcotelabs.com.

9. Email preferences

You can manage product-update and marketing email in your dashboard under Email preferences, or via the unsubscribe link in any such email. Security and transactional messages are required for account operation.

10. Security

We use industry-standard measures including password hashing (bcrypt) and hashed API keys. No method of transmission or storage is 100% secure.

11. Changes

We may update this Policy; material changes will be reflected by a new version number and effective date.

12. Contact

Privacy questions: privacy@clearcotelabs.com.