hirecall
Log inBook a demo

Legal

Cookies

Last updated 2026-08-21

Draft — awaiting legal review

This document is being finalised before launch and has not yet been reviewed by a lawyer. Passages in double brackets are still to be completed. Do not rely on it.

This site does not use cookies

Not "only essential cookies". None.

Visiting [[SITE DOMAIN]] sets no cookies on your device. The site also writes nothing to local storage or session storage, and runs no script that reads information already stored on your device.

That stays true even though the site now measures its audience: the measurement is done without cookies, and it is described plainly below rather than hidden behind the word "essential".

It is, however, no longer true by default. The code for an anti-bot check on the /demo page is written and merged; it is dormant only because no key is configured for it. The section on it below is written for whoever turns it on.

So there is no cookie banner

Under French law — Article 82 of the loi Informatique et Libertés, which implements the ePrivacy Directive — consent is required before storing information on someone's device or reading information already stored there.

This site does neither. The analytics described below set no cookie, write nothing to your device, and read nothing stored on it: the only identifier involved is computed on Vercel's servers from the visit itself and discarded within 24 hours. So there is nothing to ask you to consent to, and no banner. A consent banner here would be theatre: it would ask you to make a choice that has no effect. We would rather tell you the truth once.

For review — the no-banner position now carries analysis, not just absence. Before 20 August 2026 this page needed no legal reasoning: the site did nothing Article 82 touches. It still does nothing Article 82 touches, but that is now a conclusion rather than a tautology: Article 82 bites on storing information on the terminal or reading information already stored there, and Vercel Web Analytics and Speed Insights do neither — no cookie, no local storage, and the daily-rotating visitor hash is derived server-side from the incoming request (IP address and headers, which every request carries anyway), with no cross-site reach. Note that the CNIL's audience-measurement exemption is beside the point: that regime exempts certain cookie-based tools from consent; these tools never engage Article 82 at all. The avocat should confirm this reading — the CNIL's doctrine on fingerprinting-adjacent techniques is the one angle from which it could be attacked — and the data-point list below is taken from Vercel's published documentation, which should be re-checked on upgrade.

What the site does do

Four things happen that are worth knowing about, none of which involves cookies.

The site is served to you. Our host receives your IP address, the page you asked for, the time, and your browser's user agent, and records them in server and security logs. This is how any website works; without it, nothing could be delivered to you. It is covered in the Privacy Policy.

The site counts its visitors — without cookies. We use two tools from our host, Vercel: Web Analytics and Speed Insights. Neither sets a cookie nor stores anything on your device. For each page view they record the page and the referrer, coarse location derived from your IP address (country, region, city — the address itself is not kept in the analytics data), your browser, device type and operating system, and — for Speed Insights — how fast the page loaded. Visits are counted with a short-lived identifier derived from your connection on Vercel's servers and discarded within 24 hours; it cannot follow you to any other site. The legal basis and your right to object are in the Privacy Policy.

Fonts are served from our own domain. The typefaces come from Google Fonts, but they are downloaded when the site is built and served from our own host. Your browser makes no request to Google when you visit, so Google receives nothing — not your IP address, not the fact of your visit.

Forms send what you type. If you book a demo, sign up to the newsletter, or ask for your three free interviews after trying the demo, what you enter is sent to us. That is the whole of it, and it is described in the Privacy Policy.

The demo sends you somewhere else, and sends nothing back. Trying the demo takes you to the product application at [[APP DOMAIN]]. Your audio is never recorded; a temporary transcript drives the conversation there and is destroyed when you return here, or automatically five minutes later if you do not. Nothing you said comes back to this site. The brief shown afterwards is a worked example written in advance — the same one for everyone who tries that role.

What we do not do

  • No cookie-based analytics and no third-party analytics — no Google Analytics, no Plausible, no Fathom, no PostHog. The only measurement is the cookieless Vercel tooling described above, served first-party.
  • No advertising cookies, no retargeting, no conversion pixels, no Meta pixel, no LinkedIn Insight Tag.
  • No social media embeds, no third-party video players, no chat widget, no embedded maps — none of the things that quietly set third-party cookies.
  • No cross-site tracking, and no fingerprinting that could follow you anywhere: the analytics identifier lives at most a day and means nothing outside this site.
  • No session recording or heatmapping.
  • No A/B testing tool.

If you take the interview

The demo takes you to a different application, at [[APP DOMAIN]]. That application is not covered by this page, and what it stores is explained there. The demo itself needs no account, but the application will still set at least what it needs to run the session.

To confirm. The product application almost certainly sets session and authentication cookies, and if authentication is provided by a third party it will set that provider's cookies too. Someone must produce the equivalent of this page for the product application. It is a separate document and it is not in this set.

⚠️ Before the anti-bot check is switched on

The /demo page can put a Cloudflare Turnstile challenge in front of the demo, to stop the free interview minutes being consumed by bots. It is not running today: no site key is configured, the Turnstile script is never loaded, and no visitor's browser has contacted Cloudflare. The whole of this page is verifiable on that basis right now.

Setting one environment variable changes that. Three things become true the moment it is set, and only the first is about cookies:

  1. Your browser contacts Cloudflare. Loading the challenge is a request to challenges.cloudflare.com, which necessarily discloses your IP address and user agent to Cloudflare. This is true whether or not anything is stored on your device, and it is the reason Cloudflare is now listed as a provider in the Privacy Policy. It happens on the /demo page only.
  2. Something may be stored on your device. Turnstile can set a cookie in some of its modes. Whoever ships the key must observe this rather than assume it — open the /demo page with the developer tools on a clean profile, and write down every cookie and storage entry, its name, purpose and lifetime. Then write this page from what was observed.
  3. The no-banner position has to be re-argued, not patched. If Turnstile stores nothing, Article 82 is not engaged and the reasoning above stands unchanged. If it stores something, the question becomes whether that storage is strictly necessary for a service the visitor expressly requested — the exemption in Article 82 itself. There is a real argument that an anti-bot check guarding a free service the visitor just asked for qualifies, and the CNIL treats fraud prevention as capable of exemption. But that argument is narrow, it is contested, and it is for the avocat to make or reject. Do not assume it.

For review. The honest reading today is that this is a security measure on one page, not tracking: Turnstile is not an analytics product and does not follow visitors between sites. That said, the exemption is narrower than it is comfortable to assume, and the finding in point 2 decides the whole question. Two related notes for whoever ships it: the /demo page opens a connection to Cloudflare in advance to make the challenge appear faster, and that pre-connection is itself a disclosure of the visitor's IP — it is deliberately wired to appear only when a key is configured, and it must stay that way. And unlike the Google tags below, this check cannot simply be refused: a visitor who declines it cannot take the demo. That asymmetry is exactly why it has to rest on the strictly-necessary exemption rather than on consent.

⚠️ Before any Google tag ships — the checklist this page becomes

Google Analytics and advertising tags are planned for when paid campaigns start. They are not on the site today. The day the first one is merged, this page stops being accurate at that moment — so this section is written for whoever edits it on that day, not as a hypothetical. All five of the following must be true before the first tag loads, not after:

  1. Prior blocking. Nothing loads, executes or transmits before the visitor makes an affirmative choice. A tag that fires once before the banner is answered is a violation, not a bug — test with the network panel open, on a first visit, before shipping.
  2. Refusing as easy as accepting. A "Refuse all" control with the same prominence as "Accept all", on the first layer of the banner. No pre-ticked boxes. This is not a style preference: the CNIL fined Google €150 million and Facebook €60 million (decisions of 31 December 2021) precisely for making refusal harder than acceptance.
  3. Proof and withdrawal. Keep proof of each consent — what was shown, what was chosen, when — and provide a withdrawal route as simple as the banner: a persistent "Cookies" link in the footer that reopens the choice. A refusal is remembered (the CNIL recommends at least six months) and not re-asked at every page load.
  4. Consent Mode v2. Google tags run in Consent Mode v2, wired to the consent platform, so Google receives consent signals — and no data — until consent exists. "The tag is installed but dormant" must be verifiably true.
  5. The transfer analysis, re-run on the day. Google Analytics sends data to the United States. The EU–US Data Privacy Framework currently supports that, but the Latombe appeal (C-703/25 P) is pending before the Court of Justice. Check the state of play on the day the tag ships; then rewrite this page and the Privacy Policy to name each cookie, its purpose, its lifetime, and the transfer mechanism.

The near-misses to learn from. Analytics were added to this site on 20 August 2026, and this page said "no analytics of any kind" until it was revised the same day. The demo funnel then merged Turnstile-calling code on 21 August 2026 while this page still said the site contacted no third party at all — dormant, so the page stayed true, but true by one unset variable. That is exactly the failure mode this page predicted when first drafted. The suggested control stands, with sharper teeth: a deployment-pipeline check that fails the build if a Google or ad-tech package appears in the dependency list while this page has no live consent-banner section. This page is verifiable by anyone with a browser's developer tools open — which makes it a strong trust signal while true, and a plainly false statement by a company selling itself on data discipline the day it goes stale.

Questions

privacy@hirecall.ai

Last updated: [[PUBLICATION DATE]]