The page your privacy notice is supposed to link to

Why it is hosted rather than something you build

A preference centre is a small page with a large number of correctness requirements. It has to show the purposes that are currently active and not superseded, in the language the visitor reads, reflecting the published version of the notice rather than the draft, writing to the same consent record the banner wrote to, and producing an artefact on every change. Built in-house it is a fortnight of work and a permanent source of drift between what the page shows and what the record holds.

Hosting it means the page is generated from the same configuration the widget reads, against the same key. There is no second copy of your purpose list to keep in sync, and no deploy when a purpose is retired.

No login, and that is the deliberate part

The default is anonymous. A visitor arriving from the banner or from a link in your notice is recognised by a first-party handle, sees the decisions made from that browser, and can change them. No account, no password, no email.

That sounds like a security hole until you think about what the alternative collects. Requiring identification before somebody can exercise a preference means collecting personal data in order to let them reduce the personal data you hold — which is the opposite of what §6(1) and the rights machinery are for. The data minimisation argument is written into the code path.

Where you do need identification, it is a per-key setting: require an email, send a six-digit code, verify, then show the record tied to that address. QR-code deployments force that mode on, because a printed code has no browser history behind it and the anonymous handle would be meaningless.

What a visitor can actually change

Per-purpose toggles, not a single accept-or-reject. Each purpose is shown with the name and description in the chosen language, and each can be moved independently — which is the practical expression of the §6 rule that consent be specific rather than bundled. Where a purpose in the key's scope is in draft or has been retired, the page says so rather than silently omitting it.

There is also a withdraw route on the page itself, worded as plainly as the accept button was. Where the consent it is withdrawing was verified by email, the withdrawal is verified the same way; where it was an anonymous cookie decision with no email behind it, there is nothing to verify against and no code is sent. Asking someone to prove an identity they never gave you is a way of making withdrawal harder than consent, which §6(4) does not allow.

Twenty-three languages, and three that read right to left

The page chrome — headings, buttons, the explanatory copy around the toggles — is authored in English plus the twenty-two languages named in the Eighth Schedule of the Constitution. Urdu, Kashmiri and Sindhi render with the document direction set to right-to-left, which is the detail that separates a page that has been translated from a page that has been localised. An unrecognised language code collapses to English rather than failing.

The purpose names and notice body arrive in the same request, translated separately, with a flag on each one saying whether it is the real translation or an English fallback. That flag exists because a preference centre that silently shows English purposes under a Tamil heading is worse than one that admits it.

The token-addressed variant, and when to use which

There are two doors into the same record. The key-addressed page above is the public one you link from a notice or a banner — it recognises a browser. The token-addressed one is a per-principal link emailed to a specific person, which shows that person's record wherever they open it, including on a different device.

Use the first for a link in a privacy notice and a button in a banner. Use the second in a consent request email, a receipt, or anything sent to an individual — because a browser handle does not survive the jump from your email on a laptop to your phone, and the whole point of a per-principal link is that it does.

What it will not do

It is not an account portal. It will not show order history, support tickets or profile data, and it will not authenticate anyone for any other purpose. It shows consent state and changes consent state.

It also will not, by itself, satisfy §11 to §14. Access, correction, erasure and nomination are rights requests with their own verification, routing and clock, and they live in the rights portal rather than here. A preference centre that pretends to be a rights portal is the kind of thing that looks fine until the first erasure request arrives through it with no record of who asked.