Cookie Consent Behaviour Checker That Tests What a Site Does After You Click Reject

The problem: a reject button that does nothing

Cookie banners are everywhere, on sites for European users because of the GDPR and ePrivacy rules, and increasingly elsewhere as more countries pass data protection laws. A user who clicks "reject all" expects analytics and advertising trackers to stay off. On many sites they do not. Tag managers load scripts before the banner appears, consent platforms are configured wrongly, or a developer adds a new marketing pixel without wiring it to the consent state.

Developers often do not know this is happening. Their own browser has accepted the banner long ago, and nobody tests the reject path. Regulators and journalists who want to check need hours per site. Users, meanwhile, learn to click "accept" because rejecting seems to make no difference, which defeats the point of asking at all.

What already exists and the gap

• Consent management platforms such as Cookiebot, OneTrust and Usercentrics run scanners that list the cookies a site sets, mainly to build the banner text. They do not focus on proving that a reject choice is respected.
• Browser privacy tools such as uBlock Origin and Privacy Badger block trackers for one user. They do not report on the site.
• Academic crawlers such as OpenWPM support large measurement studies, but they are research infrastructure, not a tool a developer can run on their own site before a release.

The gap is a focused checker that compares behaviour across "no choice", "accept" and "reject", names the scripts that misbehave, and fits into a developer's workflow.

Inspiration

"Do Cookie Banners Respect my Choice?" by Matte, Bielova and Santos (IEEE Symposium on Security and Privacy 2020) crawled European websites using IAB Europe's Transparency and Consent Framework and found sites that stored positive consent before the user chose, or even after the user opted out. Your project turns that measurement method into a reusable tool, adds network-level evidence, and makes it easy to run on any site, including sites outside Europe.

What you build

• Developers run the checker on their staging site and get a list of scripts that fire after reject, with the exact request and the tag that loaded it.
• Privacy teams and auditors run it across a portfolio of sites and get a table of failures.
• Researchers and journalists use the crawl mode to measure compliance across hundreds of sites, with results they can reproduce.

The technically interesting part

• Finding the banner. Banners are built in many ways: iframes, shadow DOM, delayed pop-ups, many languages. Combine known consent platform selectors with text matching in several languages, and measure how often your detector finds the right button.
• Clean, fair comparison. Each mode needs a fresh profile, the same location and the same wait time. Pages that load content forever need a sensible stopping rule.
• Attribution. A tracking request may be triggered by a tag manager that loaded another script that loaded the pixel. Use the DevTools initiator chain to show the full path, so developers know which tag to fix.
• Reading consent strings. Decode TCF strings stored in cookies and compare them with the user's actual choice.
• Avoiding false alarms. Some third-party requests are strictly necessary, such as a payment provider or a content delivery network. Keep an allow list and show your reasoning.

How to evaluate it

• Banner detection rate on a hand-checked sample of 100 sites, with failure reasons.
• Accuracy of "ignored reject" findings, checked by hand on 50 flagged sites.
• Speed: time per site for all three modes, so teams know whether a weekly portfolio check is realistic.
• Reproducibility: run the same crawl twice a week apart and compare results.
• Developer test: give the report for their own site to two developers and record whether they could find and fix the cause.

Suggested plan

• Weeks 1 to 3: read the paper, try OpenWPM, collect 50 sites with different consent platforms.
• Weeks 4 to 7: banner detection and the three crawl modes.
• Weeks 8 to 10: recording, tracker classification and TCF decoding.
• Weeks 11 to 13: per-site reports, CI mode and the 300-site crawl.
• Weeks 14 to 15: evaluation, write-up and demo.

Path to a product

Agencies and in-house teams need evidence that their consent setup works before a regulator or a journalist checks. A hosted checker that runs weekly and alerts on new trackers is an easy subscription to explain. The crawl results are also publishable, and privacy engineering is a growing career path.

Scope warning

You are building a measurement tool, not giving legal advice. Report what the browser observed and avoid labelling a site as breaking a specific law. Respect robots rules and rate limits when crawling, and keep the first version to one or two consent platforms you understand well before generalising.

Learn what you need on Sefism

• Cybersecurity roadmap: web privacy, tracking and how browsers isolate data.
• Frontend development roadmap: how scripts, cookies and storage work in the browser.
• Playwright Documentation: clean browser profiles and network capture.
• MDN: HTTP: cookies, headers and third-party requests.
• OWASP Cheat Sheet Series: practical guidance on cookies and client-side security.

Get help with this idea

The risk is a banner detector that only works on a handful of sites, or findings that are hard to defend. Tauseef can help you scope the first consent platforms, design the hand-checked samples and present the results carefully. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session