What belongs in a privacy receipt
A useful receipt names the page context, the kind of protection, the browser-visible evidence, and the time of the event. Examples include a selected tracker request blocked, a supported campaign parameter removed, a selected recognition signal reduced, or a visible pressure warning shown.
The wording should stay proportional. “This request was blocked” is inspectable. “This company can no longer recognize you” would go beyond what a browser extension can prove.
What the receipt is not
A Cloak privacy receipt is not the receipt for something you purchased. It does not file orders, reconcile expenses, prove payment, certify a merchant, or guarantee that a transaction was secure.
It also does not expose a merchant backend. Server-side analytics, account records, payment systems, inventory, fraud controls, and data another company already holds may remain outside the browser-visible record.
Why local evidence matters
A privacy product should not need to build a new central history of every protected page simply to explain itself. Chrome provides extension storage that can keep extension state on the device. Cloak uses local receipts and current-window counters to make selected actions readable without treating browsing history as a marketing dataset.
Local does not mean magical or permanent. Browser profiles can be cleared, devices can be shared, and extension storage is not a substitute for encrypted archival records. The design goal is data minimization and useful product feedback.
How to read a Cloak receipt
Start with the action category, then the supporting detail. A blocked tracker count, removed parameter name, pressure label, or recognition-reduction event explains what Cloak observed or changed in that browser window.
Use the receipt to verify the extension is active and understand its selected scope. Do not use it as proof of anonymity, lower prices, fraud prevention, or total tracking prevention.
Primary sources