🍪 Privacy, Cookies & Retention

Consent is stored in one cookie, cookie-consent, whose value is the dot-separated list of granted categories, always led by necessary:

An absent or unparseable value means never asked, and the banner renders. The lifetime is 183 days, so consent is re-sought roughly every six months, in line with regulator guidance that consent should not be indefinite.

Where it lives

• The banner is static SSR — no Blazor circuit — so it renders on the very first paint.
• All behaviour lives in one script, wwwroot/js/cookie-consent.js: the record format, the category logic, the consent-gated analytics load, and the plugin contract below.
• Settings are per-organisation, configured at /Platform/CookieConsentConfiguration and /Admin/CookieConsentConfiguration. Like the other deployment settings, an organisation with no domain of its own inherits the operator's.

This is the part most implementations get wrong. It is not enough to set a "denied" flag on a tag manager that has already loaded — the request itself is the disclosure. So the app publishes only the measurement id as a meta tag, and cookie-consent.js injects the analytics loader after the analytics category is granted. An un-consented visitor never contacts the analytics host at all.

Category mapping, for Consent Mode v2:

• analytics → analytics_storage
• marketing → ad_storage + ad_user_data + ad_personalization

Withdrawal actively deletes the analytics cookies. Setting Consent Mode to denied only stops future writes; it leaves whatever is already on the device.

PECR reg 6 and ePrivacy Art 5(3) cover any access to a visitor's device — localStorage, sessionStorage, IndexedDB and fingerprinting, not just cookies. The test is purpose, not mechanism:

• Exempt — storage strictly necessary for something the visitor asked for: a session id, a "don't show this again" dismissal, a regulator-mandated device id.
• Needs consent — analytics, advertising, A/B testing, profiling.

If you add anything in the second group, gate it and re-check on change — this is the contract a plugin uses so it doesn't need its own banner:

Adding such a thing also changes your banner copy: it becomes "cookies and similar technologies", because cookies are no longer the whole story.

1. The banner demotes itself on policy pages

On the very pages the banner links to — your cookie and privacy policies — a modal banner is demoted to a non-blocking bottom bar. A full-screen overlay covering the document the visitor opened in order to decide makes the consent uninformed, and therefore invalid.

2. Withdrawal stays as easy as consent

GDPR Art. 7(3) requires it to be as easy to withdraw consent as to give it, so a Cookie settings control lives in the footer permanently — not only in the banner that disappears once answered. Two consequences worth knowing:

• Turning off Features:SiteFooter removes that footer, so the banner grows a standalone "Cookie settings" pill instead. Withdrawal is never stranded.
• A plugin that suppresses the platform chrome and ships its own footer inherits this obligation — its footer must carry the cookie control and the organisation's legal-policy links, or those pages lose both.

• Export — /Account/Manage/DownloadPersonalData returns every field tagged [PersonalData] as JSON. Encryption is transparent here: the storage layer decrypts on read.
• Erasure — deletion is soft, with a grace window (BackgroundServices:UserDeletion:GracePeriodDays, default 30). Sign-in is blocked immediately; the user can cancel during the window; a sweep hard-deletes afterwards, removes memberships, and re-evaluates any organisation left without active members or owners.
• Encryption is a separate concern from export. [Encrypted] governs storage; [PersonalData] governs the download. A field can be either, both, or neither — see Security & Encryption.

"Keep it no longer than necessary" is a legal requirement, so retention is a sweep that runs in the background worker rather than something you remember to do. The windows are bucketed by kind of data, deliberately — one global number would be wrong for at least one bucket:

If you write a row per anonymous public request, you owe it a sweep. Anything reachable without a login — a redirect, a public landing page, a scan or click counter — lets an unauthenticated visitor grow a tenant database without bound. The pattern to copy is: prune the per-event detail rows on a schedule, keep the aggregate counter (which is updated atomically and costs nothing to retain).

An organisation can be members-only. When it is, anonymous visitors are redirected to sign-in, robots.txt returns Disallow: /, and /sitemap.xml returns 404 — so the workspace is neither reachable nor indexable. Tenant organisations default to private; the platform organisation defaults to public. Toggle it on /Admin/Pages.

Two details that matter operationally. An organisation whose settings row is missing resolves to private — including the platform organisation, which has no structural exemption, so losing that row bounces every anonymous visitor on your own marketing site to a login page. And the anonymous wall is orthogonal to the membership wall: making an organisation public admits anonymous readers to its public pages, it does not admit non-members to the application.