WebGuard Privacy

In short

WebGuard is a browser extension that checks websites for signs of phishing and warns you before you send sensitive information somewhere you might not intend.

WebGuard has no servers. There is no account, no login, no analytics and no telemetry. Nobody at Elevven11 Studio can see what you browse, what you check, or what WebGuard finds.

What WebGuard reads

To check the page you are on, WebGuard reads:

• the page's address, from the browser rather than from the page;
• the structure of its forms: whether there is a password or card field, where the form submits to, and the field types. Never the values;
• the hostnames of resources the page loaded, to recognise trackers;
• the number of cookies and local-storage entries the page can see;
• the page title.

It does not read the text of the page unless a check specifically asks for it, and no shipped check currently does.

What WebGuard never reads

• Password fields. The input monitor skips them entirely. Their values are not read, not scanned, and not counted.
• The contents of any field you type into, other than the paste and blur-time scan described below, which is local and returns no values.

What WebGuard stores

On your device, in chrome.storage.local:

• your settings;
• your trusted sites, as registered domains;
• a short-lived cache of page verdicts, which expires after ten minutes and holds at most forty entries;
• a feed API key, if you entered one;
• only if you turn history on: a list of checks, where each record holds a hostname, a risk level, a score and a timestamp. Nothing else fits in the record. Pages you merely visit are never recorded. History is off by default.

And in IndexedDB: downloaded threat lists, as hash prefixes. This is public threat data and contains nothing about you or where you have been.

What WebGuard never stores

Anything sensitive it encounters while you browse: passwords, API keys, tokens, private keys, card numbers, database connection strings, the contents of any field you type into, and the contents of the pages you visit.

None of these is written to storage, placed in a log, included in an error message, or sent anywhere.

The one credential WebGuard does keep is a feed API key you deliberately typed into settings, which is yours and is described below. Nothing WebGuard finds is ever kept.

Network requests

Online checks are off by default. With them off, WebGuard makes no network requests whatsoever, and every check runs on your device.

If you turn them on, two things may leave your browser, and neither of them is a URL or a password.

The password breach check

When you ask WebGuard to check a password for breaches:

1. The password is hashed on your device, in the popup.
2. Only the first five characters of that hash are sent to api.pwnedpasswords.com.
3. That prefix selects a bucket of roughly eight hundred hashes, which comes back in full.
4. WebGuard compares the rest of your hash against that bucket locally.

The service receives five hexadecimal characters. It cannot learn your password, and it cannot learn your password's full hash. The request also asks for padding, so the size of the response cannot hint at whether your password was in it.

The password itself never leaves your device, under any setting.

Threat lists

WebGuard can check addresses against published lists of known malicious and phishing URLs. It does this by downloading the lists, not by asking about your pages.

1. Lists are fetched wholesale and stored on your device as hash prefixes: four bytes of a SHA-256 hash per entry.
2. When a page is checked, its address is canonicalised and hashed locally, and the prefixes are compared against the local database. Almost every page is resolved here, with no network activity at all.
3. Four bytes collide, so a prefix match is a candidate rather than an answer. Confirmation compares the full hash. For lists WebGuard hashed itself, the full hashes are already local and confirmation needs no network.
4. For prefix-only lists such as Safe Browsing, confirmation sends the four-byte prefix and asks which full hashes sit under it. The comparison happens back on your device.

Step 4 is the only request in the product derived from a page you visited, and it carries four bytes of a hash. The service cannot tell which address produced it, because a great many addresses share any given prefix.

Because matching is local, threat-list protection keeps working with no network at all once the lists are downloaded.

Coverage is reported honestly. WebGuard distinguishes "checked against current lists and not listed" from "no lists downloaded", "lists out of date" and "not checked". An empty or stale database is never presented as a clean result.

API keys

Some feeds require a key. WebGuard ships none: an extension cannot keep a secret, since anyone can unpack it. A feed that needs a key stays off until you supply your own, and says so.

A key you enter is stored in chrome.storage.local on this device and sent only to the service it belongs to. It is deliberately excluded from the settings export, because an exported file is easy to email or sync somewhere else.

Email breach checking

Not implemented. Every breach directory for email addresses requires a paid, authenticated key, and an extension cannot hold one secretly. Rather than ship a key or invent a result, WebGuard tells you so and offers to open the service that can answer. WebGuard never checks an email address it finds on a page; only one you type in yourself, and only when you ask.

The sensitive-data scan

When you paste text into a page, or leave a field you typed into, WebGuard scans that text for things shaped like credentials.

This happens entirely in the page, synchronously, in a pure function. The text is a local variable. The scanner returns only:

• what kind of thing it recognised, as a label;
• a confidence;
• where in the text it was, as offsets;
• a masked preview, for example sk_l…********…kLmN.

There is deliberately no field in the result for the matched value. Everything downstream of the scanner, the warning card included, is structurally unable to display, store or transmit a secret, even by accident.

Nothing about the scan is stored or sent.

One exception, and how it is handled

Choosing "Scan selection for sensitive data" from the right-click menu has to move the selected text from the background service to the popup that renders the result. That text is put in chrome.storage.session, which lives in memory and is never written to disk, is read exactly once (the read deletes it), and expires after thirty seconds. Nothing else in WebGuard may use that channel.

Permissions

Permission	Why
storage	Your settings, trusted sites and optional history.
activeTab	Looking at the page you are on when you ask.
tabs	Reading the current tab's address, which is what the URL and domain checks examine.
scripting	Injecting the page reader into tabs already open when WebGuard was installed or updated.
contextMenus	The right-click entries.
notifications	A single notification when a high-risk page is found and the in-page warning cannot be drawn.
Host access to http://*/* and https://*/*	Automatic protection means checking a page as it loads, which requires access to the pages you visit. What is read is listed above. It is sent nowhere.

Threat-list checking adds no permission at all. The lists live in IndexedDB, which needs none, and they refresh when the extension is already awake for a page load rather than on a chrome.alarms schedule, which would have needed one.

WebGuard requests no permission it does not use. The same table appears in the extension's own settings page.

Your control

From the settings page you can:

• turn off website warnings, sensitive-data warnings, privacy analysis, the right-click menu, and notifications;
• turn online checks off, which stops all network activity;
• turn history off and clear it;
• remove trusted sites;
• clear cached verdicts;
• update or stop updating the threat lists, and remove a feed key;
• reset WebGuard, which deletes every piece of local WebGuard data, across both the settings store and the threat database.

Uninstalling the extension removes all of it too. There is nothing held anywhere else, so there is nothing else to delete and no request to make of anyone.

Changes

Any change to this policy will accompany a version update, and any change that introduces a network request or a new stored field will be called out in the extension's release notes.

Contact

Questions about this policy go to elevven11studio@gmail.com, or message us on WhatsApp. Bug reports and feature requests are welcome through the contact form.

This policy covers the WebGuard extension only. The studio privacy policy covers this website and the enquiries you send through it, and each of our other extensions publishes its own.