Written against the running code rather than around it: every retention period and deletion mechanism below names the thing that enforces it, so it can be checked. Where the honest answer is "we cannot promise that," it is written down instead of left out.
BurnerRoom is operated by an individual trading as Burner Room, based in Australia. This policy covers the BurnerRoom website at burnerroom.com and the private chat application your Room Key opens, which is served from a separate host given to you with your key. Both are covered by this one policy, and everything below applies to each of them.
Contact for any privacy question, request or complaint: sab.go@techsabby.com. If you are in the EEA, the UK, or another jurisdiction with its own data protection law, Your rights below explains how that applies to a business based in Australia.
There is no account: no phone number, no email address, no username, no password. Every message is encrypted on your device before it leaves it, so we cannot read your conversations — not "we choose not to," we technically cannot. Rooms end on a timer you set, or when you destroy them, and take their contents with them in a single delete. Payment records are kept only as long as the law requires, then deleted automatically. We run no analytics and no tracking pixels on either domain.
The rest of this page is the detail behind those five sentences, including the parts genuinely outside our control.
A room key is two halves. Only the first half — the half that proves you are allowed in — is ever sent to us, and it is stored as a one-way hash. The second half, which every encryption key in your conversation is derived from, is generated in your browser and never transmitted to us at all.
| What we hold | Why |
|---|---|
| Owner Key hash | Lets the server answer "is this the owner?" without holding anything that could reproduce the key.A one-way HMAC of the auth half only. The secret half never reaches us. |
| Guest Key hash | The same idea, for the one guest a room may have at a time. Lets the owner issue and revoke guest access. |
| Room identifier and rotation counter | Ties a key to its room, and records how many times the owner has rotated the room's secret by revoking a guest.The counter is useless to us on its own — deriving anything from it needs the secret half we do not have. |
| Connection and role state | Which sockets are connected and whether the owner and guest slots are filled — what makes a two-party room work, and stay two-party. |
| Push subscription, if you enable notifications | The endpoint your browser vendor gives us so a notification can reach your device. Expires 24 hours after its last refresh. |
| Encrypted message blobs, only when relayed | Held for delivery when your recipient is briefly offline. Ciphertext to us in every case. A large attachment — roughly a megabyte or more — is never relayed at all: it waits on your device and goes directly to the other browser when both of you are connected, so we never hold a copy of it. Smaller messages and attachments are still held for you as described here. |
Payments are processed by Stripe. Card details never touch our servers. What we keep is Stripe's own reference for the transaction, the amount, the currency and the status — enough to reconcile a payment, and nothing that identifies you personally.
We do not store your email address or your name. We previously stored the email Stripe returned from checkout; that column was dropped from the database and the code no longer writes one. Stripe keeps its own records of the transaction under its own privacy policy.
Your payment identity is not your room identity. Nothing links the person who paid to the conversation that follows, and a guest cannot see who bought the room.
Your browser generates the Owner Key and shows it to you before you are sent to Stripe. Only a one-way hash of its auth half is ever submitted. We hold a short-lived, single-use token so the page you land on after payment can be recognised as yours — it expires within 24 hours whether or not you use it.
There was, until recently, an encrypted copy of the whole key held on our side for that 24-hour window so the browser could collect it after the redirect. That column has been dropped from the database entirely. The distinction matters: "we do not store it" is a promise, "there is no column that could" is a property of the schema.
Every message is encrypted in your browser before it is sent. When the direct browser-to-browser channel is up, messages never touch our servers at all. When it cannot be established, an encrypted blob is held for delivery and we see ciphertext only. In neither case is there a plaintext copy anywhere on our side to hand over, to lose, or to be compelled to produce.
The full technical description — which primitives, which paths, and where the protection is weaker than you might assume — is on the security page.
Deletion here is not a manual, best-effort process. Each row below names the mechanism that enforces it, and each of those runs on our servers — nobody needs to be online, or to still have the tab open, for it to happen.
| Data | Retention | Mechanism |
|---|---|---|
| Individual messages | 5 minutes after being read, or 12 or 24 hours — your choice per room | Each message carries its own timer, applied on both devices as well as to any copy held for delivery. |
| Undelivered message blobs | 7 days maximum | A server-side sweep deletes anything past its time-to-live, so an abandoned room cannot hold queued ciphertext indefinitely. A room also holds no more than 5,000 stored items at once, counting delivery receipts and other control blobs alongside messages. |
| A whole room, on expiry | Up to 24 hours, or no timer if you prefer | A backend alarm forces every connection closed and wipes the room's entire storage — credentials, state, and any queued ciphertext — in one operation. |
| A whole room, on revoke or destroy | Immediate | Revoking a guest rotates the room's secret and deletes its stored messages server-side; destroying a room asks for the same deletion and waits for confirmation before clearing your device. If that call fails, the 7-day sweep still catches it. |
| Key delivery token | 24 hours maximum | Refused after expiry regardless, and deleted by an hourly scheduled job. |
| Payment record | 5 years | The same scheduled job. Australian tax and financial recordkeeping law requires this period, so we cannot shorten it on request. |
| Key hashes and room binding | As long as the room is usable | Never deleted by the payment job. When a payment ages out at 5 years, only the link between the receipt and the key is removed — a room should not stop working because its receipt got old. |
We use no tracking cookies and no third-party advertising cookies. Browser storage is used for strictly functional purposes: the one-time token for your session, and your local copy of an active conversation, encrypted with a key derived from your room key. That storage never leaves your device, and we never receive the key that opens it.
Because the key that decrypts your local history comes from your room key rather than from your device, anyone holding both your key and a copy of your browser storage can read it. That limitation is on the security page too, rather than buried here.
When something fails — a handshake that would not complete, a connection that dropped — the app sends a short fixed event code so we can tell that a class of failure is happening. That is the entire payload: a code from a fixed list, and a count of how many identical ones the app's own rate limiter suppressed. No message content, no room identifier, no key, and no free text — anything not matching the expected code format is discarded rather than logged.
These codes land in our infrastructure provider's log stream and age out on its retention schedule. They are read to fix bugs. There is no analytics product behind them, no profile built from them, and nothing in them that could be tied back to a person.
The website, the chat application and the database all run on Cloudflare. For everything described here, Cloudflare is our infrastructure provider and data processor: it stores and transmits data on our instructions, and does not use it for its own purposes. As part of routing your traffic and defending the service against abuse, it processes standard connection metadata such as IP address and request timing. We have no separate analytics layer collecting that ourselves, and Cloudflare Web Analytics is switched off on both domains.
Every deletion described above is a real, immediate delete against the live database or the room's storage. There is no soft delete, no recycle bin, and no admin panel where we could pull a room back.
What we do not control: Cloudflare's database service keeps rolling point-in-time recovery snapshots for up to 30 days, as a platform-level disaster recovery feature. It is not a setting we can switch off and not a mechanism we can reach outside Cloudflare's own recovery tooling. In practice: for up to 30 days after we delete something, a snapshot of it may still exist in that backup layer, even though it is gone from the live database we operate and query.
We disclose this because a policy claiming "instantly and completely gone everywhere" would be misleading. What we can honestly promise is immediate deletion from every system we operate, control, or can query — and a hard 30-day ceiling, set by our infrastructure provider, on anything beyond that. Cloudflare operates a global network, so data may be processed outside your own country as part of normal routing, under Cloudflare's own cross-border transfer safeguards.
We handle personal information in line with the Australian Privacy Principles under the Privacy Act 1988 (Cth). If you are covered by the GDPR or an equivalent law, you have formal rights of access, rectification, erasure, restriction, portability, objection, and complaint to your data protection authority.
Those rights have unusually little to bite on here, and that is deliberate rather than evasive. Access: there is no account, email, name or profile, and room keys are stored as hashes we cannot reverse — if you ask what personal data we hold about you, the honest answer is none. Rectification and erasure: the same reason; messages are deleted automatically on the schedule above, and there is no profile to correct. Restriction and portability: there is no data profile to restrict or export. Objection: we process nothing on the basis of legitimate interest — only what running a room and taking a payment requires.
Two honest carve-outs. A payment record cannot be erased before 5 years, because Australian recordkeeping law requires us to keep it; if you ask, we will confirm what we hold and restrict its use to that purpose until it is deleted automatically. And we never erase message content on request, because there is nothing for us to erase — we never had your plaintext, and the ciphertext deletes itself on the schedule above whether or not anyone asks.
You can always contact us first at sab.go@techsabby.com, and you keep the right to complain to your local data protection authority.
We cannot recover a lost Owner Key. It is generated on your device, and we hold only a one-way hash of half of it. There is no reset flow and no support ticket that gets it back — the same property that stops us handing it to anyone else stops us handing it back to you.
We cannot recover a room after it expires or is destroyed. The deletion is unconditional and there is no grace period. Whatever either of you had already saved on your own device stays on that device; that part is outside our reach in both directions.
A room owner can manage the Guest Key for their own room. They can issue, rename and revoke it. "Guest" is therefore not anonymous to the owner of that room — a deliberate part of how room administration works. It has no bearing on what we can see.
We cannot verify who is holding a key. Anyone with a valid Owner or Guest Key can reach the room it belongs to. Keep them as carefully as you would a password.
We can see that a conversation is happening. Contents are opaque to us, but room identifiers, message sizes, connection times and message timing are visible to our infrastructure and to Cloudflare, which operates it.
BurnerRoom is not directed at children, and we do not knowingly collect personal information from them. Because the service requires no account and collects no identifying information, we have no practical way to determine anyone's age. If you believe a child has used the service in a way that concerns you, contact us at the address above.
The updated version is published at this URL with a new date on it. Material changes — anything altering what we collect, how long we keep it, or your rights — are called out at the top rather than buried in a diff.
Generated on this device a moment ago. We never receive it, so we cannot show it to you again and cannot recover it. Save it before you continue.
Your key is now active. It opens one private Burner Room on your private chat host.