Legal

Privacy Policy

Last updated: 10 August 2026

The short version

We have no accounts, no database, no analytics, no tracking cookies and no access logs. We cannot read your messages or files, and we do not keep them. What unavoidably exists is network metadata, held briefly in memory and by the network provider in front of the Service. One thing is written down, and only if the operator of this instance has turned it on: a suggestion you type into the box on the front page is appended to a file, along with the hour it arrived. That file is the only thing the Service keeps outside memory.

Two pages, two policies

The front page and the gate are separate documents, served with separate Content-Security-Policy headers, and this distinction is the one thing in this policy worth reading twice.

• The gate (/app, and every page reached from it) is served with default-src 'none'. It may load scripts, images, styles and connections from this origin and from nowhere else. That is enforced by your browser, not promised by us: a third-party script cannot run there even if we wanted it to. Everything below about what we do not collect applies to this document absolutely.
• The front page may carry a sponsor slot. If it does, that slot is declared in that page's policy alone and can never load on the gate. A third-party sponsor could set its own cookies or identifiers on that page and would be subject to its own privacy policy, not this one. At the time of writing no sponsor slot is enabled and the front page loads nothing from any other origin.

Nothing about a gate, including its link, its code, its secret or the fact that you opened one, is available to anything on the front page: the secret lives in a URL fragment, which is never sent to a server, and the two documents share no script, no storage key and no memory.

What we do not collect

• No name, email address, phone number or account of any kind.
• No message content, file content, file names, file sizes or file types. These are encrypted on your device before transmission and the keys never reach us.
• No history of who connected to whom, or of any past session.
• No analytics, telemetry, fingerprinting, advertising identifiers or third-party trackers of our own, on any page. The gate loads no third-party scripts, fonts or images at all; see "Two pages, two policies" above for the front page.
• No web server access logs.

What exists while a gate is open

For the lifetime of a session only, and only in memory, the server holds:

• a random room identifier, derived from your secret in a way that does not reveal it;
• a second one-way value derived from your secret, kept as a hash, used only to check that a joining device actually holds the link;
• a random session token for each participant;
• a yes-or-no flag recording whether a room password was set, so a joining device can be prompted. The password itself never reaches us;
• expiry times;
• the participants' live connections, so that encrypted handshake messages can be passed between them.

The handshake messages themselves are relayed as opaque ciphertext. The server cannot read them, which means it cannot see the network addresses they contain.

This state is destroyed when the gate expires, when any participant burns it, or when the server restarts. None of it is written to disk.

Abuse prevention

To stop one user from denying the Service to others, we count recent requests per client. The counter is keyed by a value derived from your IP address using a secret that is generated fresh each time the server starts and is never written down. The counters live in memory, expire within minutes, and cannot be linked back to an IP address without that secret, which ceases to exist when the process restarts. We do not store IP addresses. One counter lasts longer than minutes: a count of how many gates a client currently holds open, which necessarily lasts as long as those gates do and is keyed the same unlinkable way.

The suggestion box

The front page can carry a box for telling us what to build next. It is off unless the operator of this instance has configured a file for it to write to, and while it is off the page does not offer the box at all. Where it is on, one line is appended to that file for each suggestion, and that line holds two things:

• the text you typed, with control characters removed so that the file is safe to read;
• the hour it arrived, in UTC, with the minutes and the seconds zeroed.

Nothing else is written. Not your IP address, not the unlinkable abuse counter key derived from it, not your user agent, not the referrer, and nothing whatsoever from the signalling side: there is no code path between a suggestion and a gate. The hour is deliberately blunt for the same reason. A timestamp to the second would let whoever reads the file line a suggestion up with the gate its author had open.

This file is the only thing the Service keeps outside memory, and it is kept until the operator deletes it. Write a suggestion as if a person will read it, because one will, and please do not put anything in it that you would not want kept.

Network providers who can see metadata

We cannot make the network invisible, and we will not pretend otherwise.

• Cloudflare sits in front of the Service and terminates the HTTPS connection. It can observe your IP address, the time and size of requests, the room identifier, and the per-seat capability token that authorises your connection to a gate's signalling. The token decrypts nothing; it only authorises the seat. It cannot read message or file content, which is separately encrypted. Its handling of that data is governed by Cloudflare's own policies.
• A STUN server is contacted by your browser to discover your public network address, which is a necessary step in making a direct connection. We deliberately use Cloudflare's STUN server, because Cloudflare already sees your address from the connection above, so this adds no party that was not already involved.
• The other devices in your gate learn your network address, unavoidably, because the devices connect directly to each other. This is described on the first screen of the Service.
• Your own network operators, such as your ISP or employer, can see that you connected to this Service, as they can for any website.

What is stored in your browser

The Service sets no cookies. It uses browser storage only for:

• localStorage: a record that you accepted the Terms, with the version and date, so you are not asked on every visit; and, if you used the motion toggle on the front page, your animation preference, so it holds on your next visit.
• sessionStorage: your session token and the room secret for a gate that is currently open, and, for a password-protected gate, a key stretched from that password (never the password itself), so that reloading the page does not destroy the session; a counter that keeps old signalling messages from being replayed after a reload; while you are sending a file, a note of what is being sent (its name, size, type and a fingerprint of its first bytes) so that a reload can offer to continue rather than start over; and a marker for each notice you have dismissed, so it stays dismissed in that tab. All of it is scoped to that tab and discarded when the tab closes; the token, the secret and the stretched key are also removed the moment the gate ends. The secret is held here rather than in the address bar so that it is not readable by anyone who can see your screen. Note that some browsers write sessionStorage to disk for crash recovery, so treat this as a short-lived convenience rather than a vault.
• IndexedDB: only for a file transfer that is in progress, and only on the receiving device. It keeps a description of the transfer (the file's name, size, type and a fingerprint of its first bytes), a count of how many bytes have arrived, and, if you chose a save location, the handle your browser gave the page for that file, so that a dropped connection or a reloaded page can carry on from where it stopped instead of starting a large transfer again. The contents of the file are never written here. The bytes go straight into the file you chose, on your own disk. The entry is deleted when the transfer finishes, when the gate ends, and when you cancel; if you close the tab mid-transfer and never return to that gate, the entry lingers until you clear this site's data.
• A service worker, registered every time the gate page loads. It is a small script this site installs in your browser so that the site can be installed like an app and shared into from your device's share sheet, and so that a received file too large to hold in memory can be handed to your browser's own download manager and written straight to disk, instead of being held in the page. It never sees a key and never decrypts anything: the page decrypts and passes it finished bytes. Unlike the storage above it is not removed when the gate ends, because a service worker belongs to the site rather than to a session. You can remove it at any time by clearing site data for this site in your browser's settings.
• Cache Storage: only if you send a file into the Service through your device's share sheet. The service worker keeps the file's contents there, unencrypted, so they survive the hop from the share sheet to the gate page. This is the one place in browser storage that ever holds a file's contents. The entry is deleted the moment the gate page picks the file up, every gate load clears out anything left waiting, and the worker drops anything older than ten minutes.

All of these can be cleared at any time through your browser's settings. Messages, and received files that are being held in memory rather than saved to a location you chose, exist only in the page and are gone when it closes.

After a gate is burned, what was exchanged remains visible in that tab so that a dropped connection does not force you to start over. This is the same data that was already in the page; it is not written to storage and not transmitted anywhere, and it is discarded when the tab is closed or reloaded. A "Clear this now" button removes it immediately.

Retention

Session state: until the gate ends, and never on disk. Abuse counters: minutes, in memory. Suggestions, where the box is enabled: the text and the hour, on disk, until the operator deletes them. Everything else: not collected, therefore not retained. Apart from the suggestion file there is nothing to export, and a deletion request would find nothing to delete; a suggestion carries nothing that identifies who sent it, so we could not find yours in order to remove it even if you asked.

Legal requests

If we receive a valid legal demand, we can only produce what we hold, which for past sessions is nothing at all. Where the suggestion box is enabled, the file it appends to is the only record in existence, and it holds no identifier of any kind. We cannot decrypt, recover or reconstruct the contents of any session, because the keys exist only on the devices involved and are destroyed with the session.

Children

The Service is not directed at children and is not intended for use by anyone under the age at which they can form a binding contract in their jurisdiction.

Changes

Any change to this policy will be published on this page with an updated date.

Contact

Privacy questions, and requests about this policy, can be sent to warpgate@fysh.site. This address is monitored by the operator of the Service and is the correct route for every enquiry, including legal ones.

Back to Warp Gate · FAQ · Terms · Acceptable use · Privacy