Why mikbry.com has no cookie banner

Mik Bry · 2026-08-18 · ~7 min read · Privacy · Trust

I click "reject all" on almost every cookie banner I see.

On mikbry.com, I'd rather not ask you the question at all: I simply don't use the trackers that would require your consent.

I measure what I need to know if the site is useful — how many pages get read, which buttons get used, and roughly when. I don't need to know it was you, and I won't recognize you next time you're back.

A cookie banner is not a privacy strategy. Collecting less data is. That's the idea this piece walks through — not "banners are theatre," but what a site like this one actually needs to measure, and what it looks like to build for that instead of asking permission for more.

01 — Why there's no banner

A banner typically appears when a website uses cookies or other trackers that require your consent — for advertising, cross-site tracking, or certain audience-measurement tools. mikbry.com doesn't use trackers that would require your consent to measure its audience. That's why there's no cookie banner: this is a cookieless website by design, not by omission.

A strictly-necessary cookie to keep you logged in can be used without asking your consent — that exemption has always existed. When a site uses trackers that do not qualify for an exemption, it has to obtain consent before using them. A banner is simply the most common way to ask.

None of this is unique to me. A crop of 2026 analytics tools — Plausible, Fathom, Cloudflare Web Analytics, Umami, PostHog's cookieless mode — offer measurement modes without ad cookies or persistent individual tracking. Depending on their configuration and the data they process, this can let a site avoid requiring consent in the first place. That's the same choice mikbry.com makes. I prefer to collect less data than to ask permission to collect more.

Sources: Plausible, Fathom, and Cloudflare Web Analytics describe their cookieless measurement modes. Legal framework in the technical section below.

02 — What I actually measure

Here's the minimum I actually need to know if this site is working. Everything past that is decoration I've chosen not to add.

Analytics. mikbry.com counts pages read and buttons clicked, aggregated by the hour — not "someone read /about between 3 and 4 PM Paris time" as a stand-in for a specific visitor, genuinely just that count. No visitor identifier is attached, and no session connects one page view to the next. I don't know it was you. I won't recognize you next time you're back.

Security logs — a separate thing. The web server keeps the same basic records any host keeps for security and abuse prevention: an IP address, a timestamp, the requested URL, the user agent. These are retained for 7 days, then deleted. This is not analytics — they are not used to analyse visitor behaviour, they exist only to catch abuse or investigate an incident, and they are never merged with the aggregate counts above.

The only place I learn something specific about a visitor is the place they told me to: if you send me an idea or ask for a report, that's a form you filled in and a button you pressed — not something I was watching happen.

03 — What I deliberately don't collect

No ad network, on this site or feeding into one elsewhere. No cross-site tracking — nothing here follows you to another site, and nothing brings a profile built on another site to this one. No session recording, no heatmaps, no tool that replays how you moved your mouse. No individual profile of any kind: there's no record that represents "you," only aggregate counts that represent some number of visits.

The analytics counters, security logs, and form submissions described here are hosted in France. Nothing gets shipped to an ad platform in another jurisdiction, because there's no ad platform in the loop.

04 — How you can verify it

I'd rather you check this than take my word for it.

05 — What this choice costs the business

I want to be honest about the price.

There's no remarketing pixel, so I can't show an ad to someone who visited and left. There's no cross-site attribution, so I can't tell which article led to which paid Trust Report three weeks later — I get an hourly count, not a funnel. There's no audience segment to export elsewhere. If growth marketing is your model, this stack is a real handicap.

It's a tradeoff I make on purpose, for a business shaped a specific way: a small number of buyers, sold to directly, over conversations rather than ad campaigns. I don't need to correlate a click three weeks ago to a sale today — I already know who I talked to and why they bought. What I need is for the people who land here to trust what they're reading enough to email me, and a site that quietly profiles them while claiming to be trustworthy would work against that. The signal I care about is quality of relationship, not quantity of retargetable traffic.

06 — For the technical reader

Tracking. /e/track and /e/submit are the two first-party endpoints the site uses for edge tracking and form submissions. Both terminate on our Caddy-fronted VPS; neither calls a third-party service. /e/track fires a fire-and-forget request on page load — no cookie set, no browser storage touched — and lands as an anonymous hourly bucket, not a per-visitor record. /e/submit carries only the fields a given call-to-action explicitly declares. Security logs (Caddy — IP, timestamp, URL, user agent) are retained separately, 7 days, for abuse prevention only.

Legal basis. In France, the rules specific to cookies and other trackers come from Article 82 of the Loi Informatique et Libertés, which transposes the ePrivacy Directive. GDPR then applies whenever the processing involves personal data, and defines what a valid consent looks like. The data-subject rights described on the privacy page — access, rectification, erasure, restriction, portability, objection — come from GDPR Articles 15–22.

Sources: CNIL — what the law says about cookies and trackers confirms Article 82 as the specific consent rule and its exemptions, including for strictly-necessary purposes and certain audience-measurement configurations.

Manifest. /.well-known/privacy.json publishes the claims above in machine-readable form: what's tracked, what isn't, hosting jurisdiction, log retention in days.

Header stack. mikbry.com is missing two response headers that would tighten this further: Referrer-Policy: strict-origin-when-cross-origin (so full URLs don't leak into outbound-link referrer data) and a Permissions-Policy including browsing-topics=() (an explicit opt-out of the Topics API). It also doesn't emit Content-Signal: search=yes, ai-retrieval=yes, ai-train=no — a voluntary, still-emerging convention (content-signals.org), not a security or privacy standard; adopting it is a forward-looking signal, not a compliance claim. These headers live in the shared Caddy configuration we run across our infrastructure, applied centrally rather than duplicated per project.

This is how I design my own products and the systems I put in place for my clients: minimal analytics, European infrastructure where relevant, explicit consent, and verifiable transparency.

07 — Trust Report and Audit

The trust cornerstone piece on this site is about boundaries an AI-built app crosses without anyone deciding it should — payments, authentication, other people's data. The check I ran on my own site while writing this is the same one: not "does it work," but "what actually happens, and did anyone agree to it."

A cookie banner is not a privacy strategy. Collecting less data is — and that's a decision, not a default, the same way checking what an app actually does before launch is a decision, not a default.

If you want the security and access side of that check, Six things I check before trusting an AI-built app in production covers it. This piece covers the privacy side. A Trust Report or an Audit puts both under one review before you launch.