Skip to main content

What a git host can still see

xoron
xoron
positive-intentions

Encryption in Glitr is real, and it is not a cloak of invisibility. A host administrator browsing files should not be able to read “see you at 6.” They can still see file names, sizes, dates, and that the repo is busy.

Threat model in one line: protect message content from the host; do not expect the host to be unaware that you chat.

That sentence is the honest product. Messengers that promise anonymity-by-magic are selling a feeling. Glitr will not use unsafe sentences: unaudited end-to-end forever against nation states, compatible with the Signal app, or the entire messenger is open source.

Sealed​

  • Message bodies, attachment bytes on inbox/sent, in-progress file-transfer rows, and similar documents marked to be encrypted at rest in the mailbox.
  • Your local working copy, unlocked with the encryption password you entered at connect.
  • Handshake material that is cascaded to the recipient (AES → Signal → PQXDH, then RSA hybrid → ML-KEM) before it is written to signaling (the other person can open it; the host should see ciphertext).
  • Sent and inbox records stored as sealed documents on the respective repos.

Password sealing of your files is Argon2id then AES-GCM. That job is separate from the recipient cascade. Lose the encryption password, lose sealed documents. We cannot restore them.

Schema stamps stay plaintext. Sealed folders still have those paths; the file contents are envelopes. You do not have to edit those files by hand.

Intentionally readable (coordination)​

Some files are left readable so the other client can do its job without your password:

  • Read receipts on the git path — so the sender can turn ticks blue after a fetch.
  • Signaling envelopes as files on disk — the inner SDP is encrypted to the peer; the fact of a file per contact is visible.
  • Public profile material needed to verify a contact (the thing that moves Pending → Active). That includes an RSA public key and protocol bundles (Signal, PQXDH, ML-KEM) so someone can encrypt the first message to you.

If everything were sealed with only your password, nobody else could ever start a conversation with you.

Outbound on your repo is peer-visible as ciphertext. A body field may exist as a local convenience; peers decrypt the ciphertext, not that column. Logout deletes the signaling row. You are not leaving a permanent “call me” file after you close the door.

What a host can infer anyway​

Even with bodies sealed:

  • That you have a mailbox repository.
  • How often it changes, and roughly how large it is.
  • Who you gave read access to (collaborators, tokens).
  • IP addresses when you push and fetch (normal git hosting logs).
  • On the web, a CORS proxy also sits on the path and sees git HTTP.

A group send writes one outbound copy per member. Three members are three files. Fan-out is visible as activity even when every body is ciphertext.

GitHub, GitLab, and Codeberg may treat this mailbox use as against their terms. They may throttle, block, or close the repo. Host policy is part of the threat model, not an afterthought. See Using GitHub, GitLab, and Codeberg.

What we can see​

We do not host your repository. We do not receive a copy of your token. If you use a public CORS proxy or a public try experience, that infrastructure sees what any web proxy sees. The Glitr website itself is a documentation site. glitr-domain is hosting for glitr.io. It is not a chat server.

  • The encryption password is yours. Lose it, lose sealed documents.
  • Git tokens are host credentials. Revoke them on the host.
  • Live links are between devices. A network observer on the live path sees that a connection exists; chat bodies and file chunks are application-layer cascaded (same stack as git outbound), not only DTLS. File frames are slices of that ciphertext, not a second wrap.

Product ICE is STUN-only. Ordinary WebRTC ICE may involve public ICE servers — that is how browsers find a path, not how Glitr stores chat. A VPN can hide a WebRTC address leak; it has its own tradeoffs. Live WebRTC cannot go over Tor the way git mailbox traffic can.

Open handshake, closed messenger​

The Signal Protocol implementation used for classical handshake work is open source. You can read it, run it, and audit it:

The rest of Glitr is not published as source. Open Signal is a trust anchor for the handshake, not a promise that every layer of the messenger is public. Post-quantum pieces (ML-KEM, PQXDH) are documented for users who want the “future computers” story.

Anonymity is listed as a requirement on the roadmap and currently disclaimed. Minimize metadata is in progress: bodies are sealed; a host can still see activity, access, and IPs. A dedicated threat-model draft is still WIP. Regular security audits are planned; the messenger is closed-source and unaudited.

If you want a host that cannot read “see you at 6,” this is the split. If you want a host that cannot tell you are chatting, you will need a different design — onion routing on the live path is not what a browser app can promise today.

The full split: What is encrypted vs what a host can see. Cascade wording: Signal Protocol and the post-quantum path. Roadmap status: Roadmap.