Draft template — not reviewed by a lawyer

This document was drafted from what the software actually does. It has not been reviewed by a qualified lawyer, it is not legal advice, and it is not fit to govern a live financial service. It must be reviewed and completed by counsel qualified in the relevant jurisdiction before Crypto Gate accepts real customer funds.

Passages in [SQUARE BRACKETS] are unfilled placeholders. Nothing in them has been invented — a plausible but wrong company name, address, governing law or retention period would be far more dangerous than a visible blank.

Cookie policy

Last updated

Crypto Gate sets three cookies. All three are functional — none of them track you across other websites, and none are used for advertising.

1. The short version

We set three cookies, and every one of them exists to make the product work rather than to watch you:

a session cookie, so you stay signed in between pages;
a CSRF token, so a third-party site cannot make your browser submit a form to us as you;
a device-identifier cookie (cg_device), so we can tell this browser apart from an unfamiliar one and stop emailing you a sign-in code every single time.

There are no advertising cookies, no analytics cookies and no cross-site trackers on this product. We do not sell or share your browsing behavior with anyone.

2. What a cookie is

A cookie is a small piece of text a website asks your browser to store and send back on later requests. Because HTTP itself has no memory, cookies are how a site knows that the request loading your dashboard belongs to the same person who signed in a minute ago.

The mobile app does not use cookies. It holds the equivalent values in the operating system's secure storage and sends them as request headers instead.

3. The cookies we set

Session cookie — `crypto_gate_session`

Purpose: keeps you signed in as you move between pages. It contains an encrypted identifier for your session on our server, not your name, email or any account data.
Type: strictly necessary. The dashboard cannot function without it.
Lifetime: expires after a period of inactivity, and when you sign out.
Flags: HttpOnly — JavaScript cannot read it — and Secure over HTTPS.

CSRF token — `XSRF-TOKEN`

Purpose: proves that a form submission or state-changing request came from our own pages. Without it, another site could quietly cause your logged-in browser to submit a request to us — a cross-site request forgery.
Type: strictly necessary; it is a security control.
Lifetime: the same as the session.
Flags: readable by our own JavaScript by design, so it can be echoed back in a request header, and Secure over HTTPS.

Device identifier — `cg_device`

Purpose: lets us recognise this browser as one you have signed in from before, and skip the emailed one-time code.
Type: functional, and security-relevant. See the next section.
Lifetime: 90 days.
Contents: a random value with no meaning outside our system. It does not encode your name, your email or anything about you.

4. The device cookie, in detail

This one is worth explaining properly, because its behavior is not obvious from its name and because deleting it has a visible consequence.

What it does

When you sign in from a browser we have never seen, entering the correct password is not enough on its own: we email you a one-time code and wait for it before any session is created. That is a real defence against someone who has obtained your password.

Being asked for that code on every single sign-in from your own laptop would be exhausting, so once you have proved yourself we remember the browser. The cg_device cookie is how we recognise it next time.

How it works

The value is random — 32 hexadecimal characters generated by us. It is not derived from anything about you or your machine, and it is not a fingerprint.
We store only a SHA-256 hash of it against your account, never the value itself. Anyone who stole our trusted-device table would find hashes, not working device identifiers — which matters, because holding the raw value is what lets a browser skip the emailed code.
Alongside the hash we keep a label such as “Chrome on macOS”, the last IP address, the last approximate location and when it was last used, so your device list is legible to you.
The cookie and the stored record both expire after 90 days. A device you stopped using stops being recognised.

What it is not

It does not sign you in. The cookie is only ever a hint about which device is asking. Your password still has to be correct first, and every action that moves funds still requires a second factor regardless of how well we know the device.

It does not follow you. The value is only sent to us, it means nothing to any other site, and we do not share it or use it to build a profile of your browsing.

If you delete it

Nothing breaks. Your next sign-in from that browser is simply treated as a sign-in from an unfamiliar device, so you will be emailed a one-time code. Enter it and, if you choose to trust the browser again, a fresh cookie is set.

You can also remove a device from the device list in your account, which revokes the stored hash server-side. Do that on any device you no longer control — it is the more complete of the two options, because clearing the cookie on a laptop you have lost is not something you can do from here.

5. What we do not set

To be explicit about the absences, since they are the ones people care about:

no advertising or retargeting cookies;
no third-party analytics cookies;
no social media pixels or share-button trackers;
no cross-site tracking of any kind;
no fingerprinting to identify you without a cookie.

6. Third-party cookies

Live chat. Where the support chat widget (Supoora) is enabled, it loads a script from the provider and may set its own cookies or local storage to keep track of your conversation. Those are set by the provider under its own policy, not by us. If the widget is switched off, no such script loads at all.

No other third-party script runs on the marketing site, the dashboard or the hosted payment pages.

The web fonts used on these pages are loaded from a font host. That involves a request to that host, but no cookie.

7. Controlling cookies

Every major browser lets you see, delete and block cookies, usually under privacy or site-data settings. You can clear cookies for this site alone without touching any other.

Be aware of the trade-offs:

Blocking the session cookie makes it impossible to sign in at all. There is no way around this — it is what keeps you logged in.
Blocking the CSRF cookie makes forms fail, because we cannot verify the request came from us.
Blocking or clearing the device cookie is entirely workable. You will be emailed a one-time code at every sign-in from that browser. Some people prefer exactly that, and it is a reasonable choice.

Private or incognito windows discard cookies when the window closes, so a sign-in from one will ask for an emailed code every time.

9. Changes

If we add or remove a cookie, we will update this page and change the “last updated” date at the top. If we ever introduced a cookie that was not strictly necessary, we would say so here plainly and ask before setting it.

10. Contact

Questions about cookies, or about anything in the privacy policy: [email protected].

Crypto Gate

Before this document goes live

Have counsel qualified in the relevant jurisdiction review the whole of it, fill every bracketed placeholder, and confirm what licensing or registration holding customer funds requires where Crypto Gate operates and where its customers are. Until that is done this page is a draft, not a contract.

Questions about this document: [email protected]. Everything else: [email protected].