What a person reads about health is a statement about their health. Somebody reading about a diagnosis, a medicine, or how to find a professional for a condition has disclosed something about themselves without filling in a form, and a publication that keeps that record holds sensitive information about a reader who was never asked for it. Most health sites treat the record as an asset. This one is built so that it is not created.
What is not collected
This publication sets no cookie of its own — not an advertising cookie, not an analytics cookie, not a preference cookie, not a "necessary" one. It ships no advertising pixel, no conversion tag, no retargeting script, no behavioural profiling, no cross-site identifier, no fingerprinting library, no session replay and no third-party analytics. None at all, rather than none that identify a reader.
That holds because of how the site is built, not because of how carefully it is operated. The
journal is exported as static files, so the framework refuses cookies(), headers(),
searchParams and middleware at build time: there is no server here that could set an
identifier and no request-time hook where one could be attached. Article bodies are Markdown
rendered through remark/rehype with rehype-sanitize rather than MDX, so an article cannot
execute JavaScript and cannot carry a tracker into a page as content.
What is typed into search
The most revealing thing a reader does on this site is type a symptom into the search box. Search runs entirely in the browser, against a static JSON index shipped with the site. Nothing typed is sent anywhere, logged, or placed in the URL — which also means it is not in a browser history entry, not in a link somebody might share, and not in the referrer of any request that follows.
Reading is attached to nobody
The journal has no authentication, no database and no access to marketplace data. Reading is never linked to a GMedAC account, and no article is selected, ordered, highlighted or personalised from what somebody has searched for or booked on the marketplace. There is no "recommended for you" here, because a personalised health page is a legible inference about the reader, visible to anybody who can see the screen. The marketplace is at Phase 0 — no checkout, no live payment provider, no deployment — so there is nothing to join today. Nothing enforces that once there is: the commitment is that linking reading to an account would be a decision recorded in the open, not an integration that arrives quietly.
Nothing here accepts a symptom
There are no comments, no reader accounts, no user profiles, no patient stories, and no free-text field anywhere in which somebody could describe their own condition. That is a design decision rather than a moderation strategy: a field that accepts a symptom will eventually receive one, and once received it has to be stored, secured, retained and answered for.
Links out of an article
Following a link out of an article can tell the destination which article it was, because the
path names the subject. The policy this journal has decided on is Referrer-Policy: no-referrer, so that a regulator, a register or a guideline publisher is told neither which
page was open nor that the visitor arrived from here — a deliberate loss of attribution.
Two limits belong with that. A static export sends no response header of its own, so the header
is served by whatever hosts the files. This repository does declare it, in vercel.json, and a
test sends real requests to a local server reading that same file and asserts the value comes
back — which establishes that the header set is complete and correctly scoped, and establishes
nothing about whether the platform applies it. That last step needs a deployment and has not
happened. And a referrer policy is a directive rather than a mechanism: it constrains browsers
that obey it, and nothing else.
The cookie this journal cannot refuse
If the journal is one day served under the marketplace hostname rather than on its own, the browser will attach the marketplace session cookie to every request for a journal page, and to its assets and its search index alongside them. That cookie is scoped to the root of the domain and cannot be narrowed to exclude a path. The journal neither sets it nor is consulted about it. In that arrangement, a request for a health article reaches whatever serves it carrying an identifier that belongs to a marketplace account — an association between a person and a subject, made by the browser, on a site that collects nothing.
What the static export does about that is narrow, and worth stating narrowly. Reading the cookie
at request time is refused outright: cookies() and headers() fail the build under a static
export, there is no middleware and no server route to run when a request arrives, and sanitised
Markdown cannot execute the JavaScript that would reach a cookie from inside an article. That
much is a property of the artefact rather than a restraint somebody maintains. Code running in
the reader's browser is the weaker case, and is stated as such: nothing in the framework stops a
future component reading document.cookie. The site ships none that does, which is a fact about
the current code and about review, not a refusal the build makes.
It does not remove the exposure. The cookie is still sent. What a host or a CDN writes into a request log is configuration outside this repository and is not described here, and no static export makes a request invisible. This is honest, not clean. No such hostname arrangement is in place today, and recording the consequence now means it is decided in the open rather than discovered afterwards.
An absence of accounts, cookies and clinical fields also does not settle whether a record of who read what is health data in law. That question turns on facts and jurisdictions this repository has not researched, and nothing above answers it. Absent fields answer an engineering question, never a privacy one.
What is not decided
Whether this publication will ever carry aggregate, non-identifying analytics is undecided. Silence does not decide it and this paragraph does not decide it. Today there is none, and a lint rule names the analytics, advertising, session-replay and error-reporting packages and refuses their import, so adding one of them fails verification rather than passing unnoticed. A package that rule does not name would pass it: the rule is a backstop for the decision, not the decision.
If such a measure is ever introduced, the decision is recorded here first — with a date, an owner and a stated reason, and a description of what is counted and what is still refused — before any measuring code ships. Analytics arriving as a quiet dependency upgrade, noticed later by a reader watching their network tab, is the failure that ordering prevents. We commit to the order, not to the outcome.
Nothing above is a legal conclusion about data protection, cookies or health data in any jurisdiction. Those rules differ by country, none has been researched here to a standard this repository would publish, and a document that reads like compliance is not compliance. What is stated is what this journal does and what its build refuses; where a control depends on a browser's cooperation, a host's configuration, or a decision nobody has taken yet, it says so.