One dependency, one third party, zero trackers

The shop’s promise is simple: no ads, no trackers, no third-party code — with exactly one exception, Stripe’s JavaScript on the checkout page, because a card form that is not Stripe’s is a card form you should not trust.

That promise is easy to write and hard to prove, because the most important thing the audit found was third-party code that was not in our source at all.

What “zero third parties” has to mean

A naïve check is a grep of the HTML. That check returns zero references, and it is wrong. The independent verification found that the live storefront was contacting:

https://static.cloudflareinsights.com/beacon.min.js/…

Cloudflare — the CDN in front of the shop — was injecting its analytics beacon into the rendered DOM of real browser sessions. It appeared in no response body:

The lesson is in that table. “No third-party code” is a claim about the wire, not about the repository. The only way to check it is to run the page and watch what the browser requests and what the DOM contains.

The mitigation, and then the real fix

The first fix was a Content-Security-Policy that forbids scripts from any origin but ours. Verified in Chromium, it blocked the beacon’s execution while leaving the shop’s own scripts, the inline window.APP_BASE bootstrap, stylesheets and images working. The accepted cost was one console error — the CSP refusing the beacon — which is the mitigation working, not a defect.

The real fix came next: the injection was switched off at the source in the Cloudflare dashboard. That was verified by measurement, not by the toggle’s position:

Only then did the [ PROOF ] band’s claim become unconditionally true instead of true-by- interception.

What else the page does not load

• No analytics — no Google, no Plausible, no Cloudflare Web Analytics after the fix.
• No ad code — there is no ad slot and no ad network.
• No CDN fonts — the two variable fonts are self-hosted, 89 KB total, served from the same origin.
• No framework — the storefront and the order desk are hand-written HTML, CSS and JavaScript; the server is one Node process. The only network dependency in the customer path is Stripe, and it is loaded on /checkout only, because PCI rules require Stripe.js to be hosted by Stripe.
• No tracking cookies — the cart lives in local storage on the reader’s machine; the session cookie belongs to the store’s own accounts, not to a third party.

The verification counts origins from request events, not from the source: it opens the shop in Chromium and records every origin the page actually contacts. The only one allowed is the shop’s own. When the beacon existed, the check failed; after the fix, it passes with zero.

Why this is engineering and not marketing

A privacy claim is a verifiable property with a measurable failure, which is exactly the kind of claim this publication is built on:

1. The property: the page contacts no origin other than its own, except Stripe’s JS on the checkout page.
2. The measurement: a browser session, a request listener and a DOM check — not a grep.
3. The failure: a single unexpected origin fails the audit, and the claim comes off the page until it is true.

That is also why the fix is recorded in the open: the site had a third-party beacon for a while, the audit caught it, and the claim was weakened (CSP-blocked) before it was made true (injection off). A privacy claim that cannot fail is marketing. This one can.

What I’d tell someone

1. Test the DOM and the wire, not the source. Your CDN can inject code that is nowhere in your repository.
2. Know your one exception and name it. Stripe on checkout is a defensible exception; “some third-party scripts” is not.
3. Self-host the boring things. Fonts, CSS, JS: they are small and they are yours.
4. Let the claim fail loudly. If the audit detects an unexpected origin, take the claim off the page until it is true again.
5. Verify the deployed host, not the local one. The beacon only existed in production.

The shop is a smaller product for having no trackers. It is a more trustworthy one for being able to prove it — and for publishing the week it could not.

The third-party audit and the origin-verification method are attached below; both are from the independent verifier’s report, with the measured probes and the fix.