Slack VS SecureBit.chat

SecureBit.chat's answer:

Unknown by design. SecureBit.chat has no accounts and collects no identifiers, so we cannot see who uses it.

SecureBit.chat's answer:

There is no server anywhere in the path, including signaling.

Most private messengers still route your connection through infrastructure someone operates. Signal has servers. Session has a node network. Even federated systems have homeservers. That operator can be compelled, breached or shut down, and the иconnection graph exists somewhere by definition.

SecureBit.chat removes the operator entirely. Participants exchange a connection descriptor out of band, through whatever channel they already trust, and the clients connect directly over WebRTC. There is no account to register, no identifier to subpoena, no server log to seize and no connection graph to leak, because none of it is ever created.

The second unusual property is that one protocol has two implementations. The web client is self-contained and runs from a browser with nothing installed. Desktop and native mobile clients share a Rust cryptographic core. All of them are wire-compatible, so the person you are talking to can be on a different implementation entirely.

SecureBit.chat's answer:

Only for one reason: because the absence of an operator matters more to you than convenience.

Signal is the right choice for most people and we say so plainly. It is easy, audited, and end-to-end encrypted by default. It also requires a phone number and runs on servers operated by an organisation. If that is acceptable in your threat model, use Signal.

SecureBit.chat is for the cases where it is not. There is no phone number because there is no registration. There is no metadata because there is no server generating it. The trade you make is real and we do not hide it: establishing a session requires a manual exchange of a connection descriptor, which is more work than tapping a name in a contact list.

Against Briar and SimpleX, which share the same philosophy, the practical differences are that SecureBit.chat runs in a browser with nothing installed, works across desktop and mobile with wire-compatible clients, and does not depend on Tor or on any relay network being reachable.

We have not had an independent third-party audit. Signal, Threema and Session have. If audited-by-a-named-firm is a requirement for you, that is a legitimate reason to choose one of them instead.

SecureBit.chat's answer:

People for whom a metadata trail is a concrete problem rather than an abstract preference, and who will accept friction to avoid one.

In practice that means journalists and their sources, researchers and activists in hostile environments, security professionals, and privacy-focused developers who want to read the protocol before trusting it.

It is also used for one-off sensitive conversations by people who do not need a permanent messenger at all: a single descriptor exchange, a conversation, nothing left behind.

It is explicitly not aimed at replacing everyday chat with friends and family. Anyone who wants a contact list and instant setup will be happier with Signal, and we would rather say that than acquire users who will be disappointed.

SecureBit.chat's answer:

It started from a simple observation: nearly every "private" messenger still needs infrastructure, and infrastructure has an owner. Encryption protects the contents of a message. It does not remove the record of who spoke to whom, when, and how often, and that record is frequently the part that matters.

The question was whether a messenger could work with no server at all, including no signaling server, and whether the price in usability would be tolerable. The answer turned out to be yes, at the cost of a manual exchange of a connection descriptor to establish a session.

The project is built and maintained by one developer. That constrains the pace and it is the reason there is no third-party audit yet, since independent audits are expensive and this project has no revenue. What was possible instead was a structured internal security review of the protocol and web client, which produced 15 findings. All High and Medium severity issues are closed and the full report is published, including the items that remain open.

Publishing the open findings alongside the closed ones is deliberate. A security tool that only shows what it fixed is asking for a trust it has not earned.

SecureBit.chat's answer:

• Rust for the cryptographic core shared by desktop and native mobile clients
• WebRTC data channels for direct peer-to-peer transport
• WebCrypto API in the self-contained web implementation
• ECDH and ECDSA over P-384 for key agreement and signatures
• DH ratchet providing per-message forward secrecy
• CBOR with zlib compression for the connection descriptor format
• Fly.io for hosting the static web client and project site
• Cloudflare for DNS and edge