CookiePal Logo
CookiePal Logo
Log in

CookiePal plugin - Privacy Notice

Privacy Notice

Last updated: October 5, 2026

This privacy notice covers the CookiePal plugin and the CookiePal MCP server at mcp.cookiepal.io only. For the privacy policy that covers cookiepal.io and the main CookiePal product, see our main privacy policy.

Table of contents

back

to the top

The CookiePal plugin checks a single web page for the cookies and trackers that are set before anyone has given consent, and for what the page's consent banner actually does when you accept or reject. It needs no account. This notice explains exactly what leaves your machine when you run a check, what never does, and why.

Summary

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 the banner's accept and reject buttons changed, and a random install ID if you agreed to share one. Nothing else.

We do not store your IP address, we never receive a cookie value, and there is no account to tie any of it to.

What a check sends to CookiePal

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 used for that one lookup and is not stored. 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 be pressed, and for each one the cookies that appeared or disappeared and the third-party hosts that were newly contacted. These are the same kinds of record as above, and cookie values are left out of them too.

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

What never leaves your machine

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.

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.

The install ID

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 though it is not linked to a name or an account, so we treat it as such. It is used to count unique installs and for nothing else: not for profiling, not for advertising, and never shared with anyone.

To stop sharing it and delete it from your machine, run /cookiepal:check stop-sharing. Withdrawing consent stops any further collection or use of the ID. It does not make the processing that happened before you withdrew unlawful, and checks you have already submitted keep the ID they were sent with until they expire at 180 days. You can ask us to delete those sooner.

Claude Code, and where your result goes

The plugin runs inside Claude Code, which is Anthropic's product, not ours. The page address, the cookies found and the result therefore pass through your own Claude Code session as part of running the check. That happens under your own agreement with Anthropic, and CookiePal neither controls it nor receives a copy of your session.

By default, the plain-language read at the end of a check is published as an artifact on claude.ai, which sends that read - including the page address and the list of cookies - to Anthropic under your own claude.ai account and their terms.

You do not have to use it. 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 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.

How long we keep 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.

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.

Who we are, and our lawful basis

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 - 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 stop-sharing. Withdrawing it does not affect checks already submitted, but you can ask us to delete those too.

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.

Your rights, and asking for deletion

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 account, no name, no email address and no IP address. 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. Send it to us at support@cookiepal.io and we will handle your request. At present we do this by hand, and we are building the tooling to make it routine, so allow us the month the GDPR provides rather than expecting it the same day. Running /cookiepal:check stop-sharing deletes the ID from your machine, so copy it before you do, or we will have nothing to search for.

Everything expires by itself after 180 days in any case. 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.

How we protect it

We use technical and organisational measures appropriate to the risk. In practice the strongest measure is how little there is to protect: no account, no cookie values and no page content ever reach us, 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 few operations it needs, so it cannot read other CookiePal data even if it were compromised; 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.

Changes to this notice

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. Material changes are noted in the plugin's release notes, so an update tells you rather than leaving you to re-read this page.

Contact

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.

Any Questions Left?

Feel free to contact us and we will answer all of yours remaining questions!

Contact Us

Elevate Your Compliance with
CookiePal Today

View PlansTry for FREE

Privacy made simple!

Powered by WESTPOINT

© CookiePal 2026. All rights reserved. CookiePal Limited is registered in the UK. Company no. 15835702.

Terms and ConditionsPrivacy PolicyGet in Touch