Trust and boundaries
Is CrispGuard's masking done locally — and can the extension itself leak what you screenshot?
CrispGuard draws its masks in the browser: keywords become a bar, images a placeholder block, areas an overlay, and none of it needs a server. But it works at the page layer, not the operating-system layer, so a capture that bypasses browser rendering may miss the mask. It is not a security product and does not encrypt your screen.
If you want to know what CrispGuard can actually cover, the product page lists the three overlay types. This page is narrower: where the masking happens, and what that placement does and does not protect.
CrispGuard's data path: what stays in the browser, and what leaves it
The masking runs in the extension's content script, inside the page you already have open. Matching text, swapping images and drawing overlays all happen while that page renders locally. No step in that path requires uploading the page to a server.
CrispGuard is a Chrome extension, and the part that does the work is a content script — code the browser injects into the page you are viewing. It reads the text and images already present in the document, compares them against the keyword list you configured, and rewrites what the browser is about to draw. A matched keyword becomes a solid bar, a colour block or an emoji. A matched image becomes a placeholder block. A selected area gets an overlay drawn on top of it. The page underneath keeps working: links navigate, forms submit, scrolling is unaffected.
Every one of those steps is a local operation on a document that has already been downloaded: the comparison runs against a list stored with the extension, not against a server-side model, and no stage in that path has to send the page anywhere.
That is a claim about the masking path, and it is worth being precise about what it does not cover. "Local masking" and "no network requests at all" are two different statements. The second is stronger, and checkable. This page does not upgrade the first into the second. According to the store listing's feature description, CrispGuard's masking decisions and drawing happen on your device. What the extension talks to over the network — licence verification, anything else — is defined by its privacy policy, and that document is the one to read before you decide. The design goal is to keep as much data inside the browser as possible; the exact network behaviour is a question for the privacy policy, not for a marketing page.
The useful comparison is with a product that states the stronger version. ContextBlur's privacy policy declares 100% local processing and zero network requests, says its automatic blur only runs when the user clicks "Run auto-blur now", and says it stores CSS selectors rather than page content. It establishes something worth knowing: "processed locally" is a claim a vendor can publish and be held to in this category. It is not a CrispGuard-specific talking point, and it should not be taken on trust from any vendor, including this one.
One more boundary belongs here. Masking changes what the page displays. It does not encrypt the page, hide it from the browser's own processes, or stop anyone with access to your unlocked machine from opening developer tools and reading the DOM. CrispGuard is a privacy convenience for shared spaces, not a security product, and it should not be described as one.
What happens to the mask when you screenshot or record — what it covers, and what it doesn't
Only the capture path decides. If a tool reads the browser's rendered page, the mask is usually part of that image. If it reads the operating system's frame buffer, or a camera photographs the screen, the extension cannot put the mask there.
The mechanism explains the outcome. A browser extension lives inside the page rendering pipeline: it edits the document object model and the styles applied to it, and the browser paints the result. Capture tools come in two families. Some ask the browser what it is currently displaying — they read the same rendered page the extension already modified. Others read the operating system's frame buffer, the composited image of the entire screen, and never consult the page at all.
Mobile platforms show what the second family can do when the platform cooperates. Android's FLAG_SECURE blocks screenshots at the platform security layer, so the operating system refuses the capture outright. Chrome extensions have no equivalent layer — no API lets an extension tell Windows, macOS or a capture device to refuse the frame.
| Capture method | Does the mask usually appear in the result? | Why |
|---|---|---|
| In-browser screenshot (Chrome DevTools capture, the extension's own captureVisibleTab) | Usually, but it depends on capture timing and on the implementation | The capture reads the rendered page, so the overlay may be included — or may be missing if the capture ran before the mask was applied. |
| Operating-system screenshot (Win+Shift+S, macOS Cmd+Shift+4) | Not guaranteed | The capture happens at the operating system's frame-buffer layer, while the extension works in the page's DOM, so the extension does not control what the OS captures. |
| Third-party recorder (OBS, Loom and similar, in screen-capture mode) | Not guaranteed | The recording path can bypass the browser's render compositor and read the screen directly, which means the overlay is not part of the frames it receives. |
| External camera or phone photographing the screen | Not guaranteed | The camera records light emitted by the monitor; the extension changes page pixels, not the physical display output, so the photograph captures whatever the panel is showing. |
| Meeting app sharing the entire screen instead of a single tab | Not guaranteed | Whole-screen sharing can include other windows and system notifications that sit outside the masked page, and the extension cannot reach anything outside the browser. |
CrispGuard's masking is a visibility control at the page layer, not screenshot prevention. If you need hardware-level capture blocking, use the security display mechanism your operating system or platform provides, not a browser extension.
Two practical consequences follow. Assume the mask is absent from any capture you have not tested. And the test is cheap: take one screenshot with the tool you actually use, on a page you have actually masked, and look at the result.
How the site-lock PIN is stored — a trust signal you can check
The site-lock PIN is stored as a salted hash, never as plain text. Someone who reads the extension's local storage gets a value they cannot type back into the unlock prompt. Settings stay a normal interface; the PIN is only requested at unlock.
The site lock is a PRO feature: it asks for a PIN before it will lift protection on a site you have locked. What the extension keeps is a salted hash of that PIN — the PIN passed through a one-way function together with a random value — rather than the PIN itself. Reading the extension's local storage therefore does not hand over a usable secret. The salt matters too: two installations using the same PIN produce different stored values, so the data does not reveal that the PINs match.
This is a small decision worth weighing, because it is checkable. A product that stores a PIN in plain text is telling you something about how it thinks about storage; one that stores a hash is telling you it assumed the storage would eventually be read by someone. Neither choice makes a product trustworthy on its own, but the second is the one you want in a tool that sits on every page you open.
What hashing does not do is equally worth stating. It protects the stored value, not the unlocked state: if a site is already unlocked and someone is standing behind you, they are reading the page, not the hash. A short numeric PIN is also guessable given enough attempts, and a hash says nothing about how many attempts are allowed. Hashing answers one question — what does an attacker learn from reading this file — and it answers that one well.
If you're deciding whether to trust a screen-privacy extension, what should you check?
Five checks settle most of it: what the privacy policy says about transmitting page content, where the masking actually happens, which permissions were requested, whether auto-detection waits for a click, and whether the product admits its limits.
None of these require technical skill to run. They require reading a policy and a permission list — a reasonable amount of work before handing a tool the ability to read every page you open.
- Does the privacy policy say, in those words, that page content, screenshots and browsing history are not transmitted? A policy that names those three categories makes a falsifiable statement; one that only says it "respects your privacy" does not, and a statement you cannot falsify cannot be checked later.
- Is the masking done in a content script or page layer, or does the content have to reach a server first? The answer determines whether "local" is a property of the architecture or just a word in the description — and only the first survives a network outage.
- Does the extension request permissions that have nothing to do with masking — clipboard access, request interception, site access far beyond what the feature needs? Every permission is a capability that exists whether or not the current version uses it, so the list is a statement about what could happen, not only about what does.
- Does automatic detection run only when you trigger it? A feature that scans every page by default has a different privacy posture from one that waits for a click, even when both produce the same result on screen.
- Does the product state its limits — "not a security product", "does not stop OS-level screenshots" — or does it promise capture blocking? A vendor that names its boundary has usually thought about where the boundary is; a vendor that claims everything is either mistaken or selling something.
This is not a scorecard, and this page will not fill it in on CrispGuard's behalf. Where a point cannot be confirmed from public documentation, treat it as unconfirmed and read the privacy policy. That is the honest version of the answer, and the only version that stays true after the next release.
Frequently asked questions
Does CrispGuard send my page content to a server?
The masking path does not need to. Matching happens in the content script against a keyword list stored with the extension, and the replacement is drawn in the page itself, so no step in that path uploads the page. Whether the extension makes other network requests — licence verification, for example — is defined by its privacy policy, and that is the document to check.
I used my system screenshot tool — is the mask still there?
Not guaranteed. A system screenshot reads the operating system's frame buffer, while the extension only changes what the browser renders, so whether the mask appears depends on the capture path rather than on the mask being switched on. If the capture goes through the browser's rendered output, the mask is usually included.
Will a screen recorder capture the mask?
It depends on the recorder's capture mode. Tools that read the rendered page or the browser's compositor usually include the overlay; tools that grab the screen at operating-system level can bypass it entirely. There is no setting in CrispGuard that changes this, because the limitation is in the capture path, not in the extension.
If I forget the site-lock PIN, does the extension expose it in plain text?
No — only a salted hash of the PIN is stored, so reading the extension's local storage does not reveal the PIN. That protects what is stored, not what someone can see: if the site is already unlocked and somebody is looking at your screen, the PIN is irrelevant.
Can a screen-privacy extension replace a privacy filter?
No. A privacy filter narrows the viewing angle of the physical display, so people beside you cannot read it at all, while an extension only changes pixels inside the browser. A filter also covers everything on screen — other apps, notifications, a video call — which a browser extension cannot reach. This is what the boundary statement above means: a page-layer control is not screenshot prevention.
If I really need to prevent screenshots, what should I use?
A platform mechanism, not a browser extension. Android's FLAG_SECURE, DRM-protected playback paths and managed-device policies that disable capture all work at the operating system or platform layer, which is the layer a screenshot actually passes through. For most shared-space situations, a privacy filter plus turning the screen away is the practical answer.