# Republic Dial privacy and data handling

Applies to the independently implemented Republic Dial 0.1.15 test release and hosted Chrome companion. Updated October 27, 2026. Deployment evidence is recorded separately in [docs/VALIDATION.md](docs/VALIDATION.md).

Republic Dial has no advertising service or built-in analytics/telemetry. Depending on the connection mode, it connects directly to your WebRTC PBX or sends your ordinary SIP account to a hosted pairing gateway. Optional CRM/carrier functions use the built-in Republic service API with the current paired session’s authorization; carrier capabilities depend on server configuration. There is no separate Republic Dial account password; hosted gateway access is authorized by proof of the submitted SIP account and a generated, leased pair token.

## Managed Republic connection

The distributed client uses a fixed Republic HTTPS service address for its gateway and CRM/SMS bridge. Settings does not offer service-URL or bearer-token inputs. Pairing the PBX issues a distinct, leased owner token for that session; the client selects it internally for the fixed service. There is no shared installation-wide token that grants every user access to other pairings. Removing the visible token field does not remove authentication or its storage/expiry behavior.

Existing matching Republic pairings remain usable. A previous custom bridge URL is retired and its manual token is ignored. Foreign gateway credentials are not relabeled or sent to Republic; a foreign generated phone must be paired explicitly with the Republic service, and its former operator controls cleanup/expiry of the old lease. A changed generated browser-phone address cannot receive the remembered browser password. Scheduled custom/foreign routes are rejected for rescheduling rather than silently redirected. Direct WebRTC calling remains available; Republic CRM/carrier services require a paired gateway account.

## Data on this device

The extension stores configuration, contacts, call history, telephone numbers, call outcomes/notes, messages, templates, queue entries and follow-up reminders in the current Chrome profile. The hosted web app stores this workflow data in its browser origin's local storage. Call-recording files are stored locally in IndexedDB in either mode.

The installed Chrome companion opens the HTTPS phone app with `companion=1`. In this mode, JSON workflow data, session/remembered credentials, pairing ownership and worker schedules stay in the existing extension's Chrome storage, accessed through fixed, bounded operations. The trusted hosted phone receives authorized data and credentials in memory to operate the phone; Chrome persistence does not hide runtime values from the website. The bridge checks the exact top-level app origin/path/mode and the worker checks Chrome's sender/document identity. It exposes no arbitrary Chrome API, URL fetcher, script execution or unrestricted storage keys. Other pages served from the same origin are not an independent privacy boundary against a compromised first-party script.

Opening the ordinary hosted app without `companion=1` retains its existing browser-origin storage. It does not silently import or merge Chrome profile data. No credential is placed in the launch URL. The hosted app has its own microphone permission context. Recordings remain origin-bound: older packaged recordings stay at the extension origin and can be downloaded using **Settings → Preferences → Previous local recordings**; new companion recordings use website IndexedDB. There is no automatic binary recording migration. See [Hosted companion](docs/HOSTED-COMPANION.md).

For a paired PBX, the SMS sender display reads that extension's configured outbound caller ID through an administrator-installed metadata connector. The display is transient; outgoing message records can retain the resolved sender number. Scheduled messages also retain a non-secret binding to their original gateway pairing and SMS service URL. At dispatch, the extension checks that binding and reads the current PBX DID again. Older unbound scheduled jobs must be rescheduled instead of silently using the current account.

Upstream SIP passwords, CRM tokens, TURN credentials and private bridge credentials use session storage by default: Chrome session storage for the extension, and the current tab's `sessionStorage` for the hosted web app. Generated gateway/browser credentials also use that session record and, separately, the default local pairing cache described below. Closing the extension dialer alone does not clear Chrome session storage; extension reload/update, disabling the extension and ending Chrome's session clear it. Web-app session storage normally survives reload in the same tab and ends with that browser tab/session, subject to browser session-restoration behavior.

If you choose **Remember SIP, TURN and API credentials on this Chrome profile**, secrets are additionally saved in Chrome local storage for the extension, or origin `localStorage` for the web app, until you change that preference or clear them. Remembered storage is not a separately encrypted vault and has no extra vault password. Shared browsers/profiles, and other applications/scripts served from the same web origin, are not separate privacy boundaries. The extension restricts direct Chrome storage access to trusted extension contexts; the companion permits only its named client state through the fixed worker bridge.

**Keep this paired phone available in this browser until its lease expires** is a separate preference, **on by default**. It saves only the generated browser SIP password, pairing owner token, pair ID/expiry and matching gateway/PBX/browser identity metadata in Chrome local storage or the web origin's `localStorage`. This lets the same profile reopen a phone after its tab session ends. It does not remember the upstream SIP password, CRM credentials or TURN secrets when the remember-all preference is off. It has no separate vault encryption/password; turn it off and save on shared devices, then unpair before leaving.

After expiry, the generated browser password is discarded when the app next loads the cache. A scoped owner token and metadata may remain for cleanup of that exact pairing. Unpairing or disabling/saving the pairing-cache preference removes the local bundle; clearing browser storage also removes it. Removing browser data does not revoke the corresponding server lease. Same-origin Web Locks coordinate one registered browser window per generated phone within a profile; they are not an account-recovery service or a boundary against scripts that already control that browser origin. A lost owner token cannot be reconstructed from a public username lookup; orphan cleanup requires the administrator's safe inspection.

Data export excludes stored password/token objects and redacts TURN credentials. Exports still contain private contact/call/message information and infrastructure configuration. Recordings must be downloaded separately; a JSON backup is not a recording archive. Removing the extension or clearing its profile storage can remove local data.

## Shortcut preferences

Custom quick-action labels, destinations, DTMF sequences and PBX transfer-code preferences use versioned local storage at the phone UI origin, with separate ordinary-hosted, companion and packaged namespaces. These non-secret UI preferences are separate from Chrome-backed workspace/credential state, so older packaged recording tools cannot overwrite them through the legacy workspace schema. They do not include SIP/CRM secrets and are not uploaded by configuring them. Exports can contain private team labels and telephone numbers. Clear the phone site's browser data to remove its shortcuts; removing extension data alone does not erase website-origin preferences.

Pressing a shortcut can place a call, initiate a transfer or send in-call tones to the selected call. Message shortcuts open drafts only. PBX codes depend on server permissions/configuration; sending tones does not prove a transfer or conference completed. See [SHORTCUTS.md](docs/SHORTCUTS.md).

Warm-transfer controls ask you to stop an active local recording before starting the private consultation. Returning to the caller does not resume recording automatically.

## Diagnostics, team directory and after-call review

Connection Doctor uses explicit user clicks for microphone/speaker tests. Microphone signal is measured locally for five seconds without recording or upload, then tracks are stopped; late permission grants are also released after cancellation. Speaker success requires your confirmation. Audio tests stop if a call arrives. Connection tests reuse the owned session and do not create another registration/pairing.

Call-quality sampling extracts numerical audio packet/byte counters, jitter and RTT from the current browser peer connection. Raw ICE addresses, SDP, SIP messages and credentials do not enter its DTO or diagnostic report. Copying a report is explicit and uses fixed check IDs/codes, app version/mode/time and numerical indicators. Reports contain no account identifiers, case records, telephone numbers or passwords, and are not automatically uploaded.

The optional authenticated Team directory shares recently active employee names, extension numbers and PBX status with other valid paired accounts on that administrator-enabled PBX. Only recent call activity or observed registration/reachability within 72 hours qualifies. A restricted read-only PBX helper discards customer numbers, channels, credentials and raw CDR rows before returning its projection. The gateway retains only extension IDs and activity timestamps in protected per-PBX hashed files, pruning expired/deleted entries. Live directory responses remain transient in the browser and do not import personal contacts. Historical coverage can be incomplete; old status becomes unknown on a failed/stale refresh. See [Team directory](docs/TEAM-DIRECTORY.md).

After-call notes, outcomes and a pending-review flag use the existing local history record and its existing backup/storage rules. Saved reviews survive reload; unsaved edits remain in memory. CRM submission still uses the selected tenant's request-scoped credentials, the original call identity and confirmed receipts. Local edits do not rewrite confirmed remote activities. Finishing/advancing is explicit and does not imply that an uncertain write failed upstream. Case-note drafts can be explicitly discarded. See [Call workspace](docs/CALL-WORKSPACE.md).

## Website access

Phone-number detection is optional and requests Chrome website permission. Its content script inspects eligible page text and `tel:` links to place call/text controls. It skips editable fields and many code/control elements and uses bounded scans. It does not upload pages or continuously send detected numbers to a server.

When you use a call/text control or selection menu, the selected telephone number, action and source webpage URL can be passed to the extension so it can open the requested workflow. This does not send a text message without your Send action. A trusted calling action can place a telephone call when the dialer is connected. The current page remains subject to its own website's data handling.

## Network destinations and credentials

- **Direct WebRTC:** SIP signaling goes to your configured WSS endpoint; call audio uses WebRTC media paths negotiated with your infrastructure.
- **Hosted SIP gateway:** The HTTPS pairing endpoint receives your PBX server, extension/authentication identity, SIP password and optional name/domain. The gateway proves upstream registration, returns generated browser SIP credentials and a pair token, then processes signaling and relays live call audio between the browser and PBX. Browser-to-gateway WSS/WebRTC protection does not make an ordinary UDP/TCP PBX leg end-to-end encrypted. See server storage below.
- **PBX account metadata:** With a valid paired account, opening Bridge & SMS, refreshing its sender, or sending/scheduling carrier SMS can ask the gateway for the extension's outbound DID. A configured connector uses a dedicated SSH key and pinned PBX host key to run a restricted read-only projection on that PBX. The browser receives only its own safe account fields and normalized sender number, never the SSH key, AMI credentials, raw database response or other users' settings. The currently deployed connector does not provide a general shell or database reader. No automatic connection is made to unknown PBXs without administrator configuration.
- **STUN/TURN:** Optional servers receive the routing/authentication information their protocols require. No third-party STUN service is added automatically.
- **CRM bridge:** When you verify, search, read a case/list or write a CRM activity/task, the client sends the selected provider credentials and requested data to the built-in Republic service API. Native adapters send those credentials to the selected CRM's allowed HTTPS API endpoint. Optional automatic logging sends metadata/notes for linked calls when enabled. IRSLogics case detail responses are allowlisted; raw SSNs and miscellaneous XML are not returned by that normalized route. Case lists/details stay transient in the panel, while explicit case associations, saved contacts and completed-call receipts may persist in local workflow data.
- **SMS/PBX adapters:** Sending carrier messages or executing an enabled PBX action forwards its documented payload to the administrator's configured adapter. Incoming carrier messages are polled only when that capability is configured and the app is open. SIP MESSAGE uses your PBX route instead.

The optional bridge requires a bearer token for data/action endpoints, validates permitted browser origins and binds to loopback by default. It does not intentionally log or persist request credentials, call bodies or message bodies. Other-provider/SMS retry results and one-way request/credential fingerprints use an in-memory cache for up to 24 hours, subject to a size limit and restart. IRSLogics writes additionally use the conservative journal described below; a configured persistent journal survives restart. Your own reverse proxy, adapters, PBX, carrier and CRM may have their own logs and retention policies.

Local recording files are not uploaded to the bridge or CRM by the current implementation. In hosted-gateway mode, live call audio nevertheless passes through the gateway to complete the call. CRM logs contain the explicitly requested call metadata/notes, not the local recording blob. Server acceptance of a message is not proof of delivery.

## Hosted gateway server storage and leases

The hosted pairing gateway retains the upstream SIP password and generated browser SIP secret for the active pairing. It stores them encrypted with AES-256-GCM in its protected state file, with the encryption key held separately in the gateway's restricted server state directory. It persists pair metadata such as the PBX address, username, transport, creation/expiry times and a one-way hash of the API token. The raw API token is returned to the client; it is not stored as plaintext in the pairing state.

The active Asterisk configuration necessarily contains usable SIP authentication secrets so it can register and carry calls. Those generated configuration files and the state/key files are restricted to the gateway service/operator. Encryption and filesystem permissions do not hide credentials or media from an administrator who controls that server.

PBX metadata connectors retain a dedicated private SSH key, pinned host keys and an administrator-controlled PBX mapping on the gateway, separately from client pairing state. The PBX authorizes that key only from the gateway's address and restricts it to the outbound-ID helper. Unpairing one client does not remove the PBX administrator's connector. The connector registry is cached by the API process; outbound DID values are read again for each account request rather than stored in the pairing file. SSH/PBX access logs can record those lookups under the operator's policies.

The default pair-token/registration lease is **six hours**. Expired/revoked tokens cannot authorize new API actions. Unpairing or lease expiry triggers cleanup; active calls may drain before their configuration/secrets are removed, and periodic cleanup or operational recovery can delay removal. Browser storage, server backups, proxy/telephony logs and upstream providers can have different retention. Clearing browser data does not itself immediately revoke an active gateway pairing; use Unpair when available, or let its lease expire.

Native CRM credentials passed to the paired gateway are request-scoped and are not added to the SIP pairing store. Other-provider successful CRM retry results and hashed request/credential identities can remain in memory for up to 24 hours under the bounded retry cache. Gateway and bridge handlers avoid intentionally logging password/token bodies or echoing them in errors; server operators must also configure access/debug logs and backups appropriately.

For **IRSLogics activity, note and task writes**, the hosted gateway keeps a private durable write journal. It stores hashed scope/operation identities and payload fingerprints, pending/confirmed state and timestamps, and allowlisted receipt metadata such as case ID, provider/client receipt ID, kind and confirmation type. It does **not** store the API key, full note text, call payload or task comments. The standalone bridge uses the same persistent behavior when an administrator sets `CRM_WRITE_STATE_DIR`; without a persistent directory, its journal is held in memory for the current process.

IRSLogics journal entries have **no automatic expiry** and remain after a SIP lease expires or is unpaired. The journal has a **10,000-entry maximum**; an administrator must safely archive receipts before accepting new writes at capacity. A pending or uncertain operation is not automatically resent, including after a service restart. The client receives an uncertainty error and must check the case before submitting a new operation. Confirmed unchanged retries return the saved receipt; changing the contents under the same operation ID returns a conflict. A stable hashed Republic Dial marker is included in the remote activity/task text, which is retained according to IRSLogics policy.

Pairing does **not** connect the user's extension to an existing shared SMS application's accounts, inboxes, sending numbers or administrator privileges. Carrier SMS and shared-inbox mapping are not automatically enabled. Any future SMS integration must explicitly bind the authenticated user to their own permitted account/resources; it cannot reuse global administrator authority for every paired user.

## Chrome permissions

| Permission | Purpose |
| --- | --- |
| Storage | Local workflow data and session/optional remembered credentials. |
| Active tab and scripting | Selected-number actions and optional page phone controls. |
| Fixed Republic service origin | Required HTTPS access for automatic release checks and the built-in gateway/CRM/SMS service. |
| Optional website/PBX origins | User-approved website content-script and configured PBX access. |
| Context menus | Call/text selection actions. |
| Notifications | Incoming-call notices, due reminders and scheduled-message results. |
| Alarms | Local reminders, scheduled gateway messages and deferred extension-update retries while Chrome runs. |
| Microphone approval | Browser call audio and local recording. |

## Control and retention

You can disable number detection, disconnect the SIP endpoint, unpair the hosted gateway, disable remembered secrets, remove/change provider tokens, delete local contacts/templates/reminders, export data or remove the extension. Some histories currently have export without a full in-app purge control; clear extension profile storage or the web origin's browser data to erase local data after saving anything needed. Browser deletion or SIP unpairing does not erase remote CRM/provider records, the IRSLogics write journal or server backups. Journal archival is an operator action and must preserve unresolved-operation safeguards. Revoking a CRM/carrier/PBX token must also be done at its provider when applicable.

This document describes the shipped software, not the independent policies of services you connect. Feature and infrastructure limits are listed in [docs/PARITY.md](docs/PARITY.md), [docs/BRIDGE.md](docs/BRIDGE.md) and [docs/GATEWAY-API.md](docs/GATEWAY-API.md).

## Automatic update checks

The client periodically reads version/download metadata from the Republic release site without including PBX, CRM, contact, call or message data in those requests. The extension declares access to that fixed HTTPS service origin so checks do not require repeated permission prompts. Website detection retains its separate optional permission.

The hosted app waits for an idle, saved workspace before reloading a newer release. A short-lived, one-use session marker preserves the dialed number, public phone identity, do-not-disturb preference and an already-saved selected CRM contact ID, and records whether the existing phone should reconnect. It contains no SIP password, owner token, CRM credential or TURN configuration; reconnection relies on credentials already stored under the existing preferences. No new PBX pairing is created to apply an update.

Installed extension packages use Chrome's update mechanism. Open extension pages and pending background sends defer automatic application. Chrome clears session-only extension storage on extension reload/update, disable and browser exit; credentials not remembered may need to be entered again. Chrome controls required permission approval. Developer-mode unpacked installations cannot download and replace themselves through this mechanism.

After the one-time companion installation, compatible phone/CRM/interface features can update from the server through the hosted app's saved-idle checks while the installed package stays unchanged. Metadata can require a minimum companion version/protocol; incompatible phone updates wait for a package update. Changes to permissions, bridge operations or packaged Chrome behavior still require replacing/updating that package. A hosted companion phone window also blocks automatic package application until closed. No remote JavaScript is downloaded into the privileged extension context.

## Incoming-call alerts

Incoming calls can display a large in-app alert, a repeating synthesized ringtone and a flashing browser-tab title. Ringtone style, volume and output speaker are stored with your local settings. These sounds use local Web Audio and no downloaded audio or microphone capture. Browser playback restrictions or unavailable speakers can prevent a ringtone; the app shows an inline recovery message and the settings include an explicit alert test.

Desktop notifications are optional. Browser notification approval is requested only from the explicit Notifications settings button. Desktop alerts may include the caller name and number; turn off Show caller details to hide those fields in desktop alerts. Notification contents are handled by your browser and operating system, whose own history, Do not disturb and Focus Assist policies apply. The app requests dismissal when the call stops ringing. Extension session metadata used to open the correct call stores only call ID, owner document/tab identity and a timestamp, not caller names or numbers.

Bring-to-front applies to the extension's existing call window without creating or reloading another phone. A website cannot reliably take foreground focus from another application; clicking its desktop alert opens the in-app call controls. Keep the dialer open and connected to receive calls. The Test incoming-call alerts button creates a clearly labeled six-second local simulation with no phone call, message or CRM write.