<metaname="description"content="Short answers to what people ask before they trust the software with anything. Every one of them is drawn from the documents linked alongside it, so if an…">
<metaproperty="og:description"content="Short answers to what people ask before they trust the software with anything. Every one of them is drawn from the documents linked alongside it, so if an…">
<metaname="twitter:description"content="Short answers to what people ask before they trust the software with anything. Every one of them is drawn from the documents linked alongside it, so if an…">
"text":"<p>No. There is nothing to register, no email address, no phone number and no password. You open the page, your browser generates a key pair, and you send the resulting invitation to the person you want to talk to. Nothing about you is stored anywhere, because there is nowhere to store it.</p>"
}
},
{
"@type":"Question",
"name":"Where are my messages stored?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Nowhere. Messages travel directly between the two browsers over WebRTC and are held only in the memory of the two devices taking part. There is no message server, no database and no backup — which also means a conversation you close is gone, and nobody can hand it over later because nobody has it.</p>"
}
},
{
"@type":"Question",
"name":"Is there a server in the middle?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>No, and there is not even a signalling service. The offer and the answer that set up a connection are moved between the two people by whatever channel they already have: a QR code, a pasted block of text, a link. That is the unusual part of the design and it shapes everything else — the out-of-band channel is assumed to be readable and rewritable by an attacker, which is exactly why the safety code comparison exists. See <a href=\"/docs/architecture/\">ARCHITECTURE.md</a>.</p> <p>A TURN server, if you use one, relays encrypted packets. It never sees message content, and it is optional.</p>"
}
},
{
"@type":"Question",
"name":"What encryption does SecureBit.chat use?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Key exchange is ECDH on P-384, message payloads are AES-256-GCM, and messages carry ECDSA signatures with full ASN.1 validation of every key that arrives. Session keys rotate continuously through a Double Ratchet and are discarded after use, so a key recovered later cannot open earlier conversations. The transport underneath is DTLS, as WebRTC requires. Everything runs on the browser's Web Crypto API rather than hand-rolled primitives — <a href=\"/docs/cryptography/\">CRYPTOGRAPHY.md</a> sets out the key schedule in full.</p>"
}
},
{
"@type":"Question",
"name":"What is the safety code, and why do I have to compare it?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>It is a short code derived from both sides of the completed key exchange. If the two of you see the same code, nobody sat in the middle of the exchange; if someone did, the codes differ and the session is not what it claims to be.</p> <p>The comparison has to happen over a channel an attacker cannot impersonate — in person, or a voice you recognise. Comparing it inside the chat itself proves nothing. It is enforced rather than merely displayed: until both sides confirm, reconnection signalling, call setup, delivery receipts and incoming file transfers are all refused, and three incorrect entries end the session.</p>"
}
},
{
"@type":"Question",
"name":"Is it free, and can I read the source?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Yes to both. The software is free, has no paid tier and no upsell, and is published under the MIT licence at <a href=\"https://github.com/SecureBitChat/securebit-chat\">github.com/SecureBitChat/securebit-chat</a>. Nothing is minified beyond recognition or hidden behind a build you cannot reproduce; <a href=\"/docs/configuration/\">CONFIGURATION.md</a> describes building and running it yourself.</p>"
}
},
{
"@type":"Question",
"name":"Do I have to install anything?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>No. It runs in any current browser with WebRTC and the Web Crypto API. It can be installed as a Progressive Web App if you would rather have an icon, and there are native desktop builds for Windows, macOS and Linux. Calls are not yet available on the Linux desktop build; they work everywhere else, including in the browser.</p>"
}
},
{
"@type":"Question",
"name":"Can the person I am talking to see my IP address?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>On a default connection, yes — a direct WebRTC path means each side learns the other's address. That is how a direct connection works, not a flaw in this implementation.</p> <p>Relay-only mode prevents it: it sets <code>iceTransportPolicy: "relay"</code>, so all traffic goes through a TURN server and the peers see only the relay. The trade is that the relay operator can then see both addresses and the timing of the traffic, though never the content. Choose according to who you are protecting against.</p>"
}
},
{
"@type":"Question",
"name":"Do I need my own TURN server?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Only for relay-only mode, or when a direct path cannot be established at all. Public STUN defaults are built in and are enough for most connections. You can paste your own STUN and TURN servers under Advanced network settings; they are validated against an allowlist of schemes, hosts and transports before they reach the connection.</p> <p>One thing worth knowing: any TURN credential sent to a browser is public by definition, because the browser has to read it. Apply quotas on the TURN server rather than relying on the credential staying secret. <a href=\"/docs/configuration/\">CONFIGURATION.md</a> covers the setup and how to verify it works.</p>"
}
},
{
"@type":"Question",
"name":"Can I send files, and how large?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Yes, over the same encrypted channel, with a per-file AES-GCM key and a SHA-256 integrity check. The receiver sees name, size and type and has to accept before any buffer is allocated or a single chunk is sent.</p> <p>The ceiling is 100 MB per file, with lower limits by category: images 25 MB, PDFs 50 MB, text 10 MB, archives 100 MB, audio 20 MB. Executable and scriptable formats are blocked outright — <code>.exe</code>, <code>.js</code>, <code>.html</code>, <code>.svg</code> and others — and the file extension, not the browser-supplied MIME type, is the boundary that decides.</p>"
}
},
{
"@type":"Question",
"name":"Are group chats and calls supported?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Yes. Encrypted voice and video calls shipped in early 2026, and group communications are current work. Group sessions keep the same properties as one-to-one ones: no server holds the conversation, and members verify each other. <a href=\"/docs/calls/\">CALLS.md</a> covers codec choices and how the connection adapts to a poor network.</p>"
}
},
{
"@type":"Question",
"name":"Is there a mobile app?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Not yet. The web application works in mobile browsers today and can be installed to the home screen as a PWA. Native iOS and Android builds are planned; the roadmap on the front page lists where they sit relative to the rest of the work.</p>"
}
},
{
"@type":"Question",
"name":"What does it not protect against?",
"acceptedAnswer":{
"@type":"Answer",
"text":"<p>Read <a href=\"/docs/use-policy/\">USE-POLICY.md</a> before relying on this for anything that matters. In short: a compromised device sees your messages exactly as you do, and no transport encryption helps. The person you are talking to can screenshot or repeat what you said. A safety code you skipped protects nothing. And someone watching your network can see that you are using a WebRTC application, even though they cannot see what you send — the software does not hide its own use.</p>"
