Your meeting media is not our data product.

The list of "no".

None of the following exist anywhere in CodeB Sovereign Communications. No exceptions, no "but only if you opt in", no asterisks.

• No third-party analytics — no Matomo, no Plausible, no Mixpanel, no Amplitude, no Segment, no first-party analytics either.
• No advertising trackers — no ad-network pixels of any kind. No retargeting tags, no audience pixels.
• No cookies — we don't set any cookies, first-party or otherwise. The app uses localStorage for your preferences only, and even that stays on your device.
• No session recording, heatmaps or scroll tracking — no FullStory, Hotjar, LogRocket, Mouseflow or similar.
• No A/B testing platforms — no Optimizely, no LaunchDarkly, no feature-flag service of any kind.
• No error reporting to third parties — no Sentry, no Bugsnag, no Datadog RUM. Errors stay in your browser console.
• No CDN dependencies in the call path — the QR code generator, the WebRTC client and the signaling endpoint are all served from www.aloaha.com.
• No mandatory third-party logins — no social-account sign-in, no Microsoft account, no SSO required to join a room. You enter a room code; you're in.
• For meeting rooms, no identity provider sits in the middle - your display name is whatever you type; we do not verify it against an external directory. For OIDC sign-in and European Digital Identity Wallet flows, identity claims come from the trusted issuer or your government wallet and ARE cryptographically verified.
• No meeting persistence on any server — recordings exist only on the recorder's machine; chat lives only in browser memory and disappears when the tab closes.
• No telemetry from the app itself — the running browser code does not send "the user clicked X" events to any endpoint, period.
• No ad-supported tier — there are no ads on any page, ever.

The list of "yes — briefly".

The list of things that actually happen is short enough to fit on this page.

• The IIS server keeps a short in-memory list of "who is in which room right now" so it can route signaling between you. When the last person leaves the room, the entry is gone. Nothing is written to disk.
• Standard IIS access logs record HTTP requests (URL, status code, IP, user agent) the same way every web server does. Retention is an operator responsibility: each tenant sets a binding rotation policy in its own privacy notice and enforces it via the IIS log-rotation configuration. The CodeB reference tenants on phone.codeb.io and phone.aloaha.com rotate IIS access logs after 14 days. We do not parse them, do not correlate them with sign-in data, and never forward them to third parties.
• Your browser stores a handful of personal-preference keys in localStorage: display name, selected camera/microphone, mirror toggle, push-to-talk, auto-spotlight, background-blur, join-muted and join-camera-off. Clear your browser data and they're gone.
• For meetings that require it, an HMAC-SHA1 TURN credential is generated for your browser at room-join time. The credential expires after one hour. It does not contain your name, email or any persistent identifier.
• Passwords are hashed in your browser before they reach our server. The plaintext you type never traverses the network and never lands on our disks, never sits in our memory, never ends up in a log. We only ever see and store irreversible hashes. A server breach cannot leak passwords that aren’t there.

Where bytes leave our network.

Up to three external hosts may be contacted by the browser, depending on which features you use and how the operator has configured the deployment. None of them ever see your video, audio, chat or files.

For an air-gap install, the WebRTC signaling, TURN relay, JS, CSS, fonts and ML model can all live on the customer's own LAN. The build supports it; the recipe is documented in the deployment README.

Where AI calls differ from meetings.

Read the full AI-calls privacy & data-flow page →

The privacy posture above applies to CodeB Conference meetings and CodeB Phone (SIP) calls between humans. CodeB Voice AI is different, because by design the AI receptionist and outbound-AI-call features send caller audio to a real-time speech model. We document this honestly so operators and end-users know exactly what to expect.

The model backend is pluggable per deployment.

The bridge can be configured to use one of:

• a cloud AI Voice Engine — real-time bidirectional voice. Caller audio is streamed to the configured cloud-engine vendor’s API and processed there; the configured cloud-engine vendor’s data-handling terms apply. Transcripts arrive back through the same WS.
• another cloud AI Voice Engine — same architectural pattern. Caller audio is streamed to the configured cloud-engine vendor; the cloud-engine vendor’s terms apply.
• On-premise AI Voice Engine — static text-to-speech only. No external model. Caller audio is never sent off-machine. Used as a fallback when the cloud model is unreachable, and as the primary backend in air-gap deployments where any external traffic is unacceptable.

Which backend is active on this deployment is set in App_Data/<tenant>/appsettings.json by the operator. There is no default cloud connection — if no model is configured, AI calls do not run at all.

What leaves the deployment when a cloud model is in use.

• Caller audio — streamed to the configured model API in real time, at 16 kHz PCM. The bridge does not save a copy of the audio after the call ends.
• Caller and AI transcripts — returned by the model API. The bridge writes them to a tenant-local file (under App_Data/<tenant>/ai-transcripts/) and, if configured, emails a copy to the operator address attached to the vnum or campaign.
• The persona system prompt — sent on every call to set the AI’s behaviour. Operator-authored; reviewed in the persona file before deployment.
• Tool-call metadata — if the AI invokes transfer_to_user or hangup, the arguments (target number, reason) flow back through the model API for the response.

What stays inside the deployment.

• The phone-number whitelist and per-call FraudGuard counters — never sent to any model.
• The SIP trunk credentials — never sent to any model.
• The webhook delivery list, REST API keys and OIDC signing keys — never sent to any model.
• The transcript files on disk — tenant-local, under App_Data/<tenant>/ai-transcripts/. Not synced anywhere unless the operator wires their own backup.

Operator obligations when AI calls are enabled.

If your deployment runs AI calls using a cloud model, you are the data controller for those calls under most jurisdictions. You are responsible for:

• Disclosing to inbound callers (typically via an answer-time greeting or a hold-message) that they are speaking to an AI, and that their voice will be processed by a third-party model API.
• Choosing a model backend whose data-processing terms match your regulatory environment. For EU healthcare, legal or public-sector deployments, the on-premise AI Voice Engine backend or an on-premise inference server is the conservative default.
• Setting an appropriate transcript retention policy — the bridge keeps transcripts indefinitely on disk by default; rotation is your responsibility.

If you need an air-gap or fully on-premise AI voice experience, contact us — on-premise inference deployments (a small open-weights speech-to-text model + LLM on the same Windows box) are supported but require operator-side hardware.

Why the colour scheme looks like a 1980s terminal.

The accent colour you see throughout CodeB Sovereign Communications — that warm #f5a524 against the deep #0a0d12 background — is a deliberate tribute to amber-phosphor CRT monitors.

For roughly fifteen years, from the late 1970s into the early 1990s, the people who ran the world's most consequential computers stared at amber screens. The IBM 5151, the Wyse 50, terminals on hospital nursing stations, manufacturing line PLCs, air-traffic-control consoles, defence command terminals — they all glowed in this same warm yellow at around 580 nm wavelength.

The reason wasn't aesthetic. Amber phosphor (P3, later P134) was chosen because it sits in the sweet spot of the human eye's photopic sensitivity curve. Operators staring at a screen for ten or twelve hours — radiologists, air-traffic controllers, machine-tool programmers — experienced measurably less eye fatigue with amber than with the otherwise-common green P1 phosphor, and significantly less than with the white CRTs that became fashionable later. Amber was the colour of tools for people whose work mattered.

That's the lineage we wanted CodeB to invoke. A serious tool for people doing serious work — clinicians, engineers, factory operators, public servants, defence supply chains — the same people CodeB Identity Solutions has served for two decades. The codeb.io design language uses amber the way those terminals did: high signal, no decoration. There is one accent colour because the work is what matters; the chrome shouldn't compete with it.

(And there's a small practical bonus: against a dark background, amber has the highest perceptual contrast of any single accent colour, and it remains distinguishable to people with the most common forms of red-green colour vision deficiency. The 1980s engineers picked it for ergonomic reasons; we picked it for the same ones plus a bit of historical respect.)

Wallet and identity data.

When you sign in with an European Digital Identity Wallet credential, or with an OIDC identity provider, the following applies in addition to sections 01 - 04:

• What we receive. Person Identification Data (PID) claims — typically given_name, family_name, birthdate, and email where the credential contains them — when you present a wallet credential to sign in. For age-only checks we receive an age_over_N boolean instead of the birthdate where the wallet supports it.
• Legal basis. Article 6(1)(b) GDPR (contract performance — authentication) for the moments in which you initiate a sign-in.
• Purpose. Authenticating you to the relying party you asked to sign in to; verifying age or specific attributes as requested by that relying party.
• Retention. PID claims are retained only for the duration of the authenticated session, unless the tenant operating this instance has explicitly configured its user account store to cache them — in which case the tenant is the data controller for that persistence. The tenant setting Oidc:PidRetentionSeconds caps how long cached PID slots are visible to downstream OIDC clients; the shipped default is 30 days (GDPR Article 5(1)(e) storage-limitation). Expiry is lazy: on the next userinfo read after the TTL has elapsed the PID fields are transparently omitted. Setting the value to 0 disables persistence entirely (session-only).
• Per-client filter. Each downstream OIDC client that consumes the userinfo endpoint is subject to a per-client wallet-claim allowlist at App_Data/<tenant>/oidc-clients/<client_id>/wallet-claim-allowlist.json. In the shipped default no wallet-derived claim reaches a downstream client unless the allowlist explicitly lists it (GDPR Article 25 data protection by design and default). The escape hatch Oidc:WalletClaimDefaultAllowAll=true restores the pre-hardening behaviour for backward-compat only.
• Transaction records. Per transaction the verifier logs the outcome (success / fail), the wallet type, and a timestamp. Retention is per tenant configuration.
• Sub-processors. None by default for wallet flows. The verifier speaks OpenID4VP directly to the wallet; there is no third-party EUDI SDK in the path.
• Data controller. The tenant operating this instance. Aloaha Limited is the software vendor and does not act as data controller for wallet transactions on a customer-hosted instance.
• Your rights. Access, rectification, erasure, restriction, portability and objection under GDPR are exercised against the tenant operator. Contact details are in the tenant’s own imprint / privacy statement.

Tenant operators requiring GDPR Article 35 DPIA can start from our published template: Data Protection Impact Assessment template. Article 30 Records of Processing Activities: RoPA template. Both are template documents that the tenant DPO must adapt and sign off; Aloaha does not provide legal advice.

The promise written down.

If any of the items in section 01 ("things we do not do") ever stops being true, this page changes before the change ships. We won't roll trackers in quietly. We won't bury new analytics three menus deep.

The source code for CodeB Sovereign Communications lives on your own IIS server. Every JavaScript file, every C# handler and the entire TURN service is open to inspection by anyone in your organisation. There is no obfuscation, no minification step that hides logic, and no compiled binary that contains anything not visible in the source.

If you spot something in the running app that contradicts this manifesto, please write to info@aloaha.comCall. A real person reads that inbox — or answers that phone.