The privacy policy has a new revision, dated 29 September 2026. It adds one record, and it takes effect on 30 October 2026. This post is the notice that section 15 of the policy requires 30 days ahead of a material change.
What changes
From 30 October 2026, a new account records where its signup came from:
- the ShieldFive page the visit started on (for example
/request), - the host name of the site that linked to it (for example
www.bing.com), never the full address, - the campaign tags on our own links (
utm_source,utm_medium,utm_campaign), when the link carried them.
It is written once, at signup, on accounts created from that date. Existing accounts are not backfilled.
Why
Until now the signup source has been recorded without an account identifier. That answers "how many signups came from this page" and nothing past it. It cannot say which pages and channels lead to accounts that upload a file, collect a document from a client, or pay, which is the question that decides where effort goes. Answering it needs the source on the account.
Where it lives and when it is deleted
The record sits in the account's own server-side metadata in the authentication database. It is not sent to any analytics provider or advertiser, and it is deleted with the account. It is deliberately not written to the audit log, whose rows are immutable and outlive the account.
The existing unlinked count is unchanged, and page-view analytics are still never linked to an account identifier.
Legal basis and objection
Legitimate interest (GDPR Art. 6(1)(f)) in measuring which of our own pages and channels work. You can object at any time through the routes in section 9 of the policy, and the record is removed.
Where to read it
/privacy: sections 3.1, 5, 6 and the pending-change note in 15.
The write is gated in code to the effective date
(utils/acquisitionRecord.ts, ACCOUNT_ACQUISITION_EFFECTIVE_AT), with a
test that pins the date.