CookiePal plugin - Privacy Notice

The page is loaded on your own machine, in a fresh temporary browser profile, by the plugin. CookiePal never loads it. Our server hands out the plan before a check, validates and stores the result afterwards, counts checks, works out the country a check ran from, and applies the limits that keep the service available to everyone.

What reaches CookiePal is the page's origin and path, the cookies found without their values, the third-party hosts the page contacted, the plugin's version, the country the check ran from, what happened when the check pressed the banner's accept and reject buttons, two technical details about the result, and a random install ID if you agreed to share one. Nothing else.

We do not store your IP address and we never receive a cookie value. To keep the free check tools from being flooded, we count calls from each network under a hash of the address made with a secret key, so the stored count alone does not reveal the address, and it is deleted automatically about an hour after its ten-minute window ends. A check is not tied to any account unless you connect one and also agree to link your install ID to it.

Connecting a CookiePal account is optional. If you do, we also record which of the account's tools you use and when, and, only if you agree, which account your install ID belongs to. Your account itself is covered by our main privacy policy.

The page you checked, reduced to its origin and path. The query string and the fragment are removed on your machine, before anything is sent, because they can carry session tokens, email addresses and other identifiers. For example, a check of https://example.com/pricing?session=abc#plans is sent and stored as https://example.com/pricing. The plugin refuses to send a page address that still has a query string on it, and our server stores only the origin and path in any case.

The cookies that were found - each one's name, domain, path, expiry, its Secure, HttpOnly and SameSite flags, and the category assigned to it. The value of a cookie is never sent and never leaves your machine.

The third-party hosts the page contacted while it loaded.

The plugin's version number, so we can tell which release produced a result.

The country the check ran from, worked out from the IP address your request arrives with. The IP address itself is not stored: it is used for that one lookup and, for the tools that need no account, to count calls from your network, as described under how long we keep it. We keep the country, not the address.

What the banner's buttons did, when the check pressed them: whether a banner was found, whether accept and reject could each be pressed and, if not, why, and how each button was recognised. For each press, the cookies still set afterwards and which of them the press itself added, and the third-party hosts contacted after it. These are the same kinds of record as above, and cookie values are left out of them too. If the page says its own CookiePal banner applies reject when it loads, that claim is sent as well.

A random install ID, only if you agreed to share one. See below.

Two technical details about the result: which version of the result format it uses, and whether the check hit its size limits and left some cookies or hosts out.

Cookie values, local storage and session storage contents, the page's HTML or text, form input, screenshots, the query string and fragment of the URL you checked, and your own browser profile. Our server has no field for a cookie value and rejects any result that tries to include one, so this is enforced rather than promised. Some of these pass through Claude Code on your machine, as the section on Claude Code below explains, but none of them reaches CookiePal.

The check never uses the browser profile you browse with. Every run launches a fresh temporary profile, so your own cookies, sessions and sign-ins are never opened and never read.

Cookies are categorised on your machine, against the open-source @cookiepal-oss/cookie-db catalogue that ships with the plugin. No cookie is sent anywhere to be identified, and the category travels with the result rather than being worked out on our side.

The plain-language read of your result is also produced entirely on your machine, from fixed wording that ships with the plugin. Producing it sends nothing to CookiePal.

We would like to know roughly how many people use the plugin, not just how many checks are run. The only way to tell those apart is a random identifier that stays the same between your checks.

The first time you run a check, the plugin asks you once whether to share one. The default is no, and the check works either way. The ID is created only after you say yes. It is a random value with nothing derived from your machine, your network or you, and it is kept in the plugin's data folder, so removing the plugin removes it.

We ask because the install ID is stored on your device for our own measurement rather than because the check needs it. Storing or reading information on someone's device generally requires consent unless it is strictly necessary for the service they asked for, and measurement is not, so we treat consent as required here.

A persistent random identifier is still personal data under the GDPR, even when it is not linked to a name or an account, so we treat it as such. It is used to count unique installs and, only if you separately agree when you connect a CookiePal account, to tell whether the checks made under it led to that account. It is not used for profiling or advertising, and we never share it with anyone. Like everything the plugin sends, it passes through your own Claude Code session on its way to us.

To stop sharing it and delete it from your machine, run /cookiepal:check-one-page stop-sharing. That same command deletes the checks you have already submitted and removes any link between the ID and a CookiePal account: the plugin sends the ID to us one last time, we erase every check stored under it and the link, and only then is the ID removed from your machine. It tells you how many checks were deleted. Withdrawing consent stops any further collection or use of the ID, and it does not make the processing that happened before you withdrew unlawful.

Checking a page never needs an account. If you want to use CookiePal on a site you run, /cookiepal:connect-account connects Claude Code to a CookiePal account. You sign in, continue with Google, or create a free account on CookiePal's own pages in your browser. Your password never passes through Claude Code or the plugin, and the plugin never sees it. Claude Code keeps the sign-in it is given on your machine, under your own agreement with Anthropic.

Your account itself - your email address, your organisation and your domains - is covered by our main privacy policy, not by this notice. What follows is only what connecting adds to it.

If you create your account while connecting, we record that it was created from the plugin, so we can count how many accounts the plugin brings in. That record holds the organisation and the date it was created, nothing about you, and is deleted after 180 days.

Each time a tool acts on your account, we record which account and user called which tool, and when. We do not record what you asked the tool, what it answered, or which of your domains it acted on, with four exceptions. When you add a domain through the plugin, we record which account and user added which domain, and when, so we can count how many domains the plugin brings in. When you ask the plugin to verify that your banner is installed, your own machine loads a page of your site and we record which account and user checked which domain, the page's address without its query string, the banner script tag found there, when it was read and whether it counted as installed, which is also what sets that domain's banner status in CookiePal. When you ask the plugin to scan a domain, the crawl runs on your own machine, never on ours, and we record which account and user started a scan of which domain, the address it started from, how many pages it was allowed, how it ended and how many pages and cookies it found. When you ask the plugin to check Google Consent Mode, your own machine loads the page and sends us the page's address without its query string and what it read from Google's consent settings: whether Consent Mode was found, the names of its consent types, which have no default and whether a default was set late; we work out the answer and store only that, as that domain's Consent Mode status in CookiePal, marked as read on your own machine. The page's address and what was read from it are not stored. That status is not one of these records: it is kept with the domain's other settings and deleted with the domain. These records measure how the plugin is used and are deleted after 180 days. The cookie report you upload after a scan is not one of these records: it is stored with that domain's other cookie reports in your account, labelled a local scan, and is kept and deleted with them. It holds each cookie's name, domain, duration, category and description (which may name its vendor), but never its value. When you ask the plugin to change your banner's mode, colours, logo, positions or texts, we save what you chose as that domain's banner settings in your account, exactly as the dashboard does. These are your account's configuration, not one of these records: we do not log what you changed, and they stay in your account until you change them again or delete the domain.

To keep the tool connected, we store a sign-in token for it, in a one-way hashed form we cannot read back. Each one works once and is replaced every time the tool renews its connection. The connection ends 30 days after you approved it, however often it is renewed, or straight away if the tool revokes it; after that you connect again.

Your install ID is linked to your account only if you agree. If you shared one, connecting asks you separately whether to link it, and the default is no. If you agree, we record which account and which user it was connected to, and when. That makes the checks stored under the ID linkable to your account, which is its purpose: it tells us whether checking a page led to an account. The link is deleted 180 days after you last agreed to it (agreeing again on a later connect starts that period again), straight away if you answer no the next time you connect, or with /cookiepal:check-one-page stop-sharing, which also erases those checks.

The plugin runs inside Claude Code, which is Anthropic's product, not ours. Running a check therefore passes through your own Claude Code session: the page address exactly as you gave it, query string included, the page's title, the labels of the banner buttons the check pressed, the host the page redirected to if it did, the cookies found, your install ID if you shared one, and the result. That happens under your own agreement with Anthropic, and CookiePal neither controls it nor receives a copy of your session.

If you use CookiePal as a connector in Claude - on claude.ai, in Claude Desktop or in the Claude mobile apps - your requests reach our server from Anthropic's servers, not from your device. What you say to Claude is handled under your own agreement with Anthropic, and CookiePal neither controls it nor receives a copy of your conversation. Our server receives the same tool calls and keeps the same records described in this notice. Because those requests arrive from Anthropic's addresses, the country recorded for a check is where Anthropic's servers are, not where you are.

Only if you agree, the plain-language read at the end of a check is published as an artifact on claude.ai. The plugin asks you once, before the first time it would publish, and the default is no. Publishing sends that read - the page address, the country the check ran from, the date, every cookie's name, domain, category and vendor, and every third-party host - to Anthropic under your own claude.ai account and their terms.

If you say no, nothing is published. The same read can be written as a local HTML file, as a local Markdown file, or printed straight to your terminal, and those three send it nowhere at all. You can choose the form for a single run, for example /cookiepal:check-one-page https://example.com html, or set one as your default so artifacts are never used.

Whichever form you choose, the read itself is assembled on your machine and no part of producing it reaches CookiePal.

What the plugin keeps on your machine, in its own data folder: while a check runs, the address you gave with its query string, the plan our server issued and the result it returned, each deleted the next time the plugin runs after 30 minutes; the read in every form for your last 20 checks, including the artifact version even if it was never published; the form you prefer; and your install ID if you shared one. Removing the plugin removes all of it.

A stored check is deleted automatically 180 days after it was planned - that is, 180 days from the moment you started the check and our server issued its check ID, not from when the result came back. The two are minutes apart. Deletion is automatic and covers the whole record, including the install ID attached to it.

Call counts for the tools that need no account. So that they cannot be flooded, the server counts how many of them each network calls in a ten-minute window, or, when you are signed in, how many your account calls. The count is stored under a hash of the IP address or of your account ID made with a secret key, so the stored count alone reveals neither, and it names no install or page. It is deleted automatically about an hour after its window ends, and it is never used for anything else.

What connecting an account adds is kept as described above: the record of each tool call, the record of each domain added through the plugin, the record of each banner installation check, the record of each scan and the record of an account created while connecting for 180 days, the link between an install ID and an account for 180 days from when you last agreed to it, and the tool's sign-in tokens for up to 30 days. While you approve a connection, a one-time code is created that works for one minute; it is deleted as soon as it is used, or, if it never is, automatically within about an hour. Automatic deletion runs on our database's own schedule, so any record in this notice can outlast its period by a day or two before it is removed.

We may keep genuinely anonymised aggregate statistics for longer, where what is kept no longer relates to an identifiable person and could not reasonably be used to identify one. Counting alone does not make data anonymous, so this applies only where that test is actually met.

One honest qualification on any deletion, automatic or at your request. Our database keeps continuous encrypted backups so it can be restored after a failure, and those backups run 35 days behind. A record removed from the live store therefore remains inside that backup window until it rolls past, after which no copy is left. We do not use backups to look anything up; they exist only to recover from a disaster.

The controller for the data described here is CookiePal Limited, a company registered in England and Wales under company number 15835702, with its registered address at 10 Orange Street, London WC2H 7DQ, United Kingdom. Because we are established in the United Kingdom, the UK GDPR and the Data Protection Act 2018 apply to our processing, and the EU GDPR applies where we offer the service to people in the EEA. Where this notice refers to the GDPR, both regimes are meant.

For the check itself - the page, the cookies, the hosts, the plugin version and the country - and for the call counts that keep the free tools available, our basis is legitimate interests under Article 6(1)(f) of the GDPR: running the service you asked us to run, keeping it available and secure, and understanding how much it is used. Most of what a check records describes the website being tested rather than the person testing it, and we do not ask for or collect your name, email address, account or IP address as part of one. Some of it may nevertheless be personal data in particular circumstances - a path can contain an identifier - so we treat it with the same care either way.

For the install ID, our basis is your consent under Article 6(1)(a), asked for before anything is created and withdrawable at any time with /cookiepal:check-one-page stop-sharing. Withdrawing it does not make the checks you already submitted unlawful, and the same command erases them anyway.

If you connect an account, linking your install ID to it relies on your consent under Article 6(1)(a), asked when you connect and withdrawable at any time with /cookiepal:check-one-page stop-sharing. Recording how an account was created and which tools are called relies on legitimate interests under Article 6(1)(f): understanding how the plugin is used and whether it does what it is for. Signing in and using your account rely on our contract with you, as described in the main privacy policy.

The service runs on Amazon Web Services in the eu-central-1 region, in Frankfurt, Germany, and AWS is our processor for it. We are established in the United Kingdom, so data is accessed from there, and some supporting activities such as error monitoring and support may involve processing elsewhere; where that happens we rely on an appropriate transfer mechanism. The providers we use are listed on our sub-processors page.

Where we hold personal data about you, the UK GDPR and the EU GDPR give you rights of access, rectification, erasure, restriction, objection and portability. The LGPD in Brazil provides its own set of rights, including confirmation of processing, access, correction, anonymisation or deletion in the circumstances it sets out, and portability. These regimes are not the same as each other, so we have described them separately rather than treating one as a translation of another.

In practice there is very little to exercise them against, and we would rather say so plainly than imply otherwise. A stored check carries no name, no email address and no IP address, and no account unless you linked your install ID to one. If you never shared an install ID, we are unlikely to be able to tell which checks are yours from the information we hold. That is a deliberate design choice, not an evasion. If you give us more information so that we can identify your records, we will use it only to handle your request and then discard it.

If you did share an install ID, that ID is the one handle we have, and /cookiepal:check-one-page stop-sharing uses it to erase every check stored under it before it deletes the ID from your machine. That is the whole deletion, done immediately and by you: nothing has to be asked of us. If the ID has already gone from your machine but you kept a copy, send it to support@cookiepal.io and we will erase anything left under it. Without the ID there is nothing for either of us to search for, so take a copy before you stop sharing if you want one.

If you connected a CookiePal account, the records that connecting adds are tied to that account, so you can exercise your rights over them in the same way as for the rest of your account, by writing to us from its email address. We then erase the records that connecting added, any link between an install ID and your account, and the checks stored under an install ID you linked.

Everything expires by itself in any case: 180 days after it was recorded or, for the link between an install ID and your account, after you last agreed to it. If you think we have handled something badly you can complain to the Information Commissioner's Office, the UK supervisory authority, at ico.org.uk, or to the data protection authority where you live.

We use technical and organisational measures appropriate to the risk. In practice the strongest measure is how little there is to protect: no cookie values and no page content ever reach us, a check carries no account unless you link one, and no IP address is ever stored, so a breach of our store could not expose them.

Concretely: everything travels over TLS; the store is encrypted at rest using Amazon DynamoDB's managed encryption; the server's own permissions are scoped to the operations its tools need - it can write its own records, add a domain to an account and list an account's domains, as the dashboard does, set a domain's banner installation status from a check run on your machine, store the cookie report of a scan run on your machine, change a domain's banner settings and banner texts, as the dashboard does, and look a domain up by name to see whether it is already registered, but it cannot delete an account's records or list the accounts themselves, while its code reads and writes only those of the account a request is signed in with; a check ID can be used once and expires thirty minutes after it is issued; and deletion after 180 days is automatic rather than a task someone has to remember.

Every field in a submitted result is checked against a strict schema before it is stored - types, lengths, allowed values, and no unexpected fields - because it arrives from someone else's machine. That is structural validation; it is what stops a cookie value or an unknown field being stored at all, and we do not claim it as a defence against every possible form of hostile input.

Our operational logs are worth a word of their own, because logging is where services usually keep the data they say they do not keep. The MCP server's logs record runtime diagnostics only - start-up, duration, memory, errors. They contain no IP address, no page address and no check result, request logging at the gateway is switched off rather than merely unused, and the logs are deleted after 14 days. Errors and request timings are also reported to Sentry, our error-monitoring provider, which is listed on the sub-processors page; it is not set up to collect IP addresses or the contents of requests.

If what the plugin sends changes, this notice changes with it, in the same release. The date at the top says when it last changed.

Questions about this notice, or a request about your data, go to support@cookiepal.io, or by post to CookiePal Limited, 10 Orange Street, London WC2H 7DQ, United Kingdom.

This is the same privacy contact that handles requests for the rest of CookiePal, and their details, including a telephone number, are on our data protection contact page. You do not need to say which part of CookiePal your request concerns.