Privacy policy

The data controller is Mahé Chadeffaud, a sole proprietor trading as Stochastly, 7 rue Marie-Thérèse Hermann, 74000 Annecy, France, SIREN 109 270 363, reachable at contact@stochastly.com. The scope is stochastly.com, the Stochastly desktop application, and the licences issued through them.

No data protection officer is appointed; our processing does not require one (Art. 37 GDPR). Write to contact@stochastly.com for any data-protection request.

This policy applies wherever you live. Because we are established in France, the GDPR governs our processing for every user, inside the European Union and outside it, and you have the rights below whatever your country.

Each row below names one processing operation, the data it uses, its purpose and its legal basis under Art. 6(1) GDPR.

• Legacy waitlist emails. Previously submitted email addresses, submission times and source labels were collected with consent under Art. 6(1)(a). Contact us to request removal.
• Purchase. Payment is taken by Stripe, which sends us the buyer email and the checkout or subscription identifier. We do not receive or store your card number. Legal basis: performance of the contract, Art. 6(1)(b). If purchase review invitations are enabled, we send a purchase confirmation via Resend and copy the buyer email address to Trustpilot so it can send one neutral review invitation after the configured delay. Your licence is never sent to Trustpilot. This optional satisfaction follow-up is based on our legitimate interest in improving our service, Art. 6(1)(f); you may object at contact@stochastly.com and unsubscribe from the invitation email.
• Country checks. Cloudflare supplies an IP country code. We use it to check purchase and trial availability, and we read the billing country in Stripe payment events. Excluded purchases are logged with their country, reason and payment reference; missing country evidence is also logged for review. Purpose: to enforce our availability policy and investigate failures, under our legitimate interests, Art. 6(1)(f). Server logs rotate by size, up to 50 MB per container; they have no fixed retention period in days. Stripe retains billing details under its own policy. These checks do not establish residence or reliably identify occupied territories or listed persons.
• Licence record. For each licence we hold the email, the edition, the licence identifier, its expiry, the Stripe reference, and any revocation and its reason. Purpose: to issue, support and revoke the licence. Legal basis: Art. 6(1)(b).
• Account. When you sign in with GitHub, Google or an emailed link, we store your email address, whether it is verified, the sign-in provider and its account identifier, and the times of creation and last sign-in. Licences bought with a verified email that matches, or bought while signed in, are attached to the account. When the desktop app is connected to your account, we store a one-time connection code, a hash of the app secret, the machine fingerprint, and the approval time; the code expires after ten minutes, and an hourly job deletes it once it has been expired for a day. For each computer linked to a licence, up to two, we store the machine fingerprint, a hash of the secret the app received when it was linked, an optional label, and the times it was linked and last seen. Each release of a computer is recorded with its date, to apply the limit of three releases per 30 days. Purpose: to let you find your licences, release a computer, and connect the app by signing in. Legal basis: performance of the contract, Art. 6(1)(b).
• Early access. When you join the early access, we store your account identifier, the date, your answers to the five questions (each one can be skipped), and the time your 100 assistant credits, offered once, were granted. The app asks for those credits. To give them once per computer, we keep a SHA-256 hash of the machine fingerprint, which stays after the account is deleted, so that deleting and joining again does not give the credits twice; to give them once per network per day, we keep for the current day a keyed digest of your network block (the first three parts of an IPv4 address, the first four groups of an IPv6 address), never the address itself, deleted the next day. Legal basis: our legitimate interest in preventing abuse of free credits, Art. 6(1)(f). Purpose: to give you the free licence for one computer, to send you a receipt and the feedback requests, and to understand who uses Stochastly so we can decide what to build. Only the Stochastly team sees the answers: a daily summary goes to our team mailbox, and they are listed in our administration console. Legal basis: performance of the contract, Art. 6(1)(b), for the licence, the receipt and the feedback requests; our legitimate interest in improving the product, Art. 6(1)(f), for the answers, which you may object to at contact@stochastly.com. The five questions are optional; skipping them changes nothing. To keep the free licences from being claimed in bulk, each request is counted for the current day by the domain of your email address and by a keyed digest of your network block (the first three parts of an IPv4 address, the first four groups of an IPv6 address), never the address itself; these counters are deleted the next day. A request above the daily thresholds waits, with its answers, for a manual review by the Stochastly team before the licence is issued. Legal basis: our legitimate interest in preventing abuse of a free offer, Art. 6(1)(f). The feedback you write is kept while your account exists and used to improve the product, Art. 6(1)(b).
• Free trial. When the app starts a free trial, we store your account identifier, a SHA-256 hash of your email address, a SHA-256 hash of the machine fingerprint, the identifier of the trial licence, its start and end times, and the time the trial credits were granted. Purpose: to offer one trial per person and per computer. Legal basis: performance of the contract, Art. 6(1)(b), and our legitimate interest in preventing repeated trials, Art. 6(1)(f).
• Licence check. A signed-in installation contacts our licence endpoint about every 1 hour on its own while it is open, and at each sign-in. It sends the licence token, the machine fingerprint and the secret the app received when it was linked; we update the time the computer was last seen, and when the check is refused we store the fingerprint, the licence identifier, the reason and the day (see Account and licence activity). Purpose: to check that the computer is one of those linked to the plan, to enforce revocation, and to issue the signed authorisation that keeps the app working offline. Legal basis: our legitimate interest in preventing licence sharing, Art. 6(1)(f).
• The machine fingerprint. It is a truncated SHA-256 hash of your operating system name and processor architecture, combined on Windows with your computer name and network adapter address, and on macOS with the platform identifier the system assigns at installation. The hash does not let us read those values back. It does identify your installation over time, which makes it pseudonymised personal data under Art. 4(5) GDPR, and this policy covers it as such.
• Assistant allowance. When the assistant is used, we increment a monthly counter holding the licence identifier, the calendar month, the input and output token totals, the number of calls and the credits charged, and a daily counter (licence, day, tokens, calls) that enforces the daily limit, deleted after 35 days. The Assistant + Agents option is recorded on your licence record: whether the option is active, the credit balances (the credits included for the current month, the credits you bought, and the amount reserved while a call is running), the identifier of the subscription that carries the option, and the date of the last change. Each credit top-up is recorded with the payment session identifier, the licence identifier, the number of credits and the date, so that a payment can never be credited twice. We also record the payment state Stripe reports for each subscription (paid, failed, refunded, disputed, paused or cancelled), to suspend, revoke or restore the licence it pays for, together with the identifiers of the Stripe events and invoices already processed, so that none is applied twice. The credits offered with a free trial opened before access became private are recorded on the trial licence in the same way. Purpose: to apply the allowance sold with the option and show you what remains. Legal basis: Art. 6(1)(b); for the daily counter, our legitimate interest in stopping a copied licence from using a month of allowance in one day (Art. 6(1)(f)).
• Account and licence activity. We count, without looking at any one person, how many accounts signed in on each day, week and month, from the sign-in times and the assistant counters described above. Only totals of ten or more are shown, and only to the Stochastly team; a smaller total is hidden, and no activity is shown for any single account. Legal basis: our legitimate interest in knowing how many people use the service, Art. 6(1)(f), after checking that this use is compatible with the reason the data was collected (Art. 6(4)). You can object by writing to contact@stochastly.com; your account is then left out of these totals. Two more records serve narrower purposes. Refused licence checks: when a check is refused (licence revoked or ended, or a computer that is not linked), we keep one line per licence, reason and day, with the machine fingerprint and the number of attempts, to detect fraud and licence sharing; a check that succeeds is not logged; legal basis Art. 6(1)(f); kept 12 months, then deleted by a daily job. Download counters: each installer our server sends adds one to a daily total per system (Windows or Mac), source (account page or in-app update) and app version, with no account, IP address or browser stored, to know how many installers go out; legal basis Art. 6(1)(f); kept 25 months, then deleted by a daily job.
• Enterprise enquiries. If you request a quote, we receive your company name, work email, team size and description of use. The site sends these details through Resend to our contact mailbox so we can reply. This is a step you request before a possible contract (Art. 6(1)(b)). You can ask us to delete the correspondence at contact@stochastly.com.
• Newsletter. If you subscribe, we store your email address, subscription status, the version of the consent text, the time you agreed, the time you confirmed and where you signed up. Purpose: to send release notes and research paper summaries. Legal basis: your consent (Art. 6(1)(a)); you can withdraw it in one click from any email, without affecting earlier sends. We also count subscribers, new sign-ups and unsubscribes per day and per week, including from the records kept after you unsubscribe, to see how the newsletter grows. Only totals of ten or more are shown, only to the Stochastly team, and never for any one person. Legal basis: our legitimate interest in measuring growth, Art. 6(1)(f), after checking that this use is compatible with the reason the data was collected (Art. 6(4)). You can object at contact@stochastly.com; your address is then left out of these totals. Recipients: Supabase (database, EU region) and Resend, Inc. (sending), our processors. Resend processes data in the United States under the Standard Contractual Clauses of its data processing agreement. We use no open or click tracking. Retention: unconfirmed sign-ups are deleted when the confirmation link expires (7 days); a subscription ends when you unsubscribe; after that we keep only a keyed hash of your address, the dates and the consent version for 3 years so we never email you by mistake, then delete them.
• Creator program. If you join it, we store your account identifier and email address, your creator code, the identifier of its Stripe promotion code, the identifier of your Stripe Connect account once you open one, your status in the program, and each commission and payout: amount, invoice identifier, date and Stripe transfer identifier. Stripe collects the identity and bank details needed to pay you, as its own controller; we do not receive them. When a customer pays with a creator code, we record their email address, plan, billing period, whether the referral is eligible or refused and the reason, and the share of each invoice kept after a refund or dispute. The creator sees counts and amounts, never who bought. While the program is open, each paid subscription invoice also stores the card fingerprint Stripe supplies, a token that recognises the same card without revealing its number, with the subscription reference, so that a card already used on another subscription earns no commission. Purpose: to pay creators as the creator terms state and to prevent self-referral. Legal basis: performance of the contract with the creator, Art. 6(1)(b), and our legitimate interest in preventing commission fraud, Art. 6(1)(f).
• Request throttling. The licence validation route, the sign-in routes (provider sign-in, emailed link, callback, session refresh), the app connection routes (start, check, approval), the app account and trial-credit routes, the computer release form, the creator program sign-up and payout-account forms, the assistant relay, the browser security-report endpoint and the legacy waitlist endpoint count recent requests per IP address to stop floods; the emailed-link form also counts requests per email address, the approval form per account, and the assistant relay and the app account and trial-credit routes per licence. The health check, the payment webhook, the monthly creator payout job and the retired activation route do not count IP addresses. That counter lives in memory, resets when the process restarts, and is written to no database. Legal basis: our legitimate interest in keeping the service available, Art. 6(1)(f).
• Server logs. Our host and our network provider record standard access logs, which include the IP address, the timestamp and the requested path. Purpose: security and abuse investigation. Legal basis: Art. 6(1)(f).
• Audience measurement. To count visits and see which pages are read, the pages of stochastly.com load Umami, an open-source counter that we run on our own server at stats.stochastly.com. No other company receives this data, apart from our host and our network provider, who carry it like any other request. For each page viewed it records the page address, the address of the page you came from, the page title, the browser, operating system, device type, screen size and language, and the country, region and city of the connection. Addresses are recorded without their query string, utm_ campaign tags included, and without any #fragment; a referring page on another site is reduced to its domain. Our server shortens the IP address before the counter receives it (the last of the four numbers of an IPv4 address is set to 0, an IPv6 address keeps its first three groups). The country, region and city are the ones our network provider attaches to the request or, failing that, are looked up from the shortened address. No IP address is stored: the shortened one is combined with the browser's user agent and a secret that changes every month into a visitor identifier, so a visitor cannot be followed from one month to the next. The sign-in pages and our own administration pages are not measured. You can object at any time: Stop measuring my visits. This stores one value, umami.disabled, in your browser so the choice is kept; Do Not Track and Global Privacy Control are also honoured. Purpose: visit statistics for this site, never used for advertising or combined with other data. Legal basis: our legitimate interest, Art. 6(1)(f). It is set up to meet the conditions under which the French data protection authority (CNIL) exempts audience measurement from consent: no cookie, statistics for this site only, data kept 25 months at most. When an account has just been created, the page that follows sends one event named signup. The join path (the /join page, the five questions and the download buttons) sends one event per step reached, such as a question shown or skipped, the answers sent, or Download for Windows or Mac clicked. These events are names only: they carry no account identifier, email, name, answer or campaign, and only count steps. The app window of the home page sends one event per CSV check whose name gives how the check ended (checked, file not read, file too large, too many checks, server error), the page and a range of rows, such as csv_check_ok_landing_r30_249; it never names the file or anything in it.

The site sets cookies of its own only when you sign in: two session cookies that keep you signed in (one expires within a day, the other after thirty days or when you sign out), and, for ten minutes during sign-in, two cookies that carry the sign-in verifier and the page to return to. These are strictly necessary for the account you asked for, readable by our server only (HttpOnly), and never used for tracking. One more cookie, stx_in, holds the value 1 and no identifier, and expires after thirty days or when you sign out: the page header reads it in your browser to show Account instead of Log in, and our server never reads it. The site keeps at most two values in your browser's local storage. stx-polices is set to 1 once the site fonts are in your browser cache so the next page can show them at once. umami.disabled is set to 1 only if you object to audience measurement, so the choice is kept. Neither holds an identifier, our server never reads them, and sign-in adds nothing to them. The audience measurement itself sets no cookie and writes nothing else to your browser's storage. In the desktop application, bx.settings keeps your display preferences (theme, colours, text size) on your device, with your other application settings (the display name you choose, the assistant options and the data folders you add); our server never reads it. The site sets no advertising cookie and no third-party tracking cookie. That statement covers the pages served from stochastly.com; our network provider sets its own operational cookies.