All work
Cookie? No thanks project cover

Cookie? No thanks

A vibe-coded Chrome extension that blocks unwanted cookie prompts.

Chrome Extension DevelopmentPrivacy Tech

1. The Problem

Cookies are small text files saved by websites in a visitor's browser. Since GDPR and related European regulations came into force, websites commonly request permission before using tracking cookies, creating consent popups across much of the web.

Rejecting cookies does not prevent every form of fingerprinting, while necessary cookies still support essential functions such as authentication and shopping carts. Even so, many users prefer to reject optional tracking, and repeating that choice across dozens of websites quickly becomes frustrating.

Cookie? No thanks is a personal vibe-coding project that explores how a browser extension can identify consent interfaces and choose the safest available rejection path automatically.

Cookie consent popup example used during research

2. Research Phase

I began with the Chrome Extensions documentation to understand extension architecture, then analysed the leading competitor I Don't Care About Cookies, which serves more than 900,000 users.

Competitor testing exposed recurring side effects: broken forms, lag, forced acceptance rather than rejection, and unreliable behaviour on more complex consent experiences.

The extension centres on detection.js and decliner.js. Together they handle patterns such as accept-or-pay, accept-or-reject, and accept-or-customise while avoiding functional dialogs such as payments or login forms.

3. Detection Methods

  • Known framework selectors: identifies OneTrust, Cookiebot, Quantcast, TrustArc, Osano, Termly, and Didomi, alongside generic cookie, GDPR, consent-modal, and relevant ARIA patterns.
  • Z-index detection: scans floating div, aside, section, and dialog elements using fixed or sticky positioning and high stacking values.
  • Keyword scanning: targets dialog and container classes or IDs containing explicit cookie and consent terminology.
  • Shared validation: every candidate must be non-structural, visible, at least 200 × 50 pixels, and contain an actionable button.
  • Button classification: reads visible text, aria-label, and title attributes before grouping actions as reject all, necessary only, reject, manage, accept, or pay.

4. Validation Rules

  • Reject structural navigation, headers, main content, generic sidebars, and elements covering more than 85% of the viewport.
  • Ignore elements hidden with display, opacity, or visibility rules unless they have real layout dimensions during an animation.
  • Require a minimum size of 200 × 50 pixels.
  • Require at least one button or element with role=button.
  • Support reject-language variants including decline, no thanks, opt out, essential only, and continue without.

5. What I Learned

The main lesson was understanding the full consent context: the different types of consent dialogs, their structures, and how they interact with the rest of a website. The project reinforced my knowledge as a developer.

The happy path is straightforward; the real work lies in the edge cases discovered through testing on real websites. Some consent popups still can't be blocked safely, and some rules can accidentally select the wrong container, so testing and refinement are still ongoing.

The extension hasn't been published to the Chrome Web Store yet. It costs $5 USD to publish an extension, and I'm quite broke, so I'll leave that for later :D It's still been very helpful to run locally for myself for my MA studies, though, since I have to research and open many new websites every day. In the meantime, the source code is publicly available on GitHub.

Thank you

For taking the time to explore this project.

All projects