Why I built Refuse to Share

Cookie banners interrupt almost every part of everyday browsing. Accepting everything is usually easy, while rejecting non-essential cookies can require opening a settings panel, identifying optional categories, disabling them and saving the choice.

I created Refuse to Share to make that process less frustrating without replacing one bad choice with another.

The goal is simple: reject non-essential cookies automatically when the extension can identify a clear and legitimate rejection path. When the available choices are ambiguous, Refuse to Share deliberately avoids risky clicks.

What it does

Refuse to Share can:

  • detect supported cookie-consent banners;
  • use a direct “Reject” or “Reject all” option when one is safely identifiable;
  • open consent preferences when additional steps are required;
  • disable optional categories whose state can be verified;
  • save the resulting preferences;
  • check whether the banner has actually been dismissed;
  • preserve the user’s choice when the consent platform supports persistence;
  • abstain when it cannot determine the safe action with enough confidence.

The extension is designed to avoid accidental acceptance and false success messages. A cautious non-action is preferable to clicking an ambiguous control that could enable optional tracking.

Privacy by design

Refuse to Share works locally in the browser.

It does not require an account and does not collect, sell or transmit browsing data. It does not use analytics or remote code. Its functionality is implemented inside the extension using the browser’s own extension APIs.

How I built it

Refuse to Share is a Manifest V3 Chrome extension built with JavaScript, HTML and CSS.

Content scripts examine dynamically rendered consent interfaces and look for sufficiently specific structural, textual and accessibility signals. The extension uses rules and adapters for different Consent Management Platforms instead of relying on broad keyword matching.

A background service worker coordinates extension state, while preferences are stored locally through Chrome’s storage APIs. Dynamic interfaces are handled through controlled DOM observation so the extension can react to banners that appear after the initial page load.

The system is intentionally conservative: identifying a button is not enough. The surrounding consent interface, the meaning of the action and the result after interaction must also be consistent.

The main challenges

The hardest part was not clicking buttons—it was determining when a click was genuinely safe.

Cookie banners differ across websites, languages and Consent Management Platforms. Some appear immediately, while others are rendered later. Some require multiple steps, use nested interfaces, replace parts of the DOM dynamically or store consent in different ways.

Another challenge was balancing compatibility with safety. Broad text matching might close more banners, but it could also click “Accept,” leave optional categories enabled or claim success without changing the consent state.

Refuse to Share therefore favors specific signals, post-action verification and CMP-aware behavior over aggressive automation.

What I learned

Building the extension showed me that privacy automation needs a different definition of success.

Closing a banner is not enough. The tool must understand what action it performed, verify the resulting consent state when possible and remain honest when it cannot safely complete the process.

I also learned how important local-first architecture, controlled DOM observation, regression testing and strict performance limits are for an extension that runs across many websites.

What’s next

The next steps are to:

  • expand compatibility across more consent platforms and languages;
  • improve support for delayed and multi-stage consent interfaces;
  • strengthen post-action and persistence verification;
  • test the extension across a wider variety of real websites;
  • keep the extension lightweight, transparent and privacy-preserving.

Refuse to Share will continue to prioritize safe rejection over inflated compatibility numbers.

Built With

Share this project:

Updates