Protection you can
actually understand.

Overview

ClickSafe is a Chrome extension that runs a background service worker alongside every page you visit. It doesn't modify how your browser works, and it doesn't slow down your browsing — it quietly observes what's happening on each tab and intervenes only when something deserves your attention.

The extension is built around five distinct jobs: enforcing secure connections, identifying trackers embedded in pages, checking whether links and downloads are dangerous, detecting manipulative UI patterns, and computing a per-tab privacy score that reflects the combined result of all four. Each job is independent — you can toggle any of them off from the Settings page without affecting the others.

When you install ClickSafe, the background service worker starts immediately. It loads a tracker blocklist from a bundled seed file, attempts to fetch an updated list from Disconnect.me's public database, and begins pulling a local copy of Google's Safe Browsing hash prefix data from the ClickSafe backend. By the time you open your first tab, all three systems are ready.

What happens when you open a page

The moment a page loads, ClickSafe's content script is injected into the page's DOM. It runs a mixed-content scan — checking whether any images, scripts, iframes, or stylesheets are being loaded over unencrypted HTTP on an otherwise secure HTTPS page. That result is sent to the background worker, which stores it against the current tab ID.

At the same time, the content script begins scanning every third-party hostname it finds — every <script src>, <img src>, <iframe src>, and <link href>. Each hostname is sent to the background worker, which checks it against the in-memory tracker blocklist. Matches are accumulated and pushed back to the side panel, which updates its tracker count in real time.

None of this involves a network request. The blocklist lives in memory. The mixed-content check reads the DOM directly. Everything happens locally, in milliseconds, with no data leaving your browser.

Real-time Monitoring

ClickSafe monitors three categories of browser activity continuously: the connection security of the pages you visit, the third-party resources those pages load, and the files you download. Each category runs on a different trigger and uses a different mechanism, but they all feed into the same side panel and the same privacy score.

HTTPS enforcement

HTTPS enforcement is handled at the network layer using Chrome's declarativeNetRequest API, which means it runs before your browser even establishes a connection. A ruleset tells Chrome to redirect any http:// request to https:// automatically. This is not a content-script interception — it happens at the browser level, and it applies to navigations, subframe loads, and resource requests alike.

Separately, the content script scans the fully loaded DOM and flags any resources that loaded over HTTP despite the parent page being HTTPS. These are mixed-content resources — a problem because they can be intercepted or tampered with even when the page itself is encrypted. Mixed-content counts are stored per tab and surfaced in the side panel.

Tracker detection

On extension startup, the background worker reads a bundled trackers.json file containing around 178 high-priority tracker domains as a seed. It then attempts to fetch the full Disconnect.me services.json list from GitHub, which covers over 70,000 known tracking domains across advertising, analytics, social, and fingerprinting categories. Once fetched, the full list is cached in chrome.storage.local for 24 hours so it's available immediately on the next browser session without needing another network request.

The loaded list is kept as a JavaScript Set in the background worker's memory — which means hostname lookups are O(1). When the content script sends a hostname to check, the background worker does a single has() call and responds immediately. There's no fuzzy matching, no server call, and no logging of what you checked. Resources from the same origin as the page are skipped entirely — only genuine third-party domains are evaluated.

Download scanning

Download scanning is triggered by Chrome's chrome.downloads.onDeterminingFilename event, which fires before the file is written to disk. When a download begins, the background worker sends the download URL to the ClickSafe backend, which checks it against Google's Safe Browsing database. If the URL is flagged, the download is cancelled and the user sees a warning. If the backend is unreachable, ClickSafe fails closed — the download is cancelled rather than allowed through unchecked.

Threat Detection

Link checking is the most privacy-sensitive feature in ClickSafe, because it involves evaluating URLs you're about to visit. Most browser security extensions solve this by sending every URL you hover over to a remote server — which means a third party sees your entire browsing history, not just the dangerous parts. ClickSafe uses a different approach: a three-tier cascade that keeps your browsing local wherever possible and only contacts the backend when there's an actual reason to.

Tier 1 — Whitelist check

Before any processing happens, ClickSafe checks whether the domain you're about to visit is in your personal whitelist. The whitelist is stored in chrome.storage.local and read entirely locally. If the domain matches — either exactly or as a subdomain of a whitelisted entry — the check stops immediately. Nothing is hashed. Nothing is sent anywhere. The link is marked safe and you navigate normally.

Tier 2 — Local hash prefix lookup

If the domain isn't whitelisted, ClickSafe hashes the full URL using SHA-256 — locally, in the browser — and compares the first four bytes of that hash against a local store of known-threat hash prefixes. This prefix store is fetched from the ClickSafe backend every 30 minutes; the backend in turn retrieves it from Google's Safe Browsing Update API. The store covers four threat categories: malware, social engineering (phishing), unwanted software, and potentially harmful applications.

If no prefix matches, the URL is clean and you proceed. The original URL never left your browser. If there is a match, it doesn't automatically mean the URL is dangerous — hash prefixes are intentionally short, so false positives are possible. That's what tier 3 is for.

Tier 3 — Hash-only server confirmation

When a local prefix match occurs, the background worker sends only the full SHA-256 hash — not the original URL — to the ClickSafe backend. The backend forwards this hash to Google's fullHashes:find endpoint, which returns whether the exact hash appears in the threat database. If the full hash matches, the threat is confirmed and a warning is shown. If it doesn't, it was a false positive and you proceed normally.

The original URL is never transmitted at any tier. In the worst case — a confirmed threat — only a cryptographic hash reaches the backend. There's no way to reconstruct the original URL from a SHA-256 hash, so your browsing history remains private even when server confirmation is required.

If the local prefix store hasn't been populated yet — for example, on the very first launch before the first 30-minute refresh — ClickSafe falls back to sending the full URL to the backend for a direct check. This is the only scenario in which the original URL leaves the browser, and it resolves itself once the prefix store is populated.

Warning System

When a threat is confirmed, ClickSafe shows a modal overlay on the current page. The modal displays the URL that triggered the warning, the threat category returned by Safe Browsing — such as "Phishing / Social Engineering" or "Malware" — and three explicit choices: go back to safety, trust the domain, or proceed anyway. ClickSafe never silently blocks navigation. The decision is always yours.

Why three options

Blocking by default creates friction for false positives and positions the extension as an authority rather than an advisor. Doing nothing is worse. The three-option model treats you as someone capable of making an informed decision once you have the relevant information. "Go back" is the safe default. "Trust this site" adds the domain to your local whitelist so you won't be interrupted again. "Proceed anyway" lets you navigate through the warning with full awareness — useful when you know a site is flagged incorrectly.

Download warnings

Download warnings work differently. Because the check happens before the file is written to disk, the download is cancelled and a notice appears in the side panel. This is intentional: letting a flagged executable reach your filesystem, even with a warning, creates a risk that a UI prompt can't fully mitigate. If you believe the warning is a false positive, you can whitelist the domain and re-attempt the download.

Privacy Layer

Every feature in ClickSafe was designed with a clear data boundary in mind. The question asked during development for each feature was: does this need to leave the browser to work? If the answer was no, it doesn't. If the answer was sometimes, it only leaves the browser in those cases, and only the minimum necessary information is sent.

What stays local

Tracker detection is entirely local. The Disconnect.me list is fetched once per day and cached; all hostname lookups happen against an in-memory set. Cookie scanning reads your browser's cookie store directly using the chrome.cookies API — no cookie data is sent to any server. Mixed content detection reads the DOM. HTTPS enforcement uses declarative browser rules. The whitelist lives in chrome.storage.local on your device. The privacy score is computed locally using numbers that are themselves computed locally.

What touches the backend

Two things reach the ClickSafe backend. First, the hash prefix store is fetched every 30 minutes — this is a one-way pull of public threat data, not a transmission of anything about your browsing. Second, when a local prefix match occurs, a single SHA-256 hash is sent for confirmation. That hash cannot be reverse-engineered into the original URL. No session identifiers, no user IDs, and no analytics are attached to these requests.

What reaches Google

Google Safe Browsing data is accessed exclusively through the ClickSafe backend, which acts as a proxy. Your browser never contacts Google's Safe Browsing API directly. The backend sends hash prefixes and full hashes to Google's API when fetching the prefix store and confirming threats — Google sees the hash data but has no way to associate it with a specific user, since the requests come from the backend server rather than your IP address.

Dark Pattern Detection

Dark patterns are UI techniques designed to manipulate your decisions — to get you to subscribe to something you didn't intend to, accept cookie tracking without a real choice, or buy something under the pressure of a fake countdown. They're widespread, effective, and largely invisible unless you know what to look for. ClickSafe's dark pattern detector scans the live DOM and makes them visible.

What gets flagged

The detector checks for five categories. Fake urgency covers text patterns like "only 2 left", "act now", "selling fast", and "last chance" — language engineered to short-circuit deliberate decision-making by implying artificial scarcity or time pressure. Confirm shaming targets opt-out copy that makes declining feel like a personal failing, such as "No thanks, I hate saving money" — a pattern common in email subscription prompts and pop-up banners.

Fake countdown timers are identified by scanning the DOM for elements whose class or ID contains words like countdown, timer, or time-left, combined with checking whether those elements contain visible digit characters. Pre-ticked checkboxes are caught by finding <input type="checkbox"> elements that are checked by default and whose associated label text contains marketing keywords like "newsletter", "promotional", or "subscribe" — the classic mechanism for opting you into communications you didn't request.

Cookie banner manipulation is flagged when a consent banner contains a clearly visible "Accept" button but no equivalent "Reject" or "Decline" option. This is one of the most common dark patterns on the modern web, exploiting the fact that most users click the first available option rather than searching for a way to say no.

How detection works

The scan runs twice: once immediately at page load, and again 2.5 seconds later to catch elements injected dynamically by JavaScript after the initial render. Detected elements are highlighted with a subtle visual indicator directly on the page — not a popup, not a modal, just an inline tint and tooltip so you can see exactly which element was flagged and why. The total count of detected patterns is reflected in the privacy score and surfaced in the side panel. The feature can be toggled off entirely in Settings if you prefer not to use it.

Privacy Score

Every page you visit receives a privacy score between 0 and 100. The score is computed by the background service worker after all asynchronous scans settle — there's a 1.5-second debounce to ensure that tracker counts, cookie data, and mixed-content results are all available before the final number is produced. The score drives the animated ring in the side panel and determines whether an in-page privacy banner is shown.

How the score is calculated

The formula starts at 100 and subtracts deductions based on what was found. Serving the page over HTTP rather than HTTPS deducts 30 points — the single largest penalty, because unencrypted connections expose everything you send and receive on that page. Each tracking cookie detected deducts 5 points, capped at a maximum of 30. Each tracker script or resource deducts 4 points, capped at 20. Each mixed-content resource deducts 5 points, capped at 20. The final score is clamped between 0 and 100.

A score between 80 and 100 puts the page in good standing — the side panel ring is green and no banner is shown. A score between 50 and 79 indicates moderate risk, shown with an orange ring. A score below 50 is high risk — the ring turns red and an in-page privacy banner appears at the top of the page identifying the primary reason for the low score, whether that's an insecure connection, heavy tracking, or both.

What the score is and isn't

The score is a snapshot — a summary of the privacy conditions on that specific page at the time of load. It's not a rating of the company that owns the site, and it's not a security certification. A site can score 100 and still have poor privacy practices that aren't detectable from the DOM. What the score does well is give you an immediate, comparable signal across pages: you can open two competing news sites and see, at a glance, which one loads fewer trackers and respects your connection security.