One extension. Every defence.
Blocks scams, password theft, dodgy downloads, trackers, fingerprinting, pop-ups and forced redirects. It keeps an eye on your other extensions too. And it all runs on your device.
No WardenOne backend · Entirely open source · Local-first by design
There's no account and no analytics. Your browsing doesn't go through any server of mine (I don't have one). Public-list and update checks contact their named sources; optional reputation checks run only if you turn them on. The privacy policy explains exactly what each sends.
Warning
Official builds only. WardenOne is a browser extension, never an .exe, installer or setup program. Download it only from github.com/iri-dev/WardenOne. If you received another copy, read the impersonation incident notice.
107 individually controllable · 3 watch-only
Three of them are watch-only: Background Reports, Hardware & File Access and Browser Capabilities. They write down what happened. They don't block anything so there's nothing for a switch to turn off.
WardenOne works across the network, pages, downloads, storage and your other extensions. Not just the page you're looking at. And when it blocks something it shows you why.
Site comparisons use a bundled Public Suffix List so separately registered sites under
suffixes such as or.jp and k12.ca.us stay separate. Known shared-hosting tenants also
keep separate identities; the background worker uses the complete private suffix list.
Page guards run on Google Docs and Drive content and non-login pages on the supported identity-provider domains. Authentication routes keep their compatibility exemptions. On these hosted apps, fingerprint noise, overlay removal and automatic consent handling stay paused while phishing, ClickFix, skimmer, form-trap and fake-update checks remain available.
Custom cosmetic rules are checked individually in the browser, so one invalid selector
does not disable the other rules. Unsupported procedural list operators are reported as
skipped; native CSS selectors such as :has() remain available.
Inspect it for yourself: Privacy policy · Permissions explained · Security policy · Source · Licence
The main popup. Master switch, current-site summary, protection health and search. Settings and section arrangement are in the top-right. Click any image to see it full size.
Explore the features
- Security: scam and phishing warnings, password and session guards, Download Shield, File Shield, and checks on your other extensions.
- Privacy: tracker and cookie controls, link cleaning, IP-logger protection, and optional anti-fingerprinting.
- Content blocking: AdShield for ordinary pages and dedicated handling for YouTube, Twitch, and Spotify, plus search cleanup and Element Zapper.
- Control and verification: pause one site, adjust a protection there, inspect Activity and network requests, write your own rules, and check Protection Health or run the Self-Test.
- Tools and comfort: Memory Shield, EyeShield, keyboard and right-click tools, and optional Resource Saver controls to pause GIFs, stop muted video previews, or disable WebGL on selected sites or everywhere except allowed sites.
- Settings and popup layout: a separate searchable Settings page for switches, site exceptions, notifications, backup, and rearranging the popup's sections.
The popup and Settings captures use the current build. Some other feature screenshots come from earlier builds and may place controls differently.
- Download WardenOne-latest.zip and unzip it somewhere you intend to keep it.
- Open
chrome://extensionsand enable Developer mode in the top-right. - Select Load unpacked, then choose the unzipped folder containing
manifest.json.
Please leave Developer mode on afterwards. WardenOne isn't on the Web Store, so Chrome counts it as an unpacked extension and switches it off the moment Developer mode goes off. It then stops protecting you, even after a restart, until you turn Developer mode back on.
The About page in Settings shows both the version and the GitHub build ID. Include both when reporting a problem; the version stays the same between rolling builds.
Pick Recommended for the core security baseline. Maximum Privacy adds fingerprint noise, fraud and bot-check script blocking, first-party tracker blocking, breach and clipboard checks, WebRTC hardening, and header/link protections. These can affect calls, screen sharing, graphics, sign-ins or purchases. Choosing Recommended again preserves advanced choices you already enabled; use the individual switches in Settings to undo them.
Then pick Normal notifications or Silent mode. Silent mode still protects you, it just hides the routine pop-ups and badges. Everything's still in the Notification Centre if you want to look.
The on-page badge opens a compact list of triggered rules, with their IDs and site-specific controls. Rule names open matching settings; a closed lock pauses a supported control on this site, including YouTube ad blocking. The open lock restores it, including after reload. Its count includes available browser network matches and fades back to a hint after its brief highlight. Observations are separate from blocks; Activity holds the site's history. When network counts are unavailable, the badge marks the count as partial rather than claiming nothing was blocked. Its panel and corner badge follow WardenOne's Light, Dark or System appearance choice, including changes made while a page is open.
The final setup step links Settings and section arrangement, and has a searchable guide to every protection, popup control and tool. Open a group or search for something like GIFs, WebGL, Zapper or backup to read what it does, see its fresh-install default, and find its controls.
The full feature guide is searchable, with explanations, default labels and links to the controls.
See the complete first-run journey
Updating an unpacked installation
The ZIP gets rebuilt every time I push something that passes the tests. But an unpacked extension does not update itself from GitHub so you have to do it yourself:
- Export a settings backup from WardenOne before a major update.
- Download and unzip the newest build.
- Keep your installed WardenOne folder at the same path and replace its contents with the new build.
- Open
chrome://extensionsand press Reload on WardenOne.
Keep the folder in the same place. If the path changes Chromium can treat it as a whole different extension and your settings won't come with it.
The popup checks WardenOne's own GitHub build when you open it. If GitHub confirms that your installed build is an ancestor of the latest complete release, a small update notice appears near the top of the popup. Open Settings → About WardenOne to compare the build IDs, check again, and follow the update steps. The check uses build commits because the extension version stays the same between rolling builds. A source checkout without a packaged build ID, a Store build, a failed check, or a build from a different history is never called outdated. GitHub sees the normal request from your IP address; the commit comparison also sends your public build ID, not your browsing history or the site you are visiting. Results are reused for up to six hours while the browser stays open. WardenOne does not install updates for you.
Compatibility: Chrome, Brave, Edge, Opera and other Chromium-based browsers. Minimum supported Chromium version: 121.
Staying safe online usually means installing an ad blocker and an anti-tracker and a fingerprinting tool and a pop-up blocker and a download scanner... and then hoping they all get along. I wanted one extension that just does all of it together. Plus the things content blockers usually skip, like phishing and password theft protection, checking your other extensions, and being able to see whether any of it is working.
A few rules I've stuck to while building it:
- If WardenOne finds nothing it says it found nothing. It won't say "safe".
- If something fails (a rule it can't apply, a missing part, a verdict it isn't sure about) you get to see that. It doesn't get quietly ignored.
- If a protection breaks a site you can back off a little at a time. Pause that site, turn off one protection there, undo one firewall rule. You shouldn't have to turn everything off.
If WardenOne doesn't know, it says it doesn't know.
A file with nothing weird in its structure doesn't get called harmless. An extension that isn't in the local catalogue doesn't get called trusted. Search results never get a green tick just because nothing matched. And if a privacy check can't really be measured it says untestable, not passed.
WardenOne also doesn't promise to be invisible. Some protections have to run inside the page
itself and a page that goes looking can spot them (a few named globals, the warnings it draws,
the events it uses to talk to itself). Renaming them wouldn't make anyone safer. So instead every
single one is written down with the reason it exists, and tools/test-detectability-budget.js
fails if a new one sneaks in. A page that finds them doesn't really gain anything either. Anything
from the page that leads to a real decision has to be signed with a key the page never had. And
the protections that really matter run where the page can't reach them.
Warden is the job. Keep watch over the browser and step in when there's actual evidence something's wrong, without pretending to know more than it does.
One is about how it's built. It's not an ad blocker sat next to a separate phishing tool and a privacy tool and a download scanner. Everything shares what it knows. A dodgy redirect can feed into a scam warning. A download can use the reputation of the page it came from. And when a site breaks you can trace it back through the same activity log that made the decision.
It does not mean one extension can stop everything bad on the internet. Nothing can promise that and I'm not going to pretend this one can.
A lot of scams don't look anything like malware. Some steal passwords. Some pretend to be your browser. Some abuse permissions or redirects or the clipboard. They all work differently so WardenOne handles them separately.
Known malware, phishing and scam sites get blocked at the network level before the page even loads. WardenOne ships with built-in rules and can grab fresh vetted feeds every day. Tens of thousands of domains are stored locally and the upstream feeds cover millions.
If an update fails the last working copy stays put, so there's no gap. And the update only downloads a public list file. Nothing about your history or the page you're on goes with it.
Expand Domains by source beneath the popup's blocklist total to see each downloaded feed, built-in list and locally learned contribution. Each source shows its full domain count, with its contribution to the unique total underneath. Lists overlap, so their full sizes are not added together. Individual source counts become available after the next blocklist update.
ThreatView's malicious domains join those downloaded malware lists and follow the malware switch and site pauses. Its ThreatView row shows the full accepted list size and its contribution after overlap. Source and usage notes.
1Hosts Lite adds ad and tracker domains through AdShield. It follows the AdShield switch and appears by name in the same source breakdown, with overlapping addresses counted once.
Catches g00gle-style swaps, brand names on the wrong domain ending and international characters
that look like a familiar name. It looks at the brand text, password forms, who owns the
site etc all together. Just mentioning a company isn't enough to get a page flagged.
There's also an optional login-page age check. It looks for a password form on a domain that was registered really recently. When it's on, a sign-in page offers a Check domain age button. Only pressing it sends the domain to RDAP or your enabled WhoisXML service, without the path, page contents or anything you typed. The answer is cached locally.
The clearest look-alikes get a blocking screen with a choice to leave, visit the real site or continue. Behavioural detection can warn about an unknown site that acts like a tracker or scam even when no list knows it. Risky-site mode applies stricter checks to third-party scripts, frames, media and background calls on suspicious-looking domains.
Find it: WardenOne → Advanced detection.
You get a warning when you click into a password box on an unencrypted page. Before you've typed anything. It also catches the sneakier version where the page is HTTPS but the form sends your password over plain HTTP anyway. Router logins and other local network stuff is left alone. And if there's a secure version of the page the warning offers you that instead.
You click Sign in with Microsoft. A Microsoft window pops up with a title bar, an address bar and a close button. Looks real. Except no window ever opened. The site drew the whole thing inside its own page, and the password box belongs to the site.
WardenOne warns when it sees all of it together: something shaped like a window, showing a domain the page doesn't own, with somewhere to type a password. A normal login pop-up isn't treated as fake just for being a pop-up. Online code editors, design tools and media players are excluded too.
Why it doesn't flag everything that looks like a window
Looking like a window doesn't mean much by itself. WardenOne checks for fake browser bits (title bar, address bar, buttons), text naming some other domain, somewhere to enter credentials and whether the identity it shows matches the real site. It doesn't go off a screenshot or one CSS class. So a mock browser in someone's docs stays quiet but a fake sign-in window asking for your password trips a bunch of signals at once.
In full screen the real address bar disappears. A malicious page can then draw a fake one at the top and ask for your password, and the one thing that tells you where you actually are is gone. WardenOne warns when a full-screen page shows a domain it doesn't own next to a password field (or something similar) and offers to get you out of full screen. Video, games, slideshows and maps are left alone unless the spoofing signs are there.
ClickFix scams get you to install the malware yourself. The page tells you to "prove you are
human", then press Win+R and paste a command. Or open DevTools and type something it prepared.
WardenOne recognises those instructions and stops the page quietly putting a suspicious command on
your clipboard. It warns you if you copy something dangerous yourself too. And it treats it as
more serious when the instructions and the command turn up together.
It can't read Chrome's own DevTools window. It works on the page and the clipboard writes the page makes, and steps in before the command leaves the page.
Where it looks. Reading the instructions (the fake CAPTCHA wording, the "press Win+R" steps) runs on the top-level page only. Embedded frames get the clipboard half. If a frame tries to put a command-shaped string on your clipboard the write gets refused and the same warning shows over the page, but the frame's text isn't read. Two things aren't checked at all, so no warning means nothing for those: instructions drawn as an image or on a canvas, and anything inside a closed shadow tree (no extension can read those). If a scam puts its instructions in a screenshot WardenOne only stops it if it also tries to copy the command for you.
A test page doing the ClickFix trick and the warning WardenOne puts over it. It names the trick instead of just saying "blocked".
Real Chrome or Windows updates don't come from random web pages. Fake Update Detection looks for a page pretending to be a software company while pushing an installer or a button that sends you off somewhere else.
Tech-support Scam Guard handles the other classic. "Your computer is infected", a phone number to call, and a flood of pop-ups meant to lock up your browser. It breaks the lock so you can leave, and tells you it's the page doing this. Not your computer.
Some pages try to talk you into pressing Allow on notifications. Fake CAPTCHAs, fake download steps, made up security warnings, that kind of thing. WardenOne catches it while it's happening. The wording gets checked locally and thrown away and only the type of event goes into the Activity Centre. One limit though: a push notification sent later by a service worker happens outside the page, where this can't see it.
This watches values coming in from the URL, window.name, postMessage or the referrer and checks
if they end up somewhere code actually runs. It records where the value came from and where it
went and how serious it looks. Not the value itself.
It's a record of behaviour. It's not a promise that WardenOne finds every cross-site scripting bug (it won't). Findings that come from the page stay as warnings and can't quietly turn into a blocking rule.
Before a click that matters (signing in, paying, sending money, approving access, installing something) WardenOne checks whether the thing you're clicking is hidden or covered or not what it looks like. Normal visible buttons are left alone. It's only there to catch an important click landing somewhere you can't see.
The Guard Active badge lists triggered rules, event IDs and their counts. A closed lock pauses the
responsible protection for this site when there is one supported control; the open lock restores it. Reload is a
separate action. Shared or ambiguous events open the matching Options search instead.
Page-only exceptions say when network protection still applies. Paused rules remain in the badge
after reload, and the popup marks affected global switches with an Off on this site notice
and a restore button. YouTube applies its page-engine choice on reload to keep player requests
and responses in the same mode. Options and popup search also accept exact IDs
such as cookie_blocked and blocked_thirdparty_cookie.
If an extension update disconnects an open page, the badge offers Reload to reconnect.
Recorded beacons and tracker requests show their event ID and destination domains in the badge.
New beacons briefly brighten the corner badge with a beacon count. Opening it shows already
recorded details immediately; network totals and saved-rule controls load independently.
Each beacon destination has a site-specific Block or Unblock choice and a recommendation.
Choices persist across reloads and browser restarts; Saved blocks opens the firewall's Beacon
column to review or remove them. Beacon rules cover background beacon and link-ping requests,
while ordinary API requests stay separate. Unblocking removes this rule's block; other protections
still apply. Recorded events stay separate from confirmed blocks, and payloads are never shown.
On YouTube hosts, the pause also lets the player's Google ad-service requests load.
Restoring removes those exceptions; malicious-resource rules keep their higher priority.
Forced pop-ups and pop-unders. Ad tabs that open on a timer. Redirects you never clicked, CPA chains, meta-refresh bounces, download pages hidden behind ads, fake confirm boxes, frames that steal your click and send it somewhere else. They're all related but each one gets handled on its own.
If a clearly labeled download link opens an unrelated ad tab instead, WardenOne closes
the ad and opens the link you pressed when the intended tab did not open on its own. It follows
the link shown by the page; it cannot verify a file host hidden behind later redirects.
This also covers “Click Here” links beneath a nearby Download Links or Download Mirrors heading.
Visible URL links followed immediately by an archive filename qualify too. A recently pressed
download link can stop a cancellable script redirect to a different site before navigation starts.
If the page swaps a new-tab download link during the click, WardenOne cancels it and opens only
the address captured when you pressed it. Recovery opens that host page once and removes its opener.
This covers same-tab and same-site download links, keyboard and touch activation, and native or
ARIA buttons that declare a URL in data-url, data-href, data-link or data-download-url.
It does not execute a button's JavaScript to guess where it goes, and conflicting URLs remain uncertain.
Once the intended tab opens, its redirects remain subject to normal threat checks without being
mistaken for a separate ad tab. Following the intended link does not establish that its file is safe.
When the redirect-chain detector displays its warning, supported browsers cancel the relay’s
automatic navigation. Dismissing the warning keeps that stop active. “Resume page redirects”
is an explicit override for the current document. Unsupported browsers show a detection warning
without claiming that native navigation was stopped. The reported deceptive-download host
whuw8g.site and its subdomains have a separate native request rule, controlled by malicious-site
protection. The fake-ad warning offers a return to the original page or source tab and
explains how to try the original download button again. If that source is unavailable,
it keeps the warning open with manual instructions. These protections do not verify the
contents of a file.
After the current page has had a popup or redirect blocked, a download button that hides its destination requires a one-time review before a cross-site popup or cancellable script navigation opens it. The review shows the destination and states that neither it nor its files have been verified. This applies to that document; it does not label an entire site as malicious. Forms, sign-in flows and pages without that blocked-action evidence retain their normal behavior.
Auto-skip download ads follows a continuation only after you click a visible download link and the gate identifies that same destination. Loading a sponsor offer does not start a download. Gates with an uncertain continuation stay under your control.
You can remove overlays on the page and there's an Undo chip if you change your mind. It tries to leave real payment forms, CAPTCHAs, logins and media controls alone. If WardenOne stops a jump right after a real click you get its warning page with a Continue button. Only the guard that stopped the jump can open that page, so a script on the site can't sneak its own destination in behind it.
Back-button protection stops pages that keep re-adding themselves to your history or stacking up entries or shoving you forward again. It never deletes your history or navigates for you. History changes right after a normal click or keypress are trusted (that's what keeps galleries and single-page apps working).
Why bounce cleanup is so careful
When a tracker sits in a redirect between the site you left and the one you land on, it briefly counts as first party. That gives it a moment to store things that third-party cookie blocking can't touch. WardenOne already knows the redirect chain so it can clean up what a known tracker left behind.
I'm deliberately careful here. It only clears a hop if you actually passed through it, it's already on a blocking list, and it doesn't look like part of a login or payment. The page you asked for, the page you ended up on and anything ambiguous are left alone. Missing a tracker is fine. Breaking someone's sign-in halfway through isn't.
When WardenOne stops a page it tells you why.
PROTECTION SUITE · LOGIN & SESSION SECURITY
What it does: protects everything that matters once you're logged in. Session tokens, cookies, password and card fields, OAuth grants, the clipboard, anywhere a site keeps your identity. It never records or shows a full token, password or card number.
Each part has its own switch. Protecting a token and spotting a card skimmer and warning about a risky paste are different jobs and they can each break different sites.
Find it: WardenOne → SessionShield — login & session protection.
SessionShield looks for token-like values sitting in URLs, cookies and any storage scripts can read. It keeps watching after you log in, not just on page load. Token Guard then checks the page's request APIs (and its frames) for those exact values and blocks a call it sees sending one to an unrelated domain.
Player URLs supplied in API or playlist responses can carry service-issued identifiers, including Bilibili's video URLs. Token Guard recognises that response evidence while still checking request bodies and headers. Watching a video still tells its provider your IP address and which video you request.
Hostile page code can get around those page-level hooks. The browser's network rules are separate though and still block the destinations they cover.
Services that are known to be noisy get logged more quietly, without weakening anything. And the token itself never gets copied into the Activity Centre. Not even to explain what was caught.
A third-party script reading your password or card fields is suspicious. That value then getting sent off to another site is a lot more suspicious. WardenOne watches for both and can block matching requests, including forms and requests inside embedded frames (which is where loads of hosted payment fields live).
It follows where the value actually goes. It doesn't treat every third-party script on a checkout page as malware, because real payment processors and sign-in providers need to read their own fields.
Warns you before your card details go to a checkout that looks like a scam, is really new or has a bad reputation. Forms that are insecure, on a look-alike domain, on a raw IP or known to be dangerous get blocked from submitting.
Embedded frames get a lighter check that only watches for card details being sent away. The full checks run on the top page because that's where the site's identity actually means something.
A page can hide username or password fields where you can't see them and wait for your browser or password manager to fill them in. WardenOne looks for credential fields that got autofilled when there's no visible login form to explain them. A normal login that fills its visible fields plus a hidden helper field won't set it off. It needs both. Hidden fields getting filled and no visible login.
Warns you before you paste a password, API token, private key or seed phrase into an insecure page, a look-alike domain or a form that sends it somewhere else. Normal secure logins don't trigger it.
Stops a site from quietly replacing what you copied. Like swapping a crypto address for the attacker's.
A second check when you paste. If the address you copied and the one you're pasting are the same currency but don't match, it shows you both so you can compare. That can even catch malware doing the swap outside the browser. Neither address gets sent anywhere.
A Google, Microsoft, GitHub, Discord, Apple, Meta, Spotify, Slack, Dropbox, GitLab, Atlassian, LinkedIn or Twitch consent page can hand over way more than a simple sign-in. WardenOne warns when an app asks for your mail, contacts, repos, admin rights or long-lived offline access, or when the redirect looks off. It doesn't block OAuth just because of the brand. It looks at what's being asked for and where it's going.
Experimental. It plants fake secret names in the page (only ones the site isn't already using). Normal site code has no reason to know they exist so a script that reads one is probably hunting for credentials. If the page turns out to have a real property with the same name the decoy gets out of the way.
Warns when a page attaches a really large number of global key listeners. Rich text editors and chat apps can do that legitimately too, so it's noisy and it's off by default. It's not a reliable keylogger detector and I'm not going to pretend it is.
The site history tool can ask Have I Been Pwned if a domain shows up in public breach records. The password check is separate. It hashes your password locally, sends only the first five characters of the hash and gets back a big list of possible matches to compare against. WardenOne doesn't read passwords from website fields, doesn't save the answer and never sends the password or the full hash.
Both are optional and obviously both leave your device. They only run when you ask.
The current site gets an A–F grade based on its connection, exposed JWTs, how it stores tokens and its cookie settings. It's something to look into. It's not a guarantee your account can't be compromised.
If you think an account's already been compromised, Emergency Logout clears the cookies and session data for this site or signs you out everywhere. In one go. It's kept separate from the normal privacy cleaning because it's for emergencies, not tidying up.
Each protection above has its own switch.
AUTOMATIC PROTECTION · DOWNLOAD CONTEXT & REPUTATION
What it does: checks downloads in the background and interrupts when meaningful threat evidence needs your attention.
Off by default, with its own toggle in Download checks. Enable it explicitly to check download intent. This is protection 110. It checks how a download started, independently of Download Shield's file-safety checks, using local information. Upgrading from a version that enabled it automatically switches it off once. A later explicit opt-in is retained.
Clear automatic or disguised file links are stopped before navigation, with a small Download once / Cancel panel. This includes an installer behind a Play button and some unrelated installer links on product download pages. Scripted downloads and server-named attachments get a browser-level backstop: when WardenOne can identify the source page, an unexpected file is held in Download Review, where you can continue or cancel it. An unexpected download is not a malware verdict.
Visible download links, exports, keyboard saves and Save link as remain available. Global pauses, trusted-site pauses and this feature's site exceptions apply. When source context is missing or ambiguous, or a delayed action cannot be classified reliably, the intent check leaves it alone. Download Shield can still review it for independent safety evidence. Download buttons that lead to a thank-you or countdown page are supported. Each request still covers only one file.
The browser-level check starts after Chrome creates the download. A little data may arrive first, and Chrome or Brave can still show a native Save As dialog. Detached links and response-only downloads cannot always be stopped before that dialog. This feature cannot guarantee prevention of every forced download or identify every misleading product name.
Download Shield and File Shield sound alike but they look at different things. Download Shield knows how a file got to you. File Shield knows what's actually inside it. You kind of need both, neither one can do the other's job.
flowchart TB
Start["Download begins"] --> Context["Chrome gives WardenOne context"]
Context --> Grade["Download Shield checks the evidence"]
Grade -->|Known dangerous| Block["Block"]
Grade -->|Meaningful risk| Review["Hold for review<br/>You see the evidence"]
Grade -->|Ordinary or weak clues| Continue["Continue quietly<br/>Record in Activity"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
class Start,Context,Grade,Block,Review,Continue warden
linkStyle default stroke:#c45ca7
| Download Shield | File Shield | |
|---|---|---|
| Question | Should this browser download finish? | What is actually inside this local file? |
| Evidence | Source page, URL, name, type, browser signals, lists and optional reputation | Real bytes, format, structures, scripts, archives, documents and hashes |
| Access | Automatic for downloads Chrome reports | Only after you explicitly choose or drop a file |
| Boundary | Cannot freely read the saved file | Cannot observe how the file originally arrived |
When a download starts
- Chrome hands WardenOne the page it came from, the URL, the filename and type, plus whatever Chrome itself thinks of it.
- WardenOne grades it using that plus publisher trust, local lists and any optional services you turned on.
- Known threats get blocked. Disguised files and suspicious delivery patterns get held for review. Ordinary downloads and weak clues carry on quietly, with a check recorded in Activity when the download finishes.
- If it's held, the Download Review page explains the evidence and A–F score. You can cancel or deliberately continue a review; confirmed threat findings cannot be continued through Download Shield.
CSV exports, documents, photos, normal archives and routine installers stay quiet unless stronger evidence warrants intervention. An unfamiliar publisher, rare download, insecure connection, unusual domain or ordinary redirect chain does not trigger a window by accumulating points. Eligible hash and optional reputation checks continue in the background. Shared cloud and CDN hosts do not receive a publisher endorsement; disguises and malware findings override source trust.
Optional reputation providers, URL-content hashes and the URL scanner
If you want more you can turn on extra lookups. Each provider switch is off by default and can be enabled separately. Most need your own API key; OpenPhish uses a public feed instead. There's no hidden WardenOne reputation server behind any of them.
| Optional switch | What it checks |
|---|---|
| Download domain age | How recently a download source's domain was registered. |
| Google Safe Browsing | Page and download URLs against Google's malware and phishing reports. |
| VirusTotal reputation | Existing reports for download URLs. |
| URLhaus | Page and download URLs associated with malware delivery. |
| AbuseIPDB | Abuse reports for sites reached by a bare IP address. |
| OpenPhish | Known phishing URLs in a community feed downloaded to your device. |
| PhishTank | Phishing reports for suspicious pages, links and downloads. |
| WhoisXML API | Domain registration and age clues. |
| WhoisXML Domain Reputation | A domain reputation score. |
| WhoisXML Threat Intelligence | Threat indicators for suspicious URLs and downloads. |
The privacy policy explains which checks run automatically and what each provider receives.
The optional VirusTotal URL-content hash check is separate from its URL reputation check. For a small risky download it re-fetches up to 50 MB from the download address, hashes that response locally and sends only the hash. It cannot read the file Chrome saved, so the re-fetched bytes may not be the same. WhoisXML domain registration, domain reputation and threat intelligence are also separate choices that use the same key.
Download Shield also keeps malware feeds on your device, refreshed with the daily list update while it is on: URLhaus's exact payload addresses (through malware-filter) and separate SHA-256 hashes from MalwareBazaar and URLhaus (through Romain Marcoux's malicious-hash). Every valid hash from both source files is stored as a 128-bit fingerprint and matched locally, so nothing about your downloads is sent anywhere for them. They catch what a domain blocklist can't: a payload on GitHub, Google Drive or another shared host.
- A listed address pauses the download as Dangerous. URLhaus sometimes lists official tools that attackers also fetch, so you can still continue on purpose.
- A matching file hash blocks the download. To get that hash, Download Shield re-fetches the eligible risky download, up to 50 MB, from its address. That response may differ from the file Chrome saved, so a miss proves nothing; File Shield below checks a file's real bytes.
The bundled malware-hashes.json holds only the EICAR antivirus test signature, which tests
the lookup and covers nothing real. Until the hash feed arrives, Download Shield makes no automatic
re-fetch for that seed alone. You can add your own signatures through the wardenone_malware_hashes
local-storage key. The opt-in VirusTotal lookup is a separate protection.
The popup also has a manual VirusTotal URL scanner. Paste a link and press Scan URL with VirusTotal to check its report using your saved key; this works without turning on automatic VirusTotal checks. The pasted URL, including its query string, goes to VirusTotal, so remove any private tokens from it before scanning. Automatic download URL checks strip the query, fragment and URL credentials before the lookup; they run for public HTTP(S) downloads when enabled, including downloads that otherwise look clean. Very long or local addresses are skipped.
A test download that's suspicious on purpose, paused with the evidence. Your call.
See the Download Shield controls
Find it: WardenOne → Download Shield.
LOCAL TOOL · FILE STRUCTURE & HASH ANALYSIS
What it does: looks at the real bytes of a file you pick. It doesn't open it, run it or upload it.
flowchart TB
Pick["File you hand it"] --> Format["Identify the real format from its signature"]
Format --> Parse["Parse the structure — never open, extract or run"]
Parse --> Inspect["Inspect what is inside: program imports · script lines · archive index · document actions"]
Inspect --> Hash["Hash locally and compare with the malware hash feed and any signatures you added"]
Hash --> Report["Evidence-based report — findings, not a verdict"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
class Pick,Format,Parse,Inspect,Hash,Report warden
linkStyle default stroke:#c45ca7
Chrome doesn't let extensions read your saved files. And downloading it again from the same link isn't reliable, because signed or personalised or one-time links can give back different bytes. So File Shield only reads the actual file you hand it. Nothing gets uploaded, opened, extracted or run.
What File Shield reads
- Real format. The file's signature gives away a Windows program renamed to
holiday-photo.jpg. Same for double extensions, right-to-left override characters and padded names. - Windows programs. Signatures and signer names, imported capabilities, packing, signs of networking, launching processes, installing services or injecting into other processes.
- Scripts. Batch, PowerShell, VBScript, JavaScript and HTA shown as written, with the lines that download, decode, persist, turn off protection or delete backups pointed out.
- Shortcuts. The actual command a Windows
.lnkfile would run when you double-click it. - Archives. The index gets checked without extracting anything. Executables, path traversal, encryption, nesting, macros, files that claim they'll expand to something enormous.
- Documents. Office macros and PDF actions that can run scripts, launch programs or carry embedded files.
- SHA-256. Checked offline against the malware hash feed Download Shield keeps, any signatures you added and the EICAR test seed. A match means this exact file is a known sample. Most malware is new or repacked, so a non-match does not establish safety.
- Optional VirusTotal lookup. There's a button for this, but it only sends the SHA-256 (with your own API key) and only when you press it. The file and its name never leave your computer.
You can drop a bunch of files or a whole folder at once, and copy the report to send back to whoever gave you the file.
It never says "safe"
File Shield reads how a file is put together, not what it'll do once it's running. So it can tell you a file's disguised, or has code inside, or uses something dangerous, or matches a known bad hash. What it can't do is prove a file is harmless, and it won't ever pretend to. A clean result means the checks that ran found nothing disguised. That's it.
And it's not antivirus. No watching your files in the background, no sandbox, no quarantine. Keep using whatever you already have to protect your PC.
What the bytes show. "Nothing disguised" never turns into "safe".
See File Shield before a file is chosen
Find it: WardenOne → Download Shield → Open File Shield.
PROTECTION SUITE · IP, PRIVATE NETWORK & DEVICE ACCESS
What it does: covers the bits of the browser that go beyond the page you can see. Sites can ask about your local addresses, try to reach devices on your home network, open your camera or mic, reuse old permissions and leave stuff running in the background.
WebRTC can leak your local network addresses without a normal page request. WardenOne blocks known IP-grabber beacons and logger hosts (Grabify-style links etc). Block IP-grabber beacons controls embedded resource requests. Warn on IP-logger pages controls the warning shown before direct visits. The malicious-site switch can still block a known logger visit when page warnings are off; other enabled blocklists may independently cover the same destination.
On Chrome 130 and later, the warning page uses a session-specific resource URL to prevent fixed extension-ID probes. Chrome 121–129 still supports the warning but ignores that URL privacy option. Chrome's feature announcement.
The packaged rules also stop images from reviewed logger services before they load, including third-party images from IPLocation's tracker host. Its tracking-link routes show a warning on direct visits; the rest of the IPLocation site stays available. An ordinary small image is not blocked just for being small.
The Activity Center marks a logger image as blocked only when Chrome reports a matching WardenOne network rule. A suspicious image URL seen in a page is recorded as a candidate; the URL alone does not prove the browser sent a request. Activity says when network protection is unavailable. A feedback limit or error never counts as proof of a block.
The warning check inside embedded frames covers <img> and <picture> images, selected srcset
candidates, and changes to their image attributes. It does not inspect CSS background images or
every other way a frame can request an image. Network rules still block reviewed logger destinations
regardless of how the request starts. An unknown logger loaded through CSS may reach its destination
without an image-specific warning.
IP lookup blocking (on by default) blocks the common third-party "what is my IP" services, so a page can't ask an outside service for your address. It leaves WebRTC itself alone.
Harden WebRTC (off by default) strips the ICE servers from peer connections and refuses ones created without a recent click. That's what actually stops WebRTC handing out your local and public addresses. It's also what breaks video calls, screen sharing and some streaming. Which is why it's a separate choice.
The Privacy Self-Test checks for local address candidates without contacting a STUN server. The local leak is the useful thing to measure and it doesn't need an outside service to show it.
Force HTTPS upgrades pages and requests to HTTPS wherever it can. If a certificate fails you get a proper WardenOne warning page instead of a confusing broken one. Local network addresses are handled separately because routers and dev boxes often skip HTTPS on purpose.
A public website has no business poking at your router, NAS, printer, dev server or any other
private admin page. Intranet Guard checks the requests a page makes. Its network rules also block
direct private-network targets from pages and workers, including IP addresses, local names like
router.local or a bare nas, the 100.x addresses Tailscale gives your devices, and forms a page
submits to them. Keep the network rules on. They're the part the browser itself enforces.
Microsoft and Google sign-in pages can still send you back to an app you're running on this computer. If you sign in to a local app through some other provider, add that provider's site to your allowlist.
Pages you opened from your own network can still reach it though. What matters is who started it. A local tool talking to your own devices is normal. Some random public page scanning the same addresses isn't.
A hostname can look public and then switch to a private address once a request's already going. WardenOne watches which addresses sites really resolve to. If a public name points at your local network or flips from public to private (that's the giveaway for a rebinding attack) it gets blocked for the rest of the session.
Chromium doesn't give extensions a reliable DNS answer before a request goes out, so by the time the trick shows up that first request has already happened. Direct private-network access is blocked outright. Rebinding is caught from that first lookup onwards. WardenOne doesn't claim to block that very first request because the browser doesn't show the evidence early enough to honestly say so.
Media Shield can refuse camera, microphone, screen capture and hidden background media. For the camera and mic what matters is whether you're actually there, not which site it is. If a site asks while you're using the page (you clicked or pressed a key in the last few seconds) it goes to Chrome's normal prompt. And a site you've already allowed in Chrome isn't second-guessed. If it asks while nobody's at the page it's refused, unless Chrome already has a permission on file for it.
Screen capture is never pre-approved. After a click Chrome's own picker decides, every time. The
mic protection covers speech recognition too, which gets to your audio a different way (a
getUserMedia-only guard would miss it) and which Chrome might send off for transcription. Same
rule applies. When WardenOne refuses it uses the browser's normal "permission denied" path, so a
site that copes with you pressing Block copes with WardenOne too.
Location blocking has its own switch, so you can refuse your location without touching the rest of the device and permission settings. The block lives in Chrome's own location setting. If you pause WardenOne on a site or turn the block off for just that site, the site goes back to Chrome's normal location prompt. Never straight to automatic access. And that exception ends when the pause does. Turning the block off completely removes every location rule WardenOne wrote and leaves Chrome's default (and your own per-site choices) the way they were.
Looks at permission prompts together instead of one at a time. A notification request followed by camera, clipboard, location, screen sharing or file access can be riskier as a sequence than any of them on their own.
Shows what the current site is allowed to use and lets you set camera, mic, notifications and location to allow, block or ask. Chrome is still the one that applies it.
WATCH-ONLY · LOCAL EVIDENCE, NO PAGE MODIFICATION
Some things are worth knowing about but not worth blocking. These three only write an entry in the local Activity Centre. Where a permission decision is needed Chrome already asks you anyway.
Exactly what gets recorded, and what doesn't
- Background reports. Where a beacon got sent, noted once per page. What it carried is never read or stored.
- Hardware and file access. USB, serial, HID, Bluetooth, MIDI, XR, NFC, game controllers, files and folders. Including a site reusing access you gave it before. WardenOne stores what kind of access it was. Never the device, the path you picked, the file, the folder or the controller model.
- Browser capabilities. Service workers being registered, web apps being installed, idle detection and Chrome's payment sheet. The payment method can be named but never the amount or the item.
XR is there because an immersive session can expose your movements constantly (and with AR, details about the room it maps). NFC writes are there because they change a physical tag and can sometimes lock it read-only for good. Game controllers aren't suspicious at all. The model name is just a fingerprinting thing, so WardenOne records how many there are and never the model.
One limit. Watching from the top page can't see every API call inside every frame. Cross-origin frames still need the page's permission policy to use these, but a same-origin frame can share more of the page's access.
WardenOne only protects this browser. The guide explains how DNS filtering can cover your other devices too.
INTERFACE · INSTALLED EXTENSION IDENTITY & CHANGE HISTORY
What it does: shows what every installed extension is, what it can access and what changed.
Extensions can change after you install them. An update can add new permissions. Two extensions can have really similar names and completely different IDs. So WardenOne tracks all of that separately.
The Extension Security Centre lists every extension you've got installed. Exact ID, version, whether it's on, how it got installed, Chrome's permission warnings, and what its permissions add up to. It checks the exact IDs against an incident and identity catalogue that ships with WardenOne, so your extension list never gets uploaded anywhere.
Once you've reviewed an extension a plain version update doesn't undo that. A change to its permissions, identity, install source or reputation does reopen it though, and version changes still show up in the history. Permission exposure, trust evidence and suspicious changes are assessed separately. Powerful permissions or a missing catalogue entry alone are informational. Access outside a publisher's documented purpose asks for review once per unchanged snapshot; documented incident warnings remain visible regardless of review or disabled state. Ordinary re-enabling is informational. An unknown ID never gets called safe. There are buttons to disable an extension or ask Chrome to remove it (Chrome asks you to confirm). WardenOne never removes anything on its own.
Everything on one page. What changed, and what the local catalogue knows about each one.
Keeps a local timeline of each extension's versions, permissions and on/off state. Normal updates still show up. New powerful access gets highlighted so you can take a look.
When the browser starts this scans your restored tabs and catches up on the extension list. Without losing any change that happened while WardenOne's background worker was asleep.
Paste a Chrome Web Store link or a 32-character ID to check an extension before you install it. You don't have to install it at all. The exact ID gets checked against the same catalogue the Security Centre uses, and a known incident stays attached to an ID even if the extension gets renamed.
There's a separate optional button that asks the Web Store what name is currently published under that ID. It's separate because it tells Google which extension you're looking at. WardenOne only sends the ID. No cookies, no Web Store session.
If there's no listing it says removed or never existed, because from the outside those look exactly the same. If the catalogue has no record it says unexamined, not cleared. Chrome doesn't let one extension see another extension's code or permissions before it's installed, so this is checking identity and the listing. It's not a code review.
See an example of checking an extension before installation
An exact ID match is useful. WardenOne just doesn't stretch it into more than that.
When you open the popup Update Guardian checks the latest public Stable release of Brave, Chrome or Edge and shows a simple update status. It only tells you to update when it can tell there's a newer release. Brave can hide its exact version from extensions, and a matching Chrome or Edge major version doesn't tell you the patch level. So in those cases it shows the latest release and sends you to the browser's own update page to check.
For Chrome it only counts releases every Stable user can get, so a staged rollout that hasn't reached you yet doesn't count as a missed update. Results get reused for up to six hours while the browser's open. Restart or hit the refresh icon to check again. It sends no browsing history or page address. The sources and comparison limits are written up separately if you want them.
Privacy protection can't just be one blocklist. Trackers live on third-party hosts, sure. But they also hide behind a site's own domain, leave storage behind during redirects, ride along in email images, fingerprint you without sending a single request, or tag links that other people open later.
The default Block trackers & ad analytics switch also blocks recognizable Google Analytics 4
collection hits sent through the site's own domain or a subdomain, including custom path prefixes.
It matches the collection path and tid=G-… together. Ordinary endpoints on that domain and direct
page navigation stay available. The tracker switch and Pause on this site control this too.
Known analytics and tracking services get blocked using built-in rules and fresh feeds. The built-in rules carry every host rule in EasyPrivacy and Privacy Badger's pre-trained list: the trackers EFF's crawler saw following people across real sites. Like Privacy Badger, WardenOne blocks those only as third parties, leaves sister sites of one owner alone, and keeps loading the names Privacy Badger only strips cookies from or has fixed for particular sites. Every domain in the downloaded feeds is blocked as well, about 1.5 million across the ad, tracker, malware and phishing lists. WardenOne can send the Do Not Track and Global Privacy Control signals too. Domains that only exist to track get treated more strictly than normal cross-site services, since there's no login or checkout on them to protect.
GPC is exposed to page scripts at document start and sent as Sec-GPC: 1 on
requests. Switching privacy signals off or pausing restores the browser's own
JavaScript preference. Site exceptions apply to documents on the named host;
embedded documents follow their own hostname policy. Navigation uses the destination
document's setting, and subrequests use their initiating document's setting.
It can also warn when a page posts to an unblocked third-party logging endpoint. A separate opt-in replaces Facebook, X, Instagram and TikTok embeds with click-to-load placeholders.
Tracker and ad filtering here uses rules on your device. Optional reputation providers can receive page or download addresses when their separate switches are on; the privacy policy explains each lookup.
Block CNAME-cloaked trackers is on by default in Tracking. A site can point one of its own subdomains at a tracking company so the tracker looks first-party. WardenOne carries every tracker provider in AdGuard's CNAME catalog as a packaged ruleset: about 119,000 exact disguised addresses are blocked, and wildcard families seen with many listed children are matched by those children. Each provider is reviewed. Aliases of fraud checks used at sign-in and of tag managers WardenOne does not block elsewhere lose their cookies instead of being blocked. Unlisted hosts, a listed host's own subdomains and ordinary CNAMEs are not affected. An explicit off choice survives updates, presets, and ‘enable everything’.
Turn it off for one site in the popup or Settings if a listed address serves something the site needs; the exception covers that site's own listed addresses and applies to subsequent requests without reloading. Pausing a site lifts it too. Login, payment, government, education and media compatibility domains are exempt; page navigation, frames and media requests are outside this policy. Network Log shows the mapped target for the four providers it classifies and labels catalog blocks. The list arrives with reviewed extension builds; visited hostnames are never sent for DNS lookups.
Analytics can be routed through the site's own domain, where a list of third-party hostnames can't see it. WardenOne detects those first-party routes. It also has a local tracker learner that builds up evidence on your device over time.
Block trackers & ad analytics blocks known trackers by default, independently of learning. The Local tracker learner has one on/off switch and a Learning mode selector. The default, Review suggestions, collects repeated third-party activity. After three of your sites it can show a suggestion under Learned trackers in one browser session when WardenOne observes the tracking behavior itself. Page-only claims still need two sessions. These suggestions need your approval before the learner blocks their requests. Each shows its source, confidence and age. Browser observations matched to packaged tracker lists or the local CNAME mapping are marked corroborated; page API/path observations remain inferred, and page claims remain unverified. A page can influence a suggestion, including a mistaken one, but cannot turn it into a blocking rule.
Automatic tracker protection is an opt-in learning mode. It looks for an unpartitioned
third-party cookie with SameSite=None, at least a month remaining and an ID-shaped value,
either in the browser's cookie jar or in the tracker's own Set-Cookie response, read before
Block third-party cookies removes it from tracking pixels, so learning never needs that
protection turned off. The value is judged in memory and never kept. Page reports cannot
supply this evidence. Cookie shape
is a tracking heuristic, not proof of malicious intent; load-balancer, bot-check and consent
cookies are excluded. WardenOne also observes hidden text-canvas drawing and readback inside
third-party frames, reads ID-shaped localStorage values in an isolated extension world, and
checks native request URLs for IDs matching a stored cookie or an observed storage ID.
Storage and URL IDs must match across three sites in the same browser session; a different
partitioned ID on each site does not qualify. Canvas evidence identifies the frame that used
the canvas, not a script host named by a page or stack trace. Third-party scripts running in
the top page are outside this canvas learner's scope.
After three independently verified sites, qualifying domains can get durable blocks for their third-party resources, including scripts, frames, images and data requests. Direct visits remain available, and known sign-in, payment and media hosts are excluded from automatic learning. A domain allowed on any site is not learned automatically.
Once learned, a block stays until you unblock the tracker or reset WardenOne, even if it has not appeared for a year. Switching to Review suggestions stops new automatic decisions and keeps saved blocks. Turning off the learner or WardenOne pauses its rules; resuming restores them. At most 20 new automatic decisions are made per day.
View learned tracker history opens Settings → Learned trackers. Search domain names, filter blocked, unblocked or suggested trackers, review the evidence, and choose Unblock or Block again. Unblock choices are durable too: automatic learning will respect them. Unblocking a domain also lets it through WardenOne's packaged tracker and ad lists, so the site that needed it works. It does not override malware protection or an explicit per-site block. The popup shows at most five entries; history uses pages of 25. It retains each domain's first learning date and latest block/unblock status, rather than every request or a list of sites you visited. Up to 10,000 decisions are kept, separately from 600 expiring observations. At capacity, existing decisions are retained and new decisions pause instead of evicting old blocks. Cookie values are checked only in memory and never stored. Earlier cookie-only decisions require fresh browser evidence before becoming full resource blocks. Storage and URL correlation keeps at most 512 salted identifier digests and site-count sketches in browser-session storage. Raw IDs are never persisted. Worker suspension preserves those digests; closing the browser or clearing observations removes them.
In review mode, Block requests blocks the learned domain's third-party image, beacon, XHR/fetch and WebTransport requests across sites. It does not block every script, frame or direct visit. Page claims and API/path observations still need review in either learning mode: repeated appearances alone cannot safely authorize a domain-wide block.
With the same control enabled, Activity can also flag a Suspected identifier · detection only when an unfamiliar random-looking URL value repeats twice on each of three independent sites. These short-lived local observations exclude sensitive flows and leave URLs intact. They expire after 30 minutes or a worker restart; clearing history or observations also clears the evidence. Coverage is conservative, and a finding indicates reuse rather than proof of tracking.
Confirmed aliases count against their canonical tracking service only when the browser observes the actual alias hostname. Approving that service also covers its confirmed tracking aliases; the button identifies this scope. Existing approvals retain their original scope. Per-site Allow restores the service's learner-controlled requests, including those aliases.
None of this turns into a crowdsourced record of your browsing. Or a local one. The learner keeps counts (sites, sessions, coalesced observations), source categories and a keyed membership sketch. Repeated signals on one site are coalesced within the day and browser session. The durable learner does not store visited site names, alias URLs or request tokens; observations expire after 30 days. Which trackers the current site used is only shown for this browser session. The bounded sketch can undercount; it is not encryption, and a copy of the profile and its key permits testing guessed site names. Clearing observations removes the evidence while preserving explicit decisions.
Block third-party cookies also isolates known tracker cookies. It removes
outgoing Cookie and incoming Set-Cookie headers for curated tracker hosts and
confirmed tracking aliases. Resources can still load unless another protection
blocks them. Unknown hosts retain existing behavior; this does not isolate every
cross-site cookie or stop a script from using other identifiers.
Third-party resources on reviewed Google sign-in/static, Stripe, Spotify sign-in
and Facebook SDK hosts also lose both cookie directions. Public client scripts
do not receive a blanket login/payment exemption. These reviewed hosts no longer
have sign-in/checkout path exemptions in third-party contexts. Embedded pages
covered by the installed cookie policy also lose document.cookie, its prototype
accessors and Cookie Store API access. Supported network frames apply this
restriction before their first page script; other documents wait for verified
configuration.
Direct visits, first-party service use and established media workarounds retain
cookies. Unknown service providers retain their existing compatibility policy. Turn
it off for one site in the popup or Settings to restore cookie flow immediately
for subsequent requests. Explicit firewall allowances win; firewall noop
returns to automatic policy, and manual cookie stripping keeps its existing
outgoing-only behavior. This uses the existing cookie switch and adds no new toggle.
Network Log labels matched rules as Cookie isolation policy; a match
identifies the policy, not proof that a cookie existed on that request.
Early frame isolation needs an installed native rule and supported navigation timing. It does not cover every clean-frame/worker bypass or all website storage. Turning the setting off or adding an exception restores the wrapped native cookie APIs without a reload.
On top of blocking third-party cookies WardenOne can wipe cookies when you close the browser, or stop them sticking around at all. It's careful around embedded frames and scripts in general because sign-ins depend on them. Domains that only exist for measurement get handled more strictly though.
It can clear local storage in known tracker frames, so those trackers cannot simply restore an ID after their cookie is removed.
When an embedded frame uses the Storage Access API to ask for its cookies you can see who's asking. Known trackers get refused. Requests that are invisible or happen without you doing anything get flagged. There's a separate opt-in that blocks every cross-site storage request. I left that out of both Recommended and Maximum Privacy on purpose because it will break some embedded logins and checkouts.
Tracker, cookie and storage controls in the full Settings page.
When you open a link carrying click or campaign identifiers (fbclid, gclid, msclkid, utm_*
and similar), WardenOne removes them before the request leaves your browser, so the site never
receives them. This happens in the browser's network layer for top-level page loads, however the
navigation started: a click, a script, a redirect that added them, or a link opened from another
app. The link on the page is left exactly as written, and links carrying a signature, token or
sign-in code are never changed, because removing a parameter can invalidate them.
Skip tracking redirects opens the destination inside supported affiliate and click links without visiting their tracking host. It handles known Google, social and affiliate wrappers, including Awin, CJ, Rakuten, Skimlinks, Partnerize and eBay, when they include a clear HTTP(S) destination. Nested wrappers are decoded locally. The destination's signed query and embedded fragment survive, and it still goes through threat blocking. Opaque short links and wrappers that cannot safely be changed follow their normal route. Site pauses and the switch apply here too.
When you copy a link the known tracking parameters and redirect wrappers get stripped off.
The redirect switch also removes hyperlink-auditing ping attributes before they can report your click. WardenOne also
catches tracking parameters a page sticks straight into the address bar with history.pushState or
replaceState. There's no click and no navigation there for a normal link cleaner to notice.
Redirect skipping and the address cleaner have separate switches in the popup. Neither one edits a
link or form on the page; redirect skipping acts when a top-level link opens.
Other optional link controls warn when a link hides a destination in a redirect parameter or behind a shortener. They still let you follow it. De-AMP can take you from Google's AMP copy to the original article.
Before
https://example.com/article?utm_source=email&utm_campaign=sale&id=42
After
https://example.com/article?id=42
Only recognised tracking values get removed. Unknown parameters, paths and fragments stay exactly as they were. The site-specific rules used when you copy a link aren't applied to the live address bar either, because things like Amazon's search state or Spotify's context can be part of how the site works.
If a redirect took you through a known tracker domain, that domain's first-party cookies and storage can be cleared once the redirect finishes. The page you asked for, the page you ended up on, login and payment steps and anything ambiguous are always left out.
Opt-in. Notes which sites install service workers and can remove one after you close that site's last tab. It's off by default because service workers also do useful things like offline reading and notifications. Removing one means those stop until you visit again.
Cuts down the Client Hints sent to third parties, can remove cross-site referrers, and has ETag protection for known tracking services only. First-party, sign-in, CAPTCHA and payment requests are left alone. Rewriting every header everywhere would look impressive and break a ton of sites. So I kept it narrow.
Reduce third-party Client Hints also reduces JavaScript's detailed browser version, OS version and device model by default, in the page and supported frames. CPU architecture and bitness stay available so sites can select a suitable download. Turning the switch off restores native metadata. The broader graphics, audio, font and screen changes remain opt-in under Anti-fingerprinting mode; hosted editor and identity-provider compatibility exemptions apply. Workers retain their native metadata.
Cookie banners come in a few different shapes and one action doesn't fit them all:
- WardenOne uses explicit OneTrust, Cookiebot and TrustArc controls where recognized, with a guarded generic fallback. It opens choices when needed and saves disabled optional categories while preserving required choices.
- If a banner comes back after rejection, WardenOne rejects it again, including banners that reuse their original controls. It waits for the banner to disappear and return before reusing a clicked button, and spaces repeated choices to avoid click loops.
- Activity distinguishes a failed action, a dispatched action with an unverified opt-out, and an opt-out verified in the consent manager's changed saved state. A disappearing banner alone does not establish rejection. Custom or unreadable states remain unverified.
- If it's a consent-or-pay wall with no way to say no, and the article's already there underneath, an opt-in can lift the wall without clicking anything or saving a consent cookie. If the article never actually loaded WardenOne puts the wall back. Better than a blank page.
- If you accepted tracking yourself, the consent and tracking cookies can get cleared after you leave and you stay signed in.
Login compatibility stays on by default. A sign-in hand-off can look like a redirect. A request to an identity provider can look like data being stolen. A login pop-up can look like an overlay. So those flows are excluded by how they work, not patched one site at a time.
Marketing emails hide a one-pixel image with an ID for you in its URL. When it loads the sender
finds out you opened the email, when, and roughly where you were. Normal network blocking can miss
this in Gmail. Gmail loads remote images through googleusercontent.com, so the tracker's hostname
is gone by the time the request goes out.
But it's not always gone for good. Gmail sometimes keeps the original address in the fragment (the
bit after #) of the proxy link it puts in the page. Fragments never get sent to a server, which is
exactly why a blocklist can't see it and why Mail Shield works inside the webmail page instead.
Where the original address is still there it reads it and swaps the likely pixel for a transparent
image of the same declared size.
flowchart TB
Pixel["One-pixel image carrying your recipient ID"] --> Proxy["Gmail rewrites it through googleusercontent.com"]
Proxy --> Blind["At the network layer the tracker hostname is gone<br/>a blocklist has nothing left to match"]
Proxy --> Kept["But the original address survives in the link fragment<br/>a fragment is never sent to a server"]
Kept --> Recover["Mail Shield reads it inside the webmail page"]
Recover --> Neutralise["Pixel replaced with a transparent image of the same declared size"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
classDef dead fill:#3a1a30,stroke:#7a3562,color:#e6c8dc
class Pixel,Proxy,Kept,Recover,Neutralise warden
class Blind dead
linkStyle default stroke:#c45ca7
Mail Shield only runs on Gmail, Outlook, Proton, Yahoo, Fastmail, Zoho, AOL and Gandi. It doesn't look at images anywhere else. Everything happens inside the webmail page. No email content or pixel address ever gets sent anywhere.
How it decides in time, and where it falls short
It decides from the email's HTML, not how big the image renders, because by the time an image has
a size it might already have loaded. Deferred data-src addresses are covered too. It swaps a
suspected pixel for a transparent one rather than removing it because older HTML emails still use
tiny spacer images for layout.
A pixel that hasn't loaded yet can be stopped before anything goes out. One that's already loading can be cancelled but some of it might've reached the network already. If a provider strips every trace of the original address there's only the image's shape left to go on. And whether the provider fetched the image on its own servers is something no browser extension can see. Mail Shield doesn't claim to stop all email tracking.
This one's opt-in. It covers canvas text measurements, audio, WebGL, WebGPU, fonts, monitor layout, keyboard layout, voices and similar things sites measure. Either with per-session noise or with fixed answers everyone using the protection shares.
Being consistent matters more than being random. If a page got different GPU answers to the same question that'd be rarer than your real machine. Which makes it an even better fingerprint. So WebGL and WebGPU get one GPU identity across the page and its frames. It's picked per site and stays the same across reloads, tabs and the site's frames. Two different sites get unrelated ones. WebGPU limits are reduced toward the spec defaults without overstating a real adapter's capabilities; unavailable fields and native fallback/subgroup information stay truthful. Text, layout and derived analyser noise use a private per-document seed. Repeated identical inputs in that document agree; private text/layout noise can differ in another frame or after reload. Core count and memory are left alone because a worker can show their real values anyway.
flowchart LR
Ask["Page measures you<br/>canvas · audio · WebGL · fonts · screen · voices"] --> Shield["WardenOne answers"]
Shield --> Stable["GPU identity stays stable<br/>for one site and its frames"]
Shield --> Noise["Stable text/layout and analyser noise<br/>within one document"]
Shield --> Native["Core count and memory<br/>stay native"]
Stable --> Limit["Workers can still expose<br/>real graphics"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
class Ask,Shield,Stable,Noise,Native,Limit warden
linkStyle default stroke:#c45ca7
Media capability checks keep the browser's real supported answer, because lying about that can
break video. They do hide whether a supported codec is smooth or power-efficient though, since that
gives away roughly how new your GPU is. WebCodecs support is watched, not changed. And a burst of
capability probes gets logged separately from the shield, so noticing fingerprinting and changing
the answers stay two different things.
Playback buffers and sample rates remain native. Reading an AudioBuffer does not alter its
samples, and later edits through either buffer API remain usable. Raw/offline audio fingerprints
are therefore still visible. Canvas pixels and exports also remain native; the canvas protection
here concerns text measurements. Device enumeration hides labels/group metadata while keeping
native device types and usable opaque selection IDs.
Noise is stable for identical measurements within a document and resamples text/layout values in new documents. Workers retain native values. Raw pixel/audio signals can still link visits, and cross-realm reflection can reveal the wrappers. This option does not promise anonymity or an indistinguishable hardware profile.
Fingerprint probe detection has its own switch. It notices canvas, audio, WebGL, font, layout and device probing without changing the answers.
A separate opt-in can block known fraud and bot-check scripts that fingerprint you. Banks and shops also use those scripts to approve sign-ins and orders, so this one can break those flows.
Probe detection, script blocking and optional fingerprint noise have separate controls.
Where it runs. The noise changes the JavaScript environment it runs in (the realm), and a page
has more than one. Every frame it embeds gets a fresh one. So the same noise runs in every frame as
well as the page. Same-origin frames (about:blank, srcdoc, an about:blank window the page
opens) pick up the page's settings and seed the moment they're created, before the page can borrow
anything from them. They use the same policy; private text/layout seeds remain local to each
document, while the graphics identity is shared by site. Cross-origin
frames follow the same switch, the same pause and the same per-site choices as the page around
them. Captcha frames are left alone, same as the sign-in and captcha hosts the shield already
skips.
Web workers aren't covered. An extension can't get inside a worker's realm without re-serving the
worker's code, and that breaks module workers and scripts that load files relative to their own
location. So an OffscreenCanvas inside a worker still answers with your real machine. The page's
core count and memory stay native so the page and its workers don't disagree on those. Worker
graphics can still differ from the page's protected graphics though, so this can't guarantee every
realm gives the same answer.
Why anti-fingerprinting is opt-in
Some of this can't be changed without breaking something. If your powerful machine says it isn't power-efficient a site might give you a lower quality video. Blocking font or display listing can mess with design tools and video calls. So these stay as choices you can see, the answers stay consistent for the session, and I'm not going to claim more noise is always more private.
On Google, Bing, DuckDuckGo, Brave Search and Yahoo a result gets a marker before you click it if local evidence already points to malware, a scam, an IP logger, a look-alike, a raw IP address, a site WardenOne blocked before, or a really new domain whose age is already cached.
- ⛔ means a direct malware, scam or IP-logger match.
⚠️ means something worth a closer look. Not a verdict.- There's no green "safe" badge. On purpose.
Nothing gets hidden or moved around. Results never get sent to a reputation service just to draw a badge. Doing that for every result would tell some third party what you searched for, which would be a pretty silly thing for a privacy extension to do. If you want an online check on one link use Check this link.
A switch being on just tells you what you asked for. It doesn't prove the protection works. So WardenOne gives you a few ways to check up on it. See what happened. Look at the exact request. Measure what the page really got. Check the internal parts are loaded, and fix whatever's missing.
flowchart TB
Event["Something happens"] --> Protection["Protection acts"]
Protection --> Activity["Activity Centre"]
Activity --> Logger["Network Logger"]
Logger --> Firewall["Site Firewall / My Rules"]
Firewall --> Decision["Your decision"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
class Event,Protection,Activity,Logger,Firewall,Decision warden
linkStyle default stroke:#c45ca7
Settings → Clean-up & backup lets you keep Activity and notification history with normal retention, keep it only until the browser closes, or save none. Changing this choice clears both histories. Clear history goes through the worker so pending writes cannot bring old events back. Clear observations also removes tracker observations, Script Drift baselines and site counts while preserving approved blocks, firewall rules and site preferences.
INTERFACE · LOCAL SECURITY EVIDENCE
What it does: keeps a record of what WardenOne did and why.
Your recent security events, on this device. What WardenOne blocked, warned about, learned or allowed, with enough context to understand why. It's not an online dashboard. There's no account and the history never gets uploaded.
Sensitive events are redacted. A warning about a token or a clipboard value or a ClickFix command doesn't need to repeat the secret (or the harmful command) just to prove it saw one.
Stays on this device. Keeps the reason, not the secret.
Inspect the local timeline and exception controls
INTERFACE · NOTICE CONTROL
What it does: lists every notice WardenOne can show, so you can silence the message without weakening the protection.
Each notice comes with what it means and how long it stays on screen, and you can choose not to see it again. Muting a notice never turns off the protection behind it. That's why Silent mode is just a display thing and doesn't make you any less protected.
You can also choose which notices make a sound, set their volume and position, and keep the local notice history for a day, a week, a month or until you clear it. Repeated notices can be grouped, and an optional unread count can appear on the toolbar icon.
Notices stay here after the pop-up fades. Hiding them doesn't switch anything off.
LOCAL CHECK · EXPECTED COMPONENTS & RULES
What it does: checks that the protections you switched on are loaded and responding right now.
It checks the engines, registrations, lists and page components that should be there actually are there, and that they respond. A saved setting isn't the same as a running protection. If something's failed you see the failure, not a nice green state with the problem hiding underneath.
For support, Prepare diagnostics makes a local report of aggregate counts and states. You can preview it before downloading; it omits sites, browsing history, API keys and extension names.
The Blocklist section shows two dates for each feed. When WardenOne last downloaded it, and the date the publisher put in it. Open Publisher dates to see them one by one. A publisher date over 30 days old gets flagged even if the download worked, and a feed without a reliable date says publisher date unknown. Lists you subscribed to yourself show the same thing in My filters. These dates are only about list health. They don't turn any rules off.
To check every source's live header yourself run node tools/check-feed-publishers.js. An old date
means a source is worth a look, not that it gets deleted. WardenOne keeps the last rules it
accepted and keeps checking daily while auto-update's on. Before I drop a source that really has
been abandoned I compare its unique domains and false-positive risk with the current feeds, and add
a vetted replacement if one's needed.
Protection Health expanded in a fresh profile. Built-in rules are active, and the list-download status stays visible.
VERIFICATION TOOL · MEASURED PAGE RESULTS
What it does: measures what a real page can still learn about you, by comparing protected and unprotected readings of the same document.
It tests the page in your active tab, not some page of its own. Each check runs twice in the same page. Once through WardenOne's protected browser APIs and once through clean untouched copies of them. Protected means the page really did get a different value. Not just that a switch was on.
It measures canvas drawing and readback, audio, WebGL/WebGPU identity, machine hints, displays, Client Hints, voices, keyboard layout, media capabilities, local WebRTC addresses, battery and connection data, font access, game controllers, hyperlink auditing and tracking values in links or the address bar.
The possible results are ✅ Protected · 🟢 Minimal exposure · 🟡 Partly protected · ℹ️ Allowed by design · 🔴 Exposed. A shield you turned off yourself counts as your choice, not a failure. And the score only includes checks that have a meaningful right answer.
What the Self-Test can't measure, and won't pretend to
Some things can only be checked with a server at the other end. Like whether a third party really got your referrer, or whether a tracker request reached its server. WardenOne doesn't have one. And contacting a tracker to find out if contacting trackers is blocked would be doing the exact thing it's testing. So those say not testable here instead of getting a made-up green tick.
Nothing leaves your device. The WebRTC check doesn't use a STUN service, anything it adds to the page gets removed after, and the address bar gets put back even if a check fails.
Results come from what the page actually received. Click the image for the full list of measurements.
RECOVERY TOOL · LIVE PAGE COMPONENTS
What it does: finds the tabs where WardenOne's page engine is not answering and restarts it.
If a switch says on but the Self-Test gets the unprotected value, Verify & Repair checks from the inside. It asks WardenOne's isolated half in each open tab if the page engine still answers a signed challenge, and reloads the tabs where it doesn't. Reloading instead of re-injecting is on purpose. The engine only trusts a key it's handed once, before the page starts running, and there's no private way to hand a key to a page that's already running. Tabs that answer are left exactly as they are. So are sleeping tabs, paused sites and pages the engine doesn't run on.
After that you can run the Self-Test again from the outside. The two tools answer different questions which is why one can't just print the other's result.
Protection enabled
↓
Protection Health
↓
Privacy Self-Test
↓
Verify & Repair
↓
Test again
Open the full Settings page from the gear in the popup or your browser's extension options. It groups the same protection switches by what they do and lets you search their names and explanations. Favorites, recently changed settings, site exceptions, notification choices, backup and clean-up controls are there too. The overview shows what differs from Recommended and which enabled settings may affect site compatibility. You can choose a compact or comfortable Settings layout and show the popup's current-site card as one line or with counts.
Full Settings: search, presets, protection status and grouped controls.
Use Arrange sections from the popup's top bar or Settings → Look & reading → Popup → Section order to put the popup's sections in your preferred order. Drag them, use the arrow buttons, or reset to the original order. The order is shared between the popup and Settings; rearranging does not change any protection switches.
Reorder whole popup sections by dragging or using the arrows.
107 of the 110 protections have their own toggle. The other three are watch-only. They record events but never block or change a page, so there's nothing for a switch to decide.
When one protection gets one site wrong the This site panel lets you back off one step at a time:
- Open Site not working? to see recent actions and try one suggested protection off on this host and its subdomains for 15 minutes. Reload to test; undo at any time. The trial ends automatically, including after a worker restart, and malware/phishing blocks are never suggested.
- Turn off one protection on this site only if you want a lasting choice. The list shows the protections that run in the page. If one says page part only it also has a network part (blocking rules, headers, download checks) that keeps working on that site. Protections with no page part just aren't listed.
- Pause WardenOne here for 15 minutes, an hour or eight hours if a narrow trial does not help.
- Allowlist the site for good, if that's really what you want.
A site override can only turn a protection off. It can't sneakily turn something on everywhere. And pausing doesn't force a reload so you won't lose a half-filled form. The recovery panel can preview a diagnostic with only the host, recent action types and counts, and the active trial. It saves a local file only when you press Save diagnostic file; it never uploads a report or includes page text, URL paths, queries, or screenshots.
The next four tools work together. The Network Logger shows you what happened. The Site Firewall lets you decide per site. My Rules is your own exact rules. Custom Lists are rules someone else keeps up to date.
INVESTIGATION TOOL · REQUEST, OUTCOME & MATCHING RULE
What it does: names the exact request behind an event, whether it was blocked or allowed, and which rule decided.
The Activity Centre tells you something happened. The Network Logger tells you which request it was. If a site breaks start here, not by switching protections off at random.
Each row shows the request type, the page, whether it's first or third party, what happened to it and what matched it. You can turn a row into a rule that blocks the exact host, the whole domain or the path, or allows it back. All of those go into My Rules so your decisions are all in one place.
Activity and the Network Logger also show product names, companies and categories where the bundled local catalog recognizes a hostname. Source links identify the catalog revision. A name match describes the service; the recorded outcome and evidence still explain what happened. Unknown blocks stay unattributed, and local tracker suspicions remain separate. Refresh names reloads the local catalog without restarting the browser. No hostname is sent to a lookup service.
It only records while a logger page is open. Up to 1,000 requests are kept in memory and thrown away when the last logger closes. Sign-in details, query values, the fragment and any part of a path that is not plain route vocabulary are removed before a request gets recorded. What's left is the scheme, host, route and parameter names, plus a value only if it's a flag, a small number or a plain word. Nothing gets saved to disk unless you press Export. (And remember an export is still a list of the sites you visited.)
While the logger's open every request shows what happened to it and which rule decided.
Inspect the request ledger
CONTROL SURFACE · PER-SITE NETWORK POLICY
What it does: lets you decide what each domain a page loads is allowed to do, on that site alone.
Shows every domain the current page loads and lets you decide if each one can run scripts, make requests, load frames or media, or carry cookies. On this site only. Your choice there beats the lists WardenOne ships with when you choose Allow or Block. Allow and Allow once are explicit overrides, including malware and phishing lists.
Enable Include noop to choose Script, XHR, Frame and Media decisions directly. Default keeps that row's All decision; noop skips All for that column and leaves other rules in control. For example, All = block with Script = noop lets unlisted scripts load while malware and tracker rules still block their matches. Cookie stripping, parent-domain rows and temporary allowances are independent. Noop is saved with the matrix and survives backup/export; it creates no allow rule.
It's powerful enough to break a page completely so it doesn't pretend to be a friendly on/off switch. Undo is always one click (for this site or everywhere) and the grid shows exactly what a rule will cover before it gets saved.
Domains, request types, what happened and how far your own rule reaches. All at once.
CONTROL SURFACE · PRECISE PERSONAL POLICY
What it does: lets you write your own filter rules, and your rules beat every list WardenOne ships.
It's the usual Adblock syntax:
||ads.example.com^ block a host
@@||example.com^ allow a site back
example.com##.promo hide an element on one site
##.promo hide an element everywhere
Import and export are plain text. If WardenOne can't apply a rule it tells you the line number and why, instead of quietly saving it. A saved rule that does nothing is worse than one that gets refused. It lets you think you're covered when you're not.
Exceptions must name a domain with a host or URL anchor, such as @@||example.com^.
Settings-file imports show every changed value, trusted site, firewall decision, filter and
subscription address before applying. Imported filter rules keep a lower priority than security
blocking, including after a restart or an unchanged save in My Rules. A newly written rule in the
editor remains a direct manual decision.
Subscribe to a country-specific annoyance list, a niche tracker list or one you maintain yourself. Each one gets its own switch, last-updated status, rule count and refresh button.
Lists have to come over HTTPS. Private addresses, weird ports and redirects to them get refused. Their exceptions are domain-scoped and cannot override the malware, IP-logger or Script Shield blocking bands. A subscription's exception can override a block from another subscription. If a refresh fails the last working copy stays. The list's host only finds out its public list was downloaded. It doesn't get your browsing history or which rules matched.
Can block JavaScript and WebAssembly everywhere, block scripts on one site, only allow trusted third-party script hosts, or filter known fingerprinting scripts. Lockdown and Smart are separate modes because "this page won't run any scripts" and "untrusted third-party scripts get limited" are really different promises.
Script drift guard separately remembers the hash of a third-party script at a URL and warns when that URL later serves changed code with new behaviour or outbound hosts. It is on by default.
Ad blocking is still a big part of WardenOne. I just didn't want it to be the first thing you read about.
Network filtering, cosmetic rules and anti-adblock scriptlets, in the same formats you'd know from EasyList, AdGuard and uBlock. Shipped rules, your own element removals and rules from custom lists are kept apart. So allowing one thing back doesn't undo something unrelated.
YouTube ads get removed by taking the ad schedule out of the player's data. Not by covering the ad with a black box or racing to hit skip. Pre-rolls, mid-rolls, the ad UI around the player and player changes are all handled together. Account refreshes, captions, playback controls and the seek bar keep working like normal.
YouTube changes all the time. There are compatibility checks and a YouTube-only pause because if a video won't play the protection has failed. Doesn't matter how many ads it blocked.
Twitch stitches ads straight into live streams, so normal request blocking can freeze the player or leave it looping. Instead WardenOne asks Twitch for another clean stream session (signed by Twitch itself) and keeps the video sequence continuous while it switches over. Display and picture-in-picture ads get declined before they load.
Steadier Twitch playback is a separate comfort switch. It keeps a few seconds buffered through ad breaks and network hiccups, so the stream may sit a little further behind live. It turns Twitch's Low Latency mode off unless you chose that mode yourself.
No third-party proxy ever touches the video. If Twitch doesn't offer a usable clean session the ad just plays, instead of the player freezing or looping behind a cover. That's on purpose. A stream you can watch matters more than a blocked ad you can't get past.
Spotify's web player gets its playback state from Spotify's servers. WardenOne doesn't touch that state, the responses carrying it or anything on your account. It works in three layers, all on your side.
First, the track loader. Every track the player loads passes through one callback with the media URL it's about to load. If Spotify itself labels that track as an ad the URL gets swapped for a one-second silent clip. Nothing from the ad gets downloaded, the clip ends by itself, and the player moves on to the next song like it would after a real ad. It's the same trick AdGuard's filter uses on open.spotify.com and it doesn't care which host the ad would've come from. WardenOne's version also covers ads delivered through Spotify's manifests.
Second, the network. Media requests to dedicated advertising paths and hosts are redirected to the same silent clip. Shared audio CDN paths are left alone: their URLs cannot distinguish an ad from a song, preview or podcast. The web player's other media is also let through generic ad and tracker lists so podcast audio delivered through an analytics prefix can play; malware rules still take priority.
Third, a fallback for an ad that still makes it to the player unchanged. It's recognised from Spotify's own metadata and muted before it plays, then skipped to near the end. But only once Spotify confirms that ad is the one playing right now. Each confirmed ad gets skipped at most once so preloads and retries can't set off a chain of skips. Without that confirmation the ad stays muted and plays through. The silent clip itself never gets skipped and the ad UI is hidden while the ad slot lasts. If Spotify changes how it delivers ads none of this promises an instant transition.
There's a separate problem too. Sometimes Spotify answers an audio-license request with HTTP 429 and the player skips through a bunch of songs on its own. WardenOne holds that rejected response for up to ten seconds, which gives a good license that's already on its way a chance to keep things steady. It never makes an extra license request, your own skips aren't slowed down and good licenses pass straight through. In a live retest one song kept playing through a 429. But a later burst of rejections still made Spotify jump to a different song. So it only partly helps. It can't override a license Spotify refuses to give.
Normal songs, previews and podcast episodes never get muted or skipped. Turning AdShield off (or allowlisting open.spotify.com) switches all of this off. It's a workaround for the web player, not a replacement for Premium. Spotify can change its player whenever and you might still notice a short transition.
Sponsored results on Google and Brave (and their ad-click wrappers) can be removed. Hiding Google's and Brave's AI answer panels is optional. For Google WardenOne uses Google's own plain Web mode, which asks for the classic ten blue links in the first place, so there's no panel that flashes up and then gets hidden.
Answer-scraper sites get dimmed and labelled with a Show anyway button. Never quietly deleted. If a search filter hid the one useful result you'd never know it happened, and that's worse than a mistake you can see.
Point at a sticky bar, a leftover consent box, a sidebar, a floating video, whatever, and remove
it. It's remembered for that site and saved locally the same way as your own cosmetic rules.
Ctrl+Z can undo a few removals even after the tool closes. And if you select something big it
asks first (mouse or keyboard).
The Hidden elements page lists saved removals so you can bring back one item without clearing the others.
Zapper edits preserve hiding from your own filters and subscribed lists. If another filter also matches an element, undoing its Zapper removal leaves that filter in effect.
Start Element Zapper from the popup or WardenOne's right-click menu. Point at the unwanted
element and check the outline before clicking. Use ↑ to select a larger containing element or
↓ to narrow it down. Keep clicking to hide more items, then press Done or Esc to close
the tool. Ctrl+Z restores the most recent removal while that page is still open.
1. Choose what to hide. On GitHub's Actions page, the active Zapper outlines the developer newsletter section. The outline shows exactly what the next click will hide.
2. Click, and it's gone. The newsletter section is now missing, the footer links move up, and WardenOne confirms One thing hidden. The removal stays in place after reloading and only changes what you see in your own browser. Keep zapping, press Done, or use Undo last to bring it back.
Captured on the live GitHub website with WardenOne's actual Element Zapper, before and after the click.
Known mining-as-a-service scripts, third-party mining-pool traffic and stratum WebSockets get blocked. A mining pool's own website still works if you go there on purpose. Optional deep detection looks through the code of background workers for mining routines and stops the worker (plus any replacements the miner starts) without killing the rest of the page.
High CPU on its own never counts as mining. A video export, a WebAssembly build and a miner can all max out your cores. WardenOne goes by mining code it can actually see, which means a well-hidden miner can slip past.
Everything's under one WardenOne entry in the right-click menu, split into groups. Element Zapper and Copy clean link act on whatever you right-clicked. Check this link, Check selected text, Where is this image from? and What is this frame? answer a question about it without you having to go there. Sleep this tab, Never sleep this site and Close this tab act on the tab. Block this site blocks the site everywhere.
Copy clean link is there as well as the automatic link cleaning because Chrome's own Copy link address and the address bar are part of the browser itself. Page scripts can't step in there.
Sleep this tab unloads the tab to free up memory and moves you to the next tab, so you're not left
staring at a blank page. The tab stays in the strip and reloads when you click it. Both sleeping and
closing stop if you've typed something you haven't saved or the camera or mic is in use, and tell
you which one. Closing has that check because closing a tab this way skips the browser's own "leave
site?" prompt. Ctrl+W still closes a tab no matter what.
Never sleep this site works per host, not per domain. So marking your mail keeps your mail awake without affecting the rest of that domain. Same menu entry takes the mark off again.
If your browser's assigned the suggested Alt+Shift+O shortcut, press it, type a few letters and pick something. Check the site, run the Self-Test, hide an element, clean the page address, pause here, open the Logger or Firewall, check a file or extension, look at Activity, open settings.
Every WardenOne tool, one shortcut away. Nothing runs until you press Enter.
Why the page can't use the palette for its own ends
The palette on the page only displays things. The background worker owns the list of commands. It
rejects any ID it doesn't know and only accepts a choice that carries the one-use grant the
shortcut gave that exact tab's palette. That grant is a random value kept in WardenOne's own
isolated world, which the page can't read. Its hash lives in storage.session so it survives the
background worker going to sleep (Chrome does that within the two minutes a palette stays valid)
but disappears when the browser closes. It gets used up the moment it's spent. One press of the
shortcut, one action. A fake message from the page can't make a grant.
The palette only gets added to the page when you open it, inside a closed shadow root. The page can't read what you type into it or restyle it into something misleading.
Shortcuts use Chrome's own extension shortcut system, not a key listener injected into every page.
So pages can't see them or swallow them. You can change them at chrome://extensions/shortcuts
(brave://extensions/shortcuts in Brave).
WardenOne suggests four keys, including Alt+Shift+U for cleaning up the page address. The other commands don't have a suggested key on purpose. Your browser might leave a suggested key unassigned if it clashes with something or you cleared it. If the palette key says Not set use the Open palette or Set shortcut button in the popup. WardenOne can't assign a browser shortcut for you.
Clears a site's cookies and storage after you close its last tab (except allowlisted sites). There's a one-click button to clear them right now too. You can separately choose to clear that site's browser history when Forget Me runs.
Common categories appear first in a compact cleaning card. Expandable rows hold automatic cleaning, protected websites and history; advanced choices, preset management and reset controls open when needed. Clean browser data starts open and can be closed; opening another dropdown leaves existing sections alone. Info buttons explain individual choices, and the review screen shows consequences before confirmation.
Choose Quick Clean, Balanced Clean, Deep Clean or up to eight saved presets, then review the categories, time range, scope and consequences before deletion. Only browser cache is selected by default. Cache Storage and website file system data have separate controls. Browser history, WardenOne activity and notifications, tracker observations and Script Drift baselines are independent.
Protected websites exclude exact origins from supported cache and storage cleanup; cookie exclusions cover the registered domain. Add every scheme, subdomain and port you want preserved. Single-site cleanup supports the active website, with a warning that cookies can affect sibling subdomains. History, download records, saved forms, permission rules and WardenOne records cannot exclude protected websites. Download cleaning removes records, not files. Recognized-cookie cleaning uses names and vendor domains; it cannot guarantee sign-in preservation, covers all ages, and may bring consent banners back. Chrome provides no reliable cookie creation-age filter.
Automatic Privacy Cleaning is opt-in, with a separate category selection, daily, weekly or monthly scheduling, startup cleanup and optional notifications. Missed schedules coalesce into one cleanup when Chrome resumes; exact execution time is not guaranteed. Results retain the last 20 cleanups within 30 days and identify incomplete categories. Interrupted work is reported without automatic replay. The cleaner runs only in normal windows. Emergency logout and Forget Me have their own scopes.
Permission cleanup removes WardenOne-created rules only. Browser-granted permissions must be changed in browser site settings. Password deletion is not offered.
Settings also lets you inspect and erase WardenOne's own saved records and site exceptions, with a preview of what the reset will remove.
Exports all your settings to a file you keep. API keys are never included and an imported file can't sneak one in. There's no account and no cloud sync, so this is how you move your setup somewhere else.
Puts inactive tabs to sleep, with Gentle, Balanced, Aggressive or Emergency profiles. You can keep pinned tabs, tabs playing audio and tabs with forms, logins or payments awake. It can find duplicate and zombie tabs too, and free up memory whenever you ask.
Tab Limit is separate: when opening a tab takes you over your chosen limit, it can sleep an older unused tab or close one if you choose the more aggressive mode. You can choose whether a close shows a notice and set the minimum idle time before a tab can be slept.
From the right-click menu you can put a tab to sleep straight away, or mark a site never-sleep. The popup's Never-sleep sites control also lets you add a domain or the current site and remove saved hosts. The choice applies to the saved host, not every subdomain. A marked host stays awake regardless of the sleep profile.
See Memory Shield's safeguards and profiles
Controls for autoplaying media, background throttling, lazy-loading images, prefetch and preload. Block autoplay is off by default. When enabled, it permits delayed startup and retries for the media you select through its player or controls; unrelated media stays blocked. Turning it or Block hidden media abuse off releases its playback block in open tabs without a reload.
An optional YouTube control hides Ambient Mode's decorative watch-page glow and stops the home header blurring thumbnail colours into its background. It may reduce rendering work on some systems. It leaves playback and YouTube's own preference alone.
Another optional control stops recognised muted card and hover previews across sites. It leaves normal players, videos with controls and manually started inline videos alone. On YouTube it also hides the inline-preview layer so the static thumbnail remains visible.
An optional GIF control shows a still frame for visible, loaded URL-backed GIF images. It also handles GIPHY images served as animated WebP with a matching GIF fallback. Click a still frame to play its image. The page's image element stays in place so source changes can be followed. Canvases are released after they leave the viewport and their memory is capped; on an unusually dense page, some images may keep playing once the cap is reached. Tiny images and embedded data GIFs are left alone because sites often use them as loading placeholders. Video previews and animations drawn into canvas are handled separately. The control is off by default. It does not save the initial image download.
The advanced WebGL saver can disable hardware-accelerated 3D graphics on selected sites or everywhere except an allowlist. It is off by default because games, maps, CAD tools and 3D viewers can stop working without WebGL. The popup has a current-site action; Settings manages both lists.
Resource Saver, including GIF pausing, preview controls and the WebGL mode.
The popup keeps the mode pills and brightness slider in one card. Its scope chip switches between the All sites default, custom settings for the current site, and turning EyeShield off there. Changes save automatically. Contrast, saturation, warmth and greyscale live under More reading controls; the sliders announce their values as percentages. Security warnings keep their keyboard and screen-reader support whether EyeShield's on or not. A spoken screen-reader pass remains pending.
WardenOne's own pages come in light and dark and both keep warnings, status colours and disabled buttons easy to tell apart. Light is the default. Pick Dark in the popup (or its Interface section, or onboarding) to switch every page, or System to follow your operating system. Even if it changes while you're browsing.
Local DVR lets you scrub back through a live stream from when you opened the tab. It keeps a buffer in your computer's memory and is off by default. The separate Watch from earlier button opens the current broadcast's VOD in Twitch's player, so you can jump to before you joined when the streamer saves past broadcasts. It uses no local recording. Both are comfort features, separate from the ad and security engines.
An optional screen that shows up before a listed (or likely) adult site loads. So a typo or a redirect you didn't click doesn't put explicit content right in front of you. It says how you got there: a site you opened yourself, or one a redirect brought you to. The page stays dark from its first moment until the screen appears, so nothing explicit flashes up while settings load.
Can enforce SafeSearch on Google, Bing, DuckDuckGo, Brave Search and Yahoo, plus YouTube's Restricted Mode. It's separate and off by default because it changes what search and video sites show you.
WardenOne asks for a lot of browser access because it protects a lot of the browser. Requests, pages, downloads, cookies, sessions, site permissions, your installed extensions. That's a lot to ask for so I've tried to explain every bit of it properly.
Each permission, what it's for, and where its reach stops.
The permissions guide that comes with WardenOne goes through every permission and what it's for. PRIVACY.md covers what's stored, what network traffic there is and every optional service, in full.
In short:
- No account and no telemetry. Your browsing doesn't go through any server of mine and there's no analytics.
- Open source. The code, the pages, the tests and the bundled rule data are all here in this repo.
- Local. Your activity, settings, learned tracker evidence, file analysis and extension-ID matching all stay on your device.
- Secrets stay secret. No login token or password ever gets stored, and none gets sent anywhere except the site it came from. The only place a token moves at all is Twitch ad blocking. It sends the Twitch page's own
Authorizationheader back togql.twitch.tvso the playback request gets accepted. It's read from the page, never written down, and never leaves Twitch. - Outside checks are disclosed. Optional reputation switches can send page or download addresses automatically while enabled; manual scans send what you ask them to check. Public rule updates and the browser-release check also contact their named endpoints. The network filtering self-test loads favicons from named adult and malware-test domains only when you start it. The privacy policy lists the requests and what they send.
- Files never get uploaded. File Shield's VirusTotal button sends only the SHA-256, only when you press it, and only with your own key.
- Updates aren't telemetry. Rule updates just download public list files and say nothing about your browsing. If one fails the old copy stays.
See how optional provider keys are explained
Every provider is optional. WardenOne's local lists, heuristics and page protections all work without a key. Adding one gives you one specific kind of lookup. It doesn't switch on some hidden backend.
There's no WardenOne server in the middle of your browsing. The work's split across the parts of the browser that actually have the evidence:
- Browser network layer. Rules for listed destinations and direct private-network targets, plus redirect and download checks.
- Page and session layer. Fake interfaces, logins and passwords, privacy APIs, links, and signs of device use.
- Extension worker. Local state, and the browser APIs that join the layers together.
- Local pages. Activity, Self-Test, Repair, Logger, Firewall and the review tools, where you see and control what happened.
Browser-enforced network rules keep working even if a website changes its JavaScript. The token
and skimmer checks are different. They wrap page APIs like fetch, XHR and sendBeacon, and a
hostile page can replace those wrappers, borrow an unwrapped copy or send data some other way they
don't watch. They stop the matching calls they see. But they can't guarantee that malicious code
already running in a page won't get a secret out. The network rules block the destinations they
cover. They don't look inside a random request for your secret.
flowchart TB
Page["Web page"] --> PageLayer["Page and session layer<br/>deceptive interfaces · credential flows · privacy APIs · links"]
Net["Browser requests"] --> NetLayer["Browser network layer<br/>listed destinations · direct private-network targets"]
Dl["Download"] --> DlLayer["Download Shield<br/>origin · identity · behaviour"]
PageLayer --> Worker
NetLayer --> Worker
DlLayer --> Worker
Worker["Extension worker<br/>the only place the layers meet"] --> State["Local state and evidence<br/>never leaves this browser"]
State --> Explain["Activity · Notifications · Health<br/>what happened"]
State --> Prove["Self-Test · Verify and Repair<br/>whether it still works"]
State --> Control["Logger · Firewall · My Rules<br/>your decision beats every list"]
classDef warden fill:#51203c,stroke:#c45ca7,color:#ffffff
classDef entry fill:#2b1226,stroke:#8d3f74,color:#f0d7e8
class PageLayer,NetLayer,DlLayer,Worker,State,Explain,Prove,Control warden
class Page,Net,Dl entry
linkStyle default stroke:#c45ca7
Everything ends up in one worker and one local store, and the pages you use to see, check and control it all read from there. That's what the One in WardenOne really means. One place where everything each layer notices ends up. Not a pile of separate tools sharing an icon.
Some tools sound like they overlap but they look at different evidence. Download Shield knows the browser's context, File Shield knows the bytes. Activity records the event, the Logger names the request and the rule. The Self-Test measures from outside, Verify & Repair checks from inside. An extension's identity history and its current permissions answer different questions too. I kept them apart on purpose so nothing gets squashed into one convenient score that promises more than it can back up.
My local copy is usually a good way ahead of what's pushed here.
I build in VS Code with the extension loaded, and I'll happily sit with one thing for hours — edit, reload, hard-refresh, watch what the page actually does, go again. Almost none of that is worth a commit on its own, so I push once something is finished and I'm actually sure about it. The history goes quiet and then several commits land at once, which is usually just one long session finally ending. Probably more of those at 2am than is strictly sensible.
Use Node 24 (recorded in .node-version). Everything goes through
node tools/check-maintainability.js first. And when something
turns out to be wrong on a real site, I'd rather leave the revert sitting in the history
than tidy it away.
Run node tools/build-source-bundle.js from a clean checkout to make a ZIP next to the repo. It has
every file tracked in the current commit (src/, tools/, the docs, everything) and leaves out
local folders like .git/, .store-candidates/ and .publish/. That's the source for review. The
Latest release ZIP is the smaller extension package. It won't run on a checkout with uncommitted
changes, so nothing gets silently left out. Use --committed only if you really do want a ZIP of
HEAD without your uncommitted changes.
Guessing what something costs isn't the same as measuring it, so release candidates get profiled
too. node tools/perf-profile.js loads the real extension into a real browser and measures three
local test pages. An article, a page that builds a deep DOM like frameworks do, and a page with
eight frames. Extension off and on, five runs each. It writes the medians, the tails and every raw
value to a private local report, tied to the commit and the browser version.
It won't measure anything unless the extension's actually loaded and running. It has to prove it can spot a known regression before its numbers count. And nothing it does leaves the machine. The current build's profile (and how to read one) is in docs/perf/README.md.
The GitHub build is all of WardenOne. The Chrome Web Store package I've got ready includes
EyeShield's optional readability controls and Memory Shield's resource controls, Tab Limit
included. It leaves out Twitch Rewind, which is really its own separate media tool. And that means
its files, manifest entries and settings, not just a line in the description.
node tools/build-store-package.js builds that package from a commit, byte-for-byte reproducibly.
The worker and popup read build-profile.js so they run fine without the parts that got left out.
The public build profile reference lists the included and omitted
features. Nothing's been submitted yet. The
tool's there so if it ever is, what goes up matches the record exactly.
Website: iri-dev.github.io/WardenOne
Author: iri (iri-dev on GitHub) · iri-dev.github.io
Releases only ever come from github.com/iri-dev/WardenOne. WardenOne is never an executable installer. In August 2026 someone republished the project under another account and pointed its downloads at a credential stealer. GitHub took the account and site down. The incident page has the file details, antivirus results and recovery steps if you ran the fake copy.
A security extension has a lot of access to your browser so where you got it from really matters. A build from another repo, file host or website didn't come from me. Even if the screenshots and description got copied word for word. If you want extra reassurance there's an optional download check below.
Optional, for advanced users. The three Quick install steps are all you need
to install the ZIP from the official GitHub release. You only need WardenOne-latest.zip; downloading
the .sha256 file, calculating a hash and using the GitHub CLI are optional. These checks just give
you extra evidence about the exact ZIP you downloaded:
- SHA-256 checksum. If the ZIP was damaged, changed or mixed up with another one, its hash won't match the one published with the same release.
- GitHub build attestation. A record that ties those exact ZIP bytes to a build run by this
repository's GitHub Actions workflow from
main.
To check the hash, download WardenOne-latest.zip.sha256 from the same release page as the ZIP. The Latest link moves to a new, verified commit build only after both files have been uploaded and checked; the previous rolling release is then removed. If the hashes don't match, open the current release page and download both files again together. Don't load a ZIP that still fails. The release notes show the ZIP's SHA-256 and link to its attestation too.
On Windows PowerShell, in the directory containing both files:
$expected = ((Get-Content .\WardenOne-latest.zip.sha256 -Raw) -split '\s+')[0]
$actual = (Get-FileHash .\WardenOne-latest.zip -Algorithm SHA256).Hash
if ($actual -ine $expected) { throw 'WardenOne ZIP checksum mismatch' }
'SHA-256 matches'On Linux, run sha256sum -c WardenOne-latest.zip.sha256; on macOS, run shasum -a 256 -c WardenOne-latest.zip.sha256.
For the optional build-origin check, use the GitHub CLI:
gh attestation verify WardenOne-latest.zip --repo iri-dev/WardenOne --signer-workflow iri-dev/WardenOne/.github/workflows/gate.yml --source-ref refs/heads/main
Neither check proves every protection is bug-free. Also compare the attested source commit with the full commit in the release notes, because an older ZIP can have a valid attestation too.
Found a site WardenOne breaks, a false positive, or got an idea? Use the issue forms. For a broken site the URL and which protection was involved help me the most.
Found a vulnerability in WardenOne itself? Please don't put exploit details, secrets or live harmful payloads in a public issue. Read SECURITY.md and use GitHub's private vulnerability report instead. I'd much rather hear about it than not 💜
Copyright (C) 2026 iri. WardenOne is licensed under the GNU General Public License v3 or later; see LICENSE, NOTICE and CREDITS.md. You're welcome to share modified versions under the licence, as long as the changes are marked and the notices are kept.
WardenOne wouldn't exist without the open-source blocking community. AdGuard, EasyList, EasyPrivacy, TwitchAdSolutions, scamorza/TwitchAdBlock, GosuDRM/TTV-AB, uBlock Origin uAssets and more. The full list of sources and credits is in CREDITS.md.
Settings → About WardenOne → Licenses & credits opens the packaged notices offline. Third-party data retains its applicable terms; the generated source inventory distinguishes published licenses, scoped written permissions and specific exceptions.