Privacy — Kintrel

Privacy, in plain language

We carry your messages.
We cannot read them.

Kintrel is designed so Confederated Technologies never receives the keys needed to decrypt your conversations. This page distinguishes message privacy from the limited data any working delivery service must process.

Effective August 1, 2026

The short version

No message-content logs. No server-side decryption.

Message text, attachment contents, and the keys that decrypt them stay on participant devices. Group and channel titles, membership, and delivery facts do not: the relay needs that metadata to enforce each roster and route ciphertext.

01 / Privacy architecture

Encryption happens before delivery begins.

Kintrel clients establish encrypted sessions and encrypt message content locally through the Thureos cryptographic core. The service receives an opaque ciphertext envelope, forwards it to each intended device, and cannot turn it back into plaintext.

One-to-one sessions advance Double Ratchet keys. Group and channel conversations use sender-key chains, while removal triggers rotation before future content. In both cases, decryption remains on participant devices.

End-to-end encryption protects content. It does not make a delivery service blind to every fact: the relay must know which registered device should receive an envelope, whether delivery succeeded, and when an undelivered item should expire.

02 / Data we process

Small, specific categories.

Account and authentication data

Account identifiers, the profile details you provide, registered device records, and session information needed to sign you in through CTI’s identity service.

Public cryptographic material

Public identity keys and prekeys that another client needs to establish an encrypted session. Private keys never belong on the relay.

Routing and delivery metadata

Sender and recipient account/device identifiers, envelope type, server receive time, delivery acknowledgements, queue state, and other information needed to route and retry ciphertext.

Group, channel, and invitation metadata

The relay stores each group or restricted channel’s plaintext title, parent relationship, membership and roles. It also processes invitation parties and deadlines. This lets it enforce a channel’s separate roster and fan ciphertext out only to that roster. A channel is not listed to parent-group members who are outside it, but the relay itself necessarily knows the channel and its membership.

Encrypted payloads

Opaque message envelopes and encrypted attachment blobs may be held temporarily so an offline device can receive them later. Their plaintext and attachment keys are not available to the server. Message bodies, quoted previews, attachment keys, timers, mention targets, and the member preview delivered with a group invitation remain inside end-to-end encryption.

Connection and security data

Infrastructure necessarily processes network information such as IP addresses, request timing, response status, and authentication or abuse signals to connect clients, protect accounts, and keep the service available.

03 / Retention

Ciphertext is a queue, not an archive.

A queued envelope is deleted when the destination device acknowledges it, or when its bounded expiry is reached. The server’s shipped defaults cap ordinary undelivered envelopes at 30 days, encrypted attachment blobs at 7 days, and reconstructable device-sync traffic at 10 minutes. Deployment policy may shorten those windows.

Account, device, group/channel membership, pending-invitation, title, relationship, and public-key records last as long as they are needed to provide the account, its conversations, and active devices. Security and operational records follow separate, limited operational retention appropriate to their purpose.

Deleting an account removes its identity and account-owned relay records. Kintrel retains only a one-way subject digest needed to reject access tokens issued before deletion; that marker cannot recover the deleted account identifier or profile.

04 / Operational logs

“No content logs” is precise. “No logs at all” would not be.

Kintrel’s application logging is deliberately configured not to record ciphertext, envelope bodies, access tokens, or key material. We do not log readable message content because the server never has it.

Narrow application and infrastructure logs are still necessary to diagnose failures, defend the service, and understand its health. They can contain timestamps, request outcomes, internal identifiers, routing events, aggregate retention counts, or connection/security metadata. They are not conversation histories and are not used to build advertising profiles.

05 / Service providers

Delivery infrastructure never gets a plaintext exception.

Kintrel uses CTI-managed hosting and identity infrastructure. When enabled, Apple or Google push services may carry a content-free wake or minimal call-notification metadata so an offline app knows to reconnect. Message plaintext and the keys needed to decrypt it are not placed in push payloads.

We do not sell personal data or message metadata. We may disclose limited records when legally required, but end-to-end encryption means we still cannot produce plaintext we never possessed.

06 / Your choices

Your devices remain the center of gravity.

  • Choose which devices are linked to your Kintrel account.
  • Remove a device you no longer control from account settings.
  • Accept or decline a group invitation before joining; use restricted channels to choose a smaller roster inside a group.
  • Keep the default confirmation before a decrypted file opens, shares, saves, or plays in another app—or turn that device-local reminder off.
  • Use the desktop privacy screen to cover Kintrel when its window is inactive; sensitive messages relock regardless of that preference.
  • Permanently delete your account in the app under Config → General → Delete account.
  • Use the Compose Multiplatform web client without installing a native package. It keeps keys and message history in durable per-account browser storage and declines to run where the browser cannot provide it; current availability is shown on the downloads page.
  • Contact CTI to request access to account data or help with deletion, subject to security and legal requirements.

Clearing local application data can permanently remove locally held message history and private key material. Because the server cannot reconstruct those secrets, keep control of every device and recovery method you rely on.

07 / On-device protection

Encryption cannot control every copy after decryption.

By default, Kintrel explains when opening, sharing, saving, or externally playing a file will put a decrypted copy under another app or storage provider’s control. Turning off that reminder does not relax separate restrictions that block protected or disappearing files from the ordinary open-with and share-sheet paths. Saving and external playback are explicit exceptions because they are user-directed ways to keep or view a file; their confirmation states the consequence plainly.

Desktop clients can cover the app whenever the window loses focus. Android requests system screenshot and recent-task exclusion, iOS covers the scene before an app-switcher snapshot, and Windows requests native screen-capture exclusion. These are best-effort platform controls: they cannot stop another camera, a capture path the operating system does not expose, or software that has already compromised an endpoint.

Sensitive messages require fresh device-owner authentication where the platform can support it and relock on blur or background. Disappearing messages are deleted on their absolute deadline from state Kintrel controls, but Kintrel cannot recall a screenshot or an outside copy a recipient chose to make.

08 / Changes & contact

Questions deserve a human answer.

We may update this notice as Kintrel evolves. Material changes will be reflected here with a new effective date. For privacy questions or data requests, contact Confederated Technologies through its official website.

Contact Kintrel support