Cookies & Tracking
In short: We set no cookies, load no analytics script, load no third-party scripts and self-host our fonts. Nothing runs in your browser to count you. We do count page requests on our own edge servers — path, day and country, in aggregate, with no identifier of any kind (section 4). There is no consent banner because nothing is stored on your device. Two further exceptions, both named rather than buried: an infrastructure cookie our CDN can set for bot protection (section 4), and a tracking pixel our mail relay injects into the one notification email, which we cannot switch off (section 7).
1. The claim
readyaudit.dev is a static website. It sets no cookies of its own, uses no local storage, session storage, IndexedDB, browser fingerprinting, tracking pixels or web beacons, and it loads no analytics script of any kind — not Google Analytics, not a privacy-friendly alternative, not a self-hosted one. Nothing runs in your browser to count you: no script, no cookie, no identifier. That is the whole browser-side claim, it is the part you can check for yourself, and section 5 tells you how in fifteen seconds.
That paragraph is about this website and the app, and that is its whole scope. One thing does fall outside it: the single notification email, whose body our mail relay rewrites to add its own unsubscribe link and a tracking pixel we cannot switch off. Section 7 sets that out in full, including how to stop it.
What we do instead is count on our side of the wire. Our edge servers record one aggregate row per page request — which path, which day, which country — and nothing else. No IP address, no user agent, no referrer, no query string, and no visitor or session identifier of any kind, hashed or otherwise. Come back tomorrow and you become another row, with nothing in either row to say the two came from the same reader. Section 4 sets out how it works and what it cannot do.
This is deliberately less than analytics, and the gap is a real cost. A path count is not a funnel: we cannot see that the same person read the pricing page and then the methodology page, because we do not know it was the same person and have built it so that we cannot find out. That means running the business on judgement rather than dashboards, and we accept it, because a site whose entire argument is "evidence, not opinions" cannot credibly ask you to trust a tracking script.
2. Why there is no consent banner
The ePrivacy Directive requires consent before storing or accessing information on your device, except where it is strictly necessary to provide the service you asked for. We store nothing of our own, and the one thing that may be stored — the CDN's bot-protection cookie in section 4 — falls inside that exception, so no consent is required and there is no banner. The counting in section 4.1 does not change that: it neither stores anything on your device nor reads anything from it, so the Directive's consent rule is not engaged by it at all. A banner asking permission for cookies that do not exist would be worse than useless — it would train you to click "accept" without reading.
3. Third-party requests
Loading a page on readyaudit.dev makes no request to any third-party domain. Specifically:
- Fonts are self-hosted. Inter and JetBrains Mono are bundled into the site through
@fontsourceand served from readyaudit.dev. Your browser never contacts Google Fonts, which would otherwise expose your IP address to a third party on every page view. - No CDN-hosted libraries. No jQuery from a CDN, no icon font, no framework loaded from someone else's server.
- No embeds. No YouTube or Vimeo players, no social share buttons, no comment system, no chat widget, no newsletter popup, no tag manager, no A/B testing script.
- Almost no JavaScript at all. The site is statically generated and ships only the small amount of script its own interactive elements need.
4. What happens on our side of the wire
Two things happen on a server rather than in your browser: we count page requests, and the CDN we sit behind may set a security cookie. Neither is visible in your DevTools, so neither can be verified the way section 5 verifies the rest. That is exactly why they are written out here.
4.1 What we count
Every request for a page of this site is recorded once, at our edge, as a
row with three fields: the path (/pricing),
the day, and the country the request
arrived from as our CDN resolved it. Requests for stylesheets, fonts,
images, the sitemap and robots.txt are not counted at all.
The list of what is not in that row is the point of it: no IP address, no user agent, no referrer, no query string, no cookie set or read, and no visitor, session or device identifier — including hashed, fingerprinted or derived ones. Nothing in a row can be linked to another row, so we cannot tell a single reader from a crowd, cannot follow anyone between pages, and cannot see a return visit. This is not a limitation we intend to lift later; it is what makes the count an aggregate rather than analytics.
The code that does it is published with the site
(web/worker/index.js) and a test refuses to pass if it ever
writes a field this page does not name. Rows are kept by Cloudflare for
three months, which is their fixed period rather than a setting of ours, and
they are readable only by us.
4.2 The CDN's security cookie
The site is served through Cloudflare. Cloudflare's bot-management and
DDoS-protection layers can set a cookie named __cf_bm, and in
some configurations cf_clearance, to distinguish a browser
from an automated client. We do not enable this for tracking, we cannot
read those cookies for any purpose of our own, and they carry no identifier
we could tie to a person. They are strictly necessary security cookies.
__cf_bm expires 30 minutes after the last request. The
lifetime of cf_clearance is set by the zone's challenge
passage configuration rather than by the cookie itself; ours is left at
Cloudflare's default rather than extended, and you can read the value your
own browser was given with the DevTools check in section 5.
We mention it because "we set no cookies" and "your browser will never receive a cookie on this domain" are different statements, and only the first one is ours to make. Infrastructure you sit behind is still infrastructure.
Cloudflare also processes request metadata — IP address, path, user agent — as described on the sub-processors page. That is server-side logging, not a cookie, and it is what any web server does in order to serve a page. We do not enable log export and keep no copy of those logs on our side. Two aggregates are visible to us and no more: Cloudflare's own per-path counts, reaching back a rolling 30 days, and the three-field rows described in section 4.1, kept for three months. Neither contains a row for an individual visit. Cloudflare retains the underlying request records under its own schedule, published in its documentation, which we do not set.
5. Verify it yourself
Do not take our word for the browser-side claim. It takes fifteen seconds:
- Open developer tools in your browser (⌥⌘I on macOS Safari or Chrome, F12 elsewhere).
- Go to the Network tab and reload this page. Every request should go to
readyaudit.dev. If you see a request to any other domain, we have a bug or a broken promise — either way, tell us. - Go to Application → Cookies (Safari: Storage). You should see nothing, or at most the Cloudflare entry from section 4.
- Check Local Storage and Session Storage for
readyaudit.dev. Both should be empty.
What that check cannot show you is section 4.1, and no browser check ever
could: counting on a server leaves nothing behind in your browser to find.
A promise you cannot verify is worth less than one you can, so the only
thing we can offer in its place is the code — web/worker/index.js
ships with the site, and the fields it writes are the three named above.
Found something that contradicts this page? Write to info@readyaudit.dev. We will fix the site or fix the page, and say which.
6. The macOS app
The Application contains no web view used for tracking, no advertising SDK,
no attribution SDK, no analytics SDK and no crash reporter that transmits
off-device. Its PrivacyInfo.xcprivacy manifest declares
no tracking domains at all and marks every collected data
type as not used for tracking. Its only required-reason API declaration is
UserDefaults, under reason CA92.1 — storing this
app's own settings on your Mac.
Local settings the app writes to your own machine — window size, your last choices in a form, your Device Token in the Keychain — stay on your machine. They are not cookies and are not transmitted anywhere.
7. The one notification email
There is exactly one message we ever send you unprompted: the notice that your report is ready, to an address you type into the audit form and which we erase as soon as we hand the message over. That message is not covered by section 1, and here is the honest reason why.
We do not run our own mail server. The relay we use — named on the sub-processor page — rewrites what we hand it: it converts the message to HTML, adds its own one-click unsubscribe link, and embeds a 1×1 tracking pixel on a domain it controls. So opening that email tells the relay that this address opened it, along with the IP address and mail client that fetched the image. There is no setting on our plan that switches either off, and we are not going to describe a pixel we can see as something other than a pixel.
Three things follow, and they are why we consider this survivable rather than fine. Blocking remote images in your mail client stops the pixel and changes nothing about the report. Using the unsubscribe link stops these notices at the relay — your reports still arrive, because the email was only ever a pointer to a report already sitting in the app. And you can leave the address field empty: the audit runs the same either way.
8. Do Not Track and Global Privacy Control
We honour both by construction on the website: there is nothing here to opt out of. We do not sell or share personal information, we operate no cross-context behavioural advertising, and a GPC signal reaching this site changes nothing because nothing is being done that it could stop. A browser signal cannot reach a pixel in your inbox, which is why section 7 gives you the switches that can.
9. If this ever changes
If we ever add anything that stores or reads information on your device beyond the strictly necessary, we will update this page before it ships, move the effective date, and — where consent is required — ask for it properly, with a real reject option given the same weight as accept. We will not introduce analytics quietly.
Contact
Buğra Günay, Erzene Mahallesi, 113/28 Sokak No: 8/4, Bornova, İzmir, Türkiye.
One address handles everything — legal notices, privacy and data subject requests, support, security disclosure and accessibility feedback: info@readyaudit.dev. Put the subject in the first line and it reaches the right person.