Security model

This page describes what Gluline actually does today, including the parts that are weaker than you may expect. It is written to be checkable against the product rather than aspirational. For the legally binding description of what we collect and why, see the Privacy Policy.

Identity

• Gluline is not anonymous. A phone number is required to register and to sign in; we store it in normalized international (E.164) form and it is the primary identifier of your account.
• An email address can be added as a second way to sign in to that same phone-based account. It does not replace the phone number and does not make the account anonymous.
• There is no mode in which the server does not know which account sent which message.

Ordinary (cloud) chats

Message bodies are encrypted on your device with a per-chat room key (AES-GCM, with a per-message key derived from the room key via HKDF). We store the ciphertext plus one copy of the room key wrapped for each member with ECDH + HKDF + AES-GCM. Whether we can unwrap that copy depends on how your private keys are protected:

• Device-wrapped keys (current format). Your private keys are wrapped with a key that stays on your device and is never sent to us. We hold only the ciphertext, so we cannot unwrap the room key and cannot read those chats.
• Legacy phone-derived keys (older accounts). On accounts created before the current format, the wrapping key is derived from the phone number — which we store. For those accounts we can derive the private key and therefore can read the chat content. This is not theoretical and it is not something you opted into: it is how the account was created. The migration to device-wrapped keys has not shipped, so if your account is old, assume this applies to it.

In short: for ordinary chats, "end-to-end encrypted" is true for accounts on the current key format and false for legacy accounts. Any page or screen that states it without that distinction is over-claiming.

There is no separate "secret chat" mode

Gluline used to advertise a second, libsignal-backed chat type. It has been removed from every app. Nothing replaces it, because nothing needed to: an ordinary chat with the AI assistant switched off is already encrypted with a room key we do not hold, which is the same protection the separate mode was there to offer.

What the room-key scheme does not give you, and what we will not claim: forward secrecy and post-compromise security. One room key covers the whole conversation until it is rotated, so someone who obtains that key — and the stored ciphertext — can read the messages it covers, past and future. A per-message ratchet would bound that; the room key does not.

The AI assistant

When the assistant is on, your client sends decrypted message text to our servers so the model can read it. That is the point of the feature, and it is the one case where your content deliberately leaves your device in the clear.

• The switch is per account, not per message. In a one-to-one chat the assistant is used only when both people have it on.
• There is no escrow key and no signed per-chat consent record. Internal documents that describe a room key "released only under a signature from every participant" describe a design that is not implemented; do not rely on it.
• Turning the assistant off for your account, or off for one conversation, stops your assistant from being fed that conversation.

Files, images and voice messages

• File contents are encrypted on your device before upload; we store the encrypted blob.
• Image previews are not encrypted. The app uploads a small (200 px) plaintext thumbnail so previews render quickly, and we store it — including in chats you have turned the assistant off for.
• The exact byte size and exact duration of a media file are sent to us as metadata, so we know how long a voice message is even though we cannot play it.

Calls

• One-to-one calls are peer-to-peer WebRTC with DTLS-SRTP. The key fingerprints are exchanged over the encrypted signalling channel and pinned, so we do not hold the media keys. If no direct path can be established the call relays through a TURN server, which forwards the still-encrypted stream.
• Group calls (three or more people) are not end-to-end encrypted. They run through our LiveKit SFU, which decrypts each participant's audio and video in order to forward it, and no client enables frame-level encryption. A group call is protected in transit but readable at that server.

Losing access to your history

• Mobile. A recovery code is shown once at sign-up, and the app also stores one device key in the platform's own vault (iCloud Keychain on iOS, Google Block Store on Android) so a new phone can restore. Both can be declined; without either, history is unrecoverable.
• Web. The web client currently uploads no recovery blob. If you use Gluline only in a browser and clear your site data, your history becomes permanently undecryptable — by you and by us. Sign in on a phone if that history matters to you.

What we can see regardless

• Metadata needed to deliver messages: who talks to whom, chat and user IDs, timestamps, message and file sizes, and that a message exists.
• Your IP address and client details, as with any service you connect to.
• Your address book, if you granted the contact-sync permission — including numbers of people who do not use Gluline.

Web-client caveat

In a browser, the encryption code is delivered by our server on every load, so a compromised or malicious server could ship modified code that leaks your keys. No web application can defend against this. The guarantee that we cannot read your content holds in the browser only against an honest server; the native apps are fixed, signed binaries and do not have this weakness.

Key verification

• Trust-on-first-use: each account has a key fingerprint, shown in the app, with a warning if it changes.
• For real assurance, compare fingerprints with your contact over another channel.

Limitations we are not hiding

• Gluline has not been independently audited, and its protocol is not a formally reviewed one like Signal's.
• Metadata is not encrypted.
• Group-call media is readable at our SFU (above).
• Legacy accounts' cloud chats are readable by us until the key migration ships (above).
• No forward secrecy and no post-compromise security. A chat's room key covers every message until it is rotated, so a key that leaks reads that whole span.