PRIVACY POLICY

Handle, email address, the IP address of your signup and of each sign-in, and the files you upload with their names, sizes and hashes. If you ask to be paid we also hold what a payment rail needs to pay a person: full legal name, address, city, postal code, country, payout country and, where you give one, a tax identifier. That set exists to make a payout and to satisfy the rail that the person being paid is the person named. It is used for nothing else, and none of it is required to hold an account or to host files.

A payout destination is an account number or a UPI handle, so it is sealed with AES-GCM under a key derived from a server-side secret, and only its masked form is shown back to you or to an administrator settling a withdrawal. The boundary is worth stating: the destination is sealed, while the name on the account, your address and your tax identifier are ordinary database columns, protected by access control rather than by encryption we perform.

For every completed download: the full IP address, a salted hash of it, a salted hash of the user agent, the country, the referring host, and the byte counts of the transfer. This exists to count downloads and to stop fraud. The address is stored whole rather than truncated, and no job discards it.

Stated plainly, because it is the most invasive thing we hold. Every completed download writes an earning event carrying the visitor's full, untruncated IP address. It is retained for exactly one declared purpose: investigating download fraud and abuse on a payout that is under review. It is not used to profile a visitor, to target advertising, or for anything surfaced outside the administrative review screen where a held payout is examined, and it must not be. Grouping, deduplication and every ordinary query run against the hash instead, so normal operation never reads the raw value. Nothing expires it on a timer; it is removed by hand.

A download ticket carries a salted hash of your address and a salted hash of your user agent, and the download is refused if either fails to match when the ticket is presented. IPv6 addresses are reduced to their /64 prefix before hashing, so an ordinary address rotation does not kill a download in progress; IPv4 addresses are hashed whole. Only those hashes travel in the ticket — it is sealed and carries no readable identifier — and they exist to stop one link being shared, not to recognise you between visits.

Our own cookies are first-party and functional. One keeps you signed in: its value is an opaque identifier, and the session record it points at — the account it belongs to, when it was issued, and its CSRF token — lives in Cloudflare KV and expires thirty days after it is written. One records that you answered a download password, so a protected link does not ask twice within the hour. One more is set only if you arrive on an invite link, to remember which publisher invited you long enough for a signup to credit them; it lasts an hour, is dropped the moment you sign up, and is not read anywhere else. We set no advertising or analytics cookies of our own. Download pages reserve space for ad units and, where a network is configured, fill them from Google Ad Manager, which may set cookies and identifiers of its own that we do not control. There is no consent banner: nothing here asks you for a choice or records one. If your browser or a consent tool you installed offers a signal, the page waits briefly for it, and then requests ads either way. Whether ads load or not, the wait before a download is the same.

The step that mints the final download token carries a Cloudflare Turnstile challenge. Solving it sends the challenge token, your address and your user agent to Cloudflare for verification, under Cloudflare's terms rather than ours; what we keep is the verdict, carried as a flag on the token the last hop tests. The widget is configured to stay invisible unless it needs interaction, so most visitors are never asked anything. Where the challenge is not configured for a lane it is skipped end to end and nothing is sent.

Alongside the download records we write sampled analytics points to Cloudflare Analytics Engine: the event, the publisher, the host, the outcome, the country, the network's autonomous system number, a coarse profile of the user agent — browser family, platform, device class — the referring host, byte counts, funnel timings, screen width, connection round-trip time and the visitor's local hour. No IP address, no cookie value and no account identifier goes into that dataset, and the platform discards the points after three months. Common events are thinned by sampling and rare ones are kept whole, so what the dataset holds is a shape rather than a record of individuals.

Cloudflare processes nearly all of it on our behalf: the site runs on Workers, files sit in R2, records in D1, sessions and caches in KV, analytics in Analytics Engine, challenges through Turnstile. Beyond that, payment processors, to make a payout you asked for, and law enforcement where a valid order compels it. We do not sell data. We do not build advertising profiles from uploader accounts, and we do not build them from the visitor addresses described in clause 04.

The periods we can state honestly. Sessions in KV expire thirty days after they are written. Analytics points are discarded by the platform after three months. Files are deleted on the reaper's schedule set out in the terms, and a file delisted by a takedown has its bytes held 30 days and then destroyed. Everything else — your account, your identity details, sign-in records, download and earning events including the addresses in clause 04, takedown and strike records, and the audit trail — has no expiry job at all, so assume it is kept until you ask us to remove it or a legal retention ends. Records that a takedown, a strike or a payout happened are not erased on request while they are the evidence for a decision that still stands.

You can request a copy of your data, correct it, or have it erased where no legal retention applies. There is no self-serve export or deletion: write to privacy@stashbay.net from the address on the account and it is done by hand, at no charge. Someone with no account can ask the same about the download records in clauses 03 and 04, but has to give us something to find them by — the link and roughly when — because those records are not indexed by any name we hold. Automated mail from Stashbay is sent from post@stashbay.net and is not read; a request sent there reaches nobody.

Files and account records sit in Cloudflare R2 and D1 with no location or jurisdiction pinned, so the region is Cloudflare's default rather than a country we can name. Nothing is cached at the edge: download responses are marked no-store and every request re-reads the record.