Privacy Policy

What the extension stores (locally only)

Evidence bundles: redirect hops, click IDs, timestamps, session-continuity events, the order number, total and subtotal, the store's registrable domain and the domains the click passed through with their roles, where the click ID was found, when the chain settled, how the capture was started (automatic, manual, or saved from a trip), a locally masked screenshot (only the order number, totals, dates, discounts, the confirmation phrase, the price amounts and the site logo are visible, each only when the text around it is free of card numbers, emails, UK postcodes and street addresses; everything else, including addresses, phone numbers, item names and product images, is black, and names are black unless they are part of an order reference), SHA-256 hashes, and, once monitoring matches the purchase or you link a portal row to it yourself, the portal's cashback and paid amount, transaction date and estimated payable date, plus, for a row you linked, a match key (merchant, date and amount); if you mark a purchase paid yourself, the amount you type (or its recorded cashback); a short status note saying why it is in its current status, written by monitoring, the daily check for untracked purchases or your own actions in the vault; and, if you file a claim from the vault, the portal reference you type (free text, your own words).

Screenshot modes. By default the screenshot is masked as described above. In the vault's settings you can switch to Classic or turn screenshots off. Classic keeps the whole page; card numbers, emails, UK postcodes and street addresses it recognises, and payment and address fields, are blacked out. Names, phone numbers and other page content will be visible in the screenshot and in any dispute PDF you send. Each saved bundle records which mode produced its image, and the dispute PDF says so.

Portal snapshots for decline monitoring: every row of your activity page as the portal shows it (merchant, date, amount, cashback, status, estimated payable date), including purchases the extension never recorded; the last snapshot per portal is kept, exported with your evidence and wiped on erase.

Portal checks, settings and the license. When each portal was last checked, whether that check succeeded and, if it failed, the reason it gave (at most 200 characters, which can quote text from your own portal activity page), which locale of a multi-domain portal you use (inferred from your own portal visits and click-outs, so the monitor checks the site you actually log into), settings, and, on Pro, the license key with its signed validation certificate, and, if you turn on timestamp anchoring, the calendar's raw receipt for each anchored bundle. Your appearance choice (dark or light) is kept with the extension's settings in its extension storage (storage.local) and copied to the extension pages’ own browser storage, a separate store, so each page opens in that theme before it has read the settings. When Pro ends, the key, the date and the server's reason (at most 200 characters) are kept so you can re-activate with one click; a successful activation removes that note.

For the free-tier save count it keeps the following. A signing key created on this device, in a browser database of its own. Its private half cannot be read out, not even by the extension. A second key in that database, which never leaves the device, makes a keyed hash of each portal account id it links. The server's last signed answer: how many saves are left for this install and for each linked portal account, and when the month turns. In that answer each account appears under the server's handle for it, with the portal's name and an opaque tag shared by the accounts that count together. The saves not yet reported, each with the bundle's id, the random id reported for it, when it was saved and the portal's name. A save also keeps the server's handle for the portal account, if it was already linked. On Pro a save keeps the license certificate instead of the portal's name and handle. For each portal account it linked: the keyed hash, the server's handle and the portal's name. When this install first registered with the server. The month of its first save while it had no answer from the server. For each count that ran out, the month you were last told so. How far this device's clock is from the server's, once the server has said so. The last day it noted that the server had not confirmed the count. Whether you dismissed the data notice. Whether the server refused to link more accounts. The extension never writes the account id itself to its extension storage (storage.local). Where a portal keeps the id in its own site storage, the portal wrote it there; the extension only reads it.

The problems log. It also keeps a short problems log, up to 200 entries of a time, a component, an error code and at most a host name (never a full address, cookie value or page content), so failures are recorded and shown in the vault's Recent problems list instead of being hidden.

Affiliate networks. It also keeps a list of affiliate networks: the ones you approved, the ones whose access was removed, the ones it saw in your click trails and the ones you told it never to ask about. About them it keeps site names and dates only, never full addresses: the portals a network was seen from and the sites next to it on its first trip, when it was first and last seen, how many trips passed through it and whether every hop through it was visible, the site access granted for it, when it was approved, removed or blocked, and whether it was already announced to you. A network it only saw is kept for 30 days after its last sighting, at most 50 of them, then dropped together with its announcement mark. Otherwise the announcement mark stays until you forget the network or erase everything, also after you undo a Never, which leaves nothing else stored about that network.

Trips and the live recording. When a purchase recording ends without evidence (the tab was closed or replaced, or the browser restarted), it keeps a trip record for 30 days (at most 20): the portal, the store's origin, the times, why it ended, the click ID, the click-trail addresses of the portal, network, any other site the click passed through, and store-landing hops, and the gaps it noticed. Trips are never used to flag a purchase as untracked; you can save one as evidence, and erasing everything removes them. While a purchase is being recorded, a one-line note (portal, store origin, times, click ID and how far the recording got) is written so a browser restart can tell you what was interrupted; it is removed when the recording ends.

Site access. It keeps a record of the site access it holds or sees granted: for each site, whether it was allowed for a purchase, for an affiliate network you approved, or in Chrome's extension settings, since when, and which purchase recordings use it; and which of its built-in sites (the four portals and the networks it ships) Chrome is currently blocking or allowing on https pages only. When it asks Chrome for site access Chrome does not already allow, it also keeps the site pattern it asked for, whether the request was for a purchase or an affiliate network (and, for a purchase, which recording it was for), and when it was made, so a grant you allow after the popup closed is still known as its own and removed the same way. That note goes when a purchase recording or an approved network takes the grant, when the extension or Chrome removes that access, when you deny the request in a popup or vault tab that is still open, and when you erase everything; otherwise it goes the next time the browser starts or the extension is updated, reloaded or turned off and on again (for a network whose access Chrome holds, at the first such time the network list can be read). It keeps short site-access notices, each naming a site: that Chrome is blocking one of its built-in sites or allowing it on https pages only, or that access to a network you approved was removed. A notice goes away when that access comes back; erasing everything clears them, and one that is still true comes back right after.

Session storage. While you browse a portal or a purchase is being recorded, it keeps in the browser's session storage (emptied when the browser closes, when the extension is disabled or updated) the live recording itself (every hop so far including same-store page addresses, continuity events and notices, and the account id of the portal account signed in at the click, until the server answers with its handle or the recording ends), plus which open tabs show a portal, the addresses of the portal pages each tab showed in the last few seconds (at most 12 per tab, each kept at least 8 seconds after it loaded, then dropped the next time the extension handles a browser event or one of its own timers, except the page the tab is still showing) so a click-out can be matched to the page you clicked on, recent clicks (on the free tier with the account id read at each, or the server's handle for an account already linked; a click with an account id is deleted about 8 seconds after it, and any other click is kept at least 8 seconds, then dropped the next time the extension handles a browser event or one of its own timers) and opened tabs, the site access it has just asked Chrome for, whether network announcements are snoozed, and when a portal-account link that failed may be tried again.

All of it stays on this device, in the browser's storage for the extension: its extension storage (storage.local), its own databases, its pages’ own browser storage and, where said above, its session storage. There is no cloud copy, no sync and no account; nothing leaves the device except what the complete network surface below lists, which includes the free-tier usage count.

What the extension observes (on the device)

On the four portal sites, the extension notes the time of each click you make, not what you clicked or where it pointed, so it can tell a cashback click-out from an address you typed. At each such click it also reads, on the device, which portal account you are signed in to: the account id, from the portal's own cookie, page script or site storage. It uses the id only for the free-tier count, and sends it only for a click-out, as the network surface below says. On Pro it does not use the id at all. It never writes the id into saved evidence, saved trips or the problems log. A click-out link's own tracking codes are kept as the portal wrote them, and a portal may build those from your membership.

Following the click-out. When you leave the portal right after a click, it follows the navigation to the store and records the address of every page the tab passes through between the portal and the store, and of every redirect Chrome reports along the way (portal and affiliate-network hops, any other site the click passes through, and the store page you land on), plus the store's origin. On the store it records only same-store page addresses while the purchase is live; of other sites you visit it keeps at most the origin of a site you leave the store for, and the address of an affiliate-network or portal redirect that interrupts the purchase.

What is kept of each address. Each of these addresses is cut down before it is written into an evidence bundle or a trip record: it keeps the site and the page path. In the path, card numbers and emails in any script are masked, and so are street addresses written as words with capitals, such as "12 High Street", and UK postcodes in upper or lower case, with a space or without one, such as "SW1A 1AA" or "sw1a1aa"; page names that use hyphens, such as "12-high-street" or "sw1a-1aa", and street addresses in lower case are not masked. Any part of the path that carries another web address with its scheme, such as "https://", or a query of its own is left out. From the query text, the click ID and the details naming the affiliate who sent the click are kept exactly as they are; on the store's own pages, only the click ID and the details that name one affiliate network are kept. Every other part of the query is removed, and so is anything after a "#". An address that is not a web page, such as a blob:, data: or app link, is stored as its scheme followed by "[omitted]". While a purchase is open, the live recording kept in the browser's session storage holds the page addresses as seen; it is emptied when the browser closes. Timings and hops stay on the device.

During a purchase you started from a supported portal, the extension watches the affiliate tracking cookies on the portal's affiliate networks and on networks you approved (and, if you enable auto-capture, on the retailer) to detect when a coupon extension, ad-blocker, or other party overwrites or clears the cookie carrying your cashback attribution. This is read-only: the extension never sets or removes a cookie, and the cookie's value is never stored or transmitted. The only things it records are the network name, the cookie name, a timestamp, and whether the cookie matched your own click. Reading happens entirely on your device; nothing about it goes over the network, and it adds no new network destinations; the complete network surface below is unchanged. You can turn the attribution radar off in the vault's settings; when it is off, nothing is read from the retailer, and nothing is recorded, classified, or acted on.

The optional conflicting-extension scan runs only when you click "Scan for conflicting extensions" in the vault's settings. It reads the installed-extension list Chrome reports (each extension's name, id and on/off state) once, on this device, keeps only the matches against a list of known coupon and cashback extensions bundled with the extension, and removes the permission it asked for when the scan finishes. If the vault tab closes mid-scan, the extension removes it the next time its background starts while none of its pages is open in a tab. Nothing about it goes over the network. Erasing everything in the vault also clears the stored result.

The complete network surface

1. 01

   Your portal pages: the extension reads cashback activity pages on the four supported portals using your own logged-in browser session: when you visit a portal, and once a day in the background for each portal where it has already seen you signed in. No credentials are collected or stored.

2. 02

   license.cashbackproof.com (Pro license and checkout links): when you activate Pro, deactivate this device, or about once a week to revalidate, the extension sends your license key (and, after activation, its activation instance id) to validate the subscription with the payment provider. The server keeps no record of the key. If it is unreachable, Pro keeps working for 14 days (fail-open; it retries about daily while it is unreachable or while its answer can't be verified on this device). Outages never lock your data. Opening the vault on the free tier fetches the current checkout links from the same server (a plain GET, no identifiers sent); they are reused for a day and fetched again on the next open after that; an unreachable server keeps the old copy.

3. 03

   license.cashbackproof.com (free-tier usage count): the free tier saves 10 evidence bundles to start, then 3 per calendar month. The server keeps the count for each portal account you click out from while signed in, so a reinstall does not reset it. For this the extension signs its reports with a key created on this device.

   What it sends. It sends the portal's name and your account id on that portal, read from the portal page you are signed in to. It sends them once per account and install (again after a failed try or a deleted record), at your first click-out from the portal while signed in: when a click takes you off the portal and the extension records the trip. A click that stays on the portal, or one on a portal you switched off, sends nothing. It also sends a random id for each saved bundle, with the portal's name and, once the account is linked, the server's handle for it, but nothing from the bundle itself. Saves are reported together, at most once a day and, once this install has registered, when you delete the record. Your browser's name and the extension's version are sent only when this install registers with the server: at its first click-out or report, and again after a deleted record or if the server lost the install.

   What the server keeps. The server keeps only a keyed hash of the account id, never the id itself. Every time it keeps is a day (UTC), never a time of day. Our database host keeps a restore history of the database for up to 30 days. Per install it keeps: the public half of that key, your browser's name and the extension's version, and the day it was created and last seen. Its counts: starting and monthly saves used, the month they belong to, bundles saved in total, saves with no known portal account, and portal accounts ever linked (at most 8). It also keeps which hashed portal accounts each install is linked to, and since which day. Per hashed portal account it keeps: the portal's name, the version of the key that made the hash, the day it was created and last seen, and which other hashed accounts share its count. Its counts: starting and monthly saves used, the month they belong to, bundles saved this month and last month, and the day a month's count ran out. An account linked again after a deletion keeps that month's saves used, until the 1st of the next month. For each saved bundle, for 30 days: its random id and the day it arrived, so a repeated report is counted once. It never receives your stores, orders, amounts, page addresses or screenshots.

   On Pro. With Pro the extension sends no portal account id. It reports only each saved bundle's random id, with the license certificate (which carries a hash of your license key and the activation id; neither is stored). The server then keeps that the install is on Pro, since which day (kept if Pro ends), and how many bundles it saved; the bundle id is kept for 30 days like any other. Records not seen for 24 months are deleted.

   Deleting your usage record. "Delete my usage record" in the vault's settings erases this install's record, its links and its bundle ids at once, not those of your other devices. An install that has registered with the server first reports its saves not yet reported when you press it. If a save cannot be reported, nothing is deleted. An install that never registered reports nothing: its saves not yet reported when you press it are cleared from the device. A save made while the delete runs is kept and sent with the next daily report. An account another install still links (usually another device of yours) keeps its count; only this install's link to it is erased. An account no other install links is reduced to a short record, kept for 24 months. It holds the portal's name, the version of the key that made the hash, the day it was created, the day of deletion and the month of its last count. It also holds how many of the 10 starting saves were used and that the current month's saves are used (until the 1st of next month). This way deleting and reinstalling does not restart a portal account's count. This install's own count does start over from the starting saves. Until it links a portal account again, that count is used for every free save, also for saves made while signed out.

   If the server is unreachable. If the server is unreachable or its answer can't be verified, the extension counts on the device from its last answer and never refuses a save that count still allows. We process the usage count to provide the free tier on its terms and, for the record kept after deletion, to prevent abuse of it (GDPR Art. 6(1)(b) and (f)).

4. 04

   OpenTimestamps calendars (opt-in, OFF by default): if you enable timestamp anchoring, the extension sends the 64-character SHA-256 fingerprint of a new evidence bundle to an OpenTimestamps calendar (a.pool.opentimestamps.org or b.pool.opentimestamps.org). The fingerprint reveals nothing about the bundle's contents; it lets you prove later that the evidence existed by that date.

Nothing else. No analytics service, no tracking scripts, no error reporting, no content servers. The usage counts above are the only measure of use we have. We read them in aggregate (how many installs by browser and version, how many free accounts reach the monthly limit, how often a save arrives with no portal account) to run the free tier and to notice a broken portal reader. Our legal basis for these statistics is our legitimate interest in running the free tier and keeping the extension working (GDPR Art. 6(1)(f)). We do not look at records one by one except to investigate abuse or a fault. license.cashbackproof.com keeps no request logs; its rate-limit counters are keyed on your full IPv4 address (or, on IPv6, its /64 network prefix), on a hash of your license key or on the install's public key, counted over 60-second windows.

Payments

Pro is not on sale yet. It will be sold through a merchant-of-record payment provider; payment details never touch Cashbackproof. The license key it issues is the only purchase artifact the extension ever sees.

Your controls

Export your evidence as JSON (bundles, screenshots and portal snapshots; trip records, network list, site-access records, monitor status and settings are not included), erase everything, delete your usage record on the server, deactivate the license on a device, and toggle every feature, including screenshot privacy (Private, Classic or Off), all from the vault's settings.

"Erase everything" wipes evidence, removes the site access you allowed through Cashbackproof for your purchases and for the affiliate networks you approved (site access you granted in Chrome's extension settings stays), forgets every network it has seen, approved or been told never to ask about (and those whose access was removed), forgets the site-access requests it is still waiting on, deletes the trip records and the live-recording note, and clears its notices and the problems log (a site-access notice that is still true comes back right after). It keeps the license (it isn't evidence) and the note that Pro ended (your key, the date and the reason). It keeps your settings, each portal's last-check status (including the reason a failed check gave), which locale of each portal you use and an internal version stamp. It keeps the cached checkout links; they are fetched again only when you open the vault on the free tier once they are a day old, and an unreachable server keeps the old copy. It keeps the free-tier save count on the device, so the saves you made stay counted. Until the browser closes, it keeps which open tabs show a portal.

"Delete my usage record" removes the count on the device together with the server record. It keeps only the two keys in its own database (the signing key and the key for account hashes), your answer to the data notice, how far this device's clock is from the server's, the last day it noted an unconfirmed count and any save made while the delete runs.

Uninstalling the extension deletes all local data, both keys included. The usage record on the server stays until it goes unseen for 24 months, so delete it in the vault's settings first if you want it gone now.

Notifications shown by the operating system can name a purchase's merchant, store, portal, order number and cashback or purchase amount, an affiliate network or site your click passed through or that Chrome is blocking, and the reason an ended Pro license gave (at most 200 characters); on a failed portal check they show nothing from the page itself (the reason is shown in the extension's popup instead); your operating system may keep its own notification history outside the extension, which erasing or uninstalling does not clear.

The free tier never deletes or locks evidence. Every feature works on it; it saves 10 evidence bundles to start, then 3 per calendar month (UTC). At the limit the extension keeps checking your tracking live and warning you, but saves no new bundle until the month turns or Pro is active. Every bundle already saved stays fully usable: in the vault, in a dispute PDF, in monitoring and in export.