A metered paywall counts free articles in a cookie the reader controls, so clearing site data, opening a private window, or switching browsers hands them a fresh allowance. Keying the meter to a cross-browser hardware fingerprint, which survives all three, makes the meter hold.
Why metered paywalls leak
A metered paywall gives a reader a few free articles, then asks them to subscribe. The standard implementation counts in a cookie or in localStorage. That counter belongs to the reader, and the reader can reset it: clear site data, open a private window, switch browsers. Each move hands them a fresh allowance.
The result is that the meter leaks to precisely the readers it is meant to convert, the engaged ones who hit the limit. The fix is to key the meter to something the reader does not control.
Why cookies, IP, and a hard wall each fall short
A cookie or localStorage meter is reset in one click and never written at all in a private window. Tying the count to storage the reader owns is tying it to their goodwill.
IP-based metering is blunt in both directions. Shared offices and carrier NAT make one IP many readers, so an office gets walled off by a single heavy reader; VPNs and mobile networks make one reader many IPs, so the meter resets at will.
A hard registration wall converts fewer readers than a meter, because it trades the soft on-ramp for friction up front. Most publishers want the meter. They just want it to hold.
Key the meter to the device, not the browser
A device-bound meter counts against the `hardwareFingerprint`: an identifier derived from hardware-bound signals that is the same across Chrome, Safari, Firefox, and Brave on one machine, and the same in a private window as in a normal one. The reader who exhausts the meter, clears cookies, and reopens in incognito presents the same hardware fingerprint, so the server-side count carries straight over.
Because the hardware fingerprint is recomputed on each visit rather than stored in the browser, there is nothing for the reader to clear. The meter lives on your backend, keyed by the device id; the browser only supplies that id.
import { getFingerprint } from 'doorman-benny';
// Before rendering a metered article, check the device's allowance.
async function readMeter(): Promise<{ allowed: boolean; remaining: number }> {
const result = await getFingerprint();
const response = await fetch('/api/paywall/meter', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
// Survives cookie clears, private windows, and browser switches.
hardwareFingerprint: result.hardwareFingerprint,
// Telemetry only: how much reset traffic is private-mode. Not a gate.
incognitoLikelihood: result.incognito.incognitoLikelihood,
}),
});
return response.json(); // { allowed, remaining } from your meter store
}The meter count lives on your backend keyed by hardwareFingerprint. The client supplies the device id; incognitoLikelihood rides along as analytics, not as an enforcement input.
Incognito is analytics here, not enforcement
It is tempting to block private browsing outright. Do not, and note that you do not need to. The device-keyed meter already carries over in a private window, because the hardware-bound signals resolve to the same `hardwareFingerprint` whether or not storage is available. The meter holds without touching the incognito signal at all.
`result.incognito.incognitoLikelihood` returns 'low', 'medium', or 'high', and it is informational by design: the library documents that it should not feed fraud or gating decisions, because doing so produces false positives on the many readers who use private mode for ordinary reasons. Use it on your dashboards to understand how much meter-evasion traffic is private-mode, not to decide who sees a wall.
What still needs care
Shared devices cut the other way here. A library terminal or a family laptop is one hardware fingerprint, so a device-bound meter is consumed by whoever uses that machine, and the next reader on it sees fewer free articles. For most publishers that is an acceptable trade against the far larger cookie-clear leak, but it is a real effect: if a meaningful share of your traffic is shared-device, keep the meter generous and lean on a registration prompt rather than a hard wall.
Hardware-bound signals also drift on legitimate events such as a new monitor or an OS update. `compareFingerprints` in `cross-browser` mode lets you treat a near-match as the same device, so a returning reader is not handed a fresh allowance by a minor hardware change. The meter is a soft gate, so erring toward continuity is the safe direction.
Frequently asked questions
Does clearing cookies reset a device-bound meter?
No. The hardwareFingerprint is not stored in the browser; it is recomputed from hardware-bound signals on each visit. Clearing site data removes the cookie-based counter, but the device id comes back identical, so the server-side meter count carries over.
Does opening incognito reset the meter?
No. Private mode blocks storage, but hardware-bound signals still resolve to the same hardwareFingerprint, so the meter carries over. The incognitoLikelihood signal flags the session as likely private for analytics; it is not used to block anyone.
Should I just block readers in private mode?
No. Blocking private browsing reads as hostile, breaks legitimate private use, and is easy to evade. You also do not need to: the device-keyed meter already holds in a private window. Keep incognitoLikelihood as an observability signal, not a gate.
What about a shared computer like a library or family laptop?
It is one device, so the meter is shared across everyone who uses that machine and a second reader sees fewer free articles. For shared-device-heavy audiences, keep the meter generous and prefer a registration prompt over a hard wall. It is a real tradeoff, not a bug.
Is a fingerprint-based paywall meter legal?
It depends on jurisdiction. Paywall metering is treated more like tracking than like fraud prevention, so the fraud-prevention exemptions do not automatically apply and disclosure, sometimes consent, may be required. See the laws/cookies-vs-fingerprinting and laws/consent-banners-fingerprinting pages. This is engineering documentation, not legal advice.
Get started
Make your meter hold
npm install doorman-benny. A cross-browser hardware fingerprint that survives cookie clears, private windows, and browser switches, so your metered paywall counts the device, not the cookie.
Last reviewed June 17, 2026
