Once a screen has been photographed or screenshotted and shared externally, the data is out. The only useful question that remains is: who produced it? Without that answer, the incident becomes an unsolvable mystery — and the absence of consequences becomes its own incentive for the next leak.
The traditional answer — a visible watermark with the user's name on screen — works as a deterrent. But cropping or photographing just the part without the watermark removes it. The user knows this; the deterrent value erodes.
Modern attribution needs two layers. A visible mark that makes the user feel identifiable, plus an invisible mark embedded into the actual pixel data that survives the obvious attacks on the visible one. ZeroLeak adds both: the visible mark deters casual leaks, the invisible mark catches the careful ones.
Both watermark layers are applied at the same point: in the noVNC viewer that the user's browser receives. Neither layer lives in the protected web application's DOM, so no website can interfere with them and no front-end policy can strip them. The visible layer is configured per protected service; the invisible trace ID is generated per session.
Username, session ID, or custom text is overlaid on the rendered page using mix-blend-mode so it stays visible on both light and dark content. The user knows they are personally identifiable on every screen they see — a strong, ever-present deterrent against casual screenshotting.
A session-unique pattern is written into the actual pixel data of every frame the user sees. It is engineered to survive cropping, scaling, JPEG re-compression, and re-photographing. When a screenshot turns up later, the embedded ID identifies which session produced it — even if the visible watermark was cropped out first.
The visible watermark supports up to three independent layers, each with its own text, position, rotation, font, opacity, and tile size. Combine a diagonal username, a centred session ID, and a corner timestamp to make the visible mark much harder to crop around without losing useful screen area.
Cropping out the visible watermark, scaling the image down for a chat client, photographing the monitor with a phone — the invisible trace ID survives all of these because it is part of the pixel data itself, not an overlay. Decoding the trace ID from a recovered image identifies the session.
Each item below is independently configurable per protected service. Use the visible layer alone for low-sensitivity content where deterrence is enough; combine both layers for high-sensitivity content where attribution must be possible.
The visible watermark text is composed at session start from the authenticated user identity, the session ID, the timestamp, or any combination chosen at policy time. The watermark on screen reflects the specific person watching, not a generic logo.
The watermark uses mix-blend-mode that inverts against the background colour. A watermark that would normally be invisible on a black or white page stays readable everywhere — the eye sees a consistent mark regardless of what the page shows underneath.
Up to three visible layers can be configured together. Each layer has its own text, colour, opacity, font, rotation, tile size, and position. Layers can be diagonal repeating, centred, or anchored to a corner — combine them so that cropping the screenshot to remove one layer still leaves the others.
A session-unique trace pattern is embedded into the rendered frames the user sees. The embedding is engineered to be robust under common screen-leak attacks — cropping, downscaling for messaging apps, JPEG re-compression, and re-photographing the monitor with a phone camera all preserve enough of the trace pattern to recover the session ID.
When a leaked image is found, the operator runs it through the decoder. The decoder reads the embedded trace pattern and returns the session ID that produced it. The operator looks up the session in the audit log to find the user identity, timestamp, and protected service involved.
Both watermark layers are applied in the noVNC viewer that the user's browser receives, not in the protected application's DOM. The protected application has no awareness of the watermark and cannot interfere with it. Front-end frameworks, trusted-HTML policies, browser extensions on the protected app's side — none of them can strip the mark.
Different leak channels degrade the leaked image in different ways. The invisible trace ID is engineered against realistic attacks; it is honest about what it can and cannot recover from.
An attacker crops the screenshot down to just the data region they want, removing all visible watermark text. The invisible trace ID is distributed across the entire frame and survives the crop — recovering a moderate-sized region of the original frame is enough to decode it.
Most messaging apps downscale and JPEG-recompress shared images. The trace pattern is engineered with redundancy that survives common downscale ratios and JPEG compression artifacts.
An attacker who does not want to leave file-system traces points their phone at the screen and takes a picture. The trace pattern is designed to survive optical capture — phone-camera photographs preserve enough of the spatial frequency information that the decoder can still find the session ID.
An attacker who only leaks a very small portion of the screen — a single sentence or single number — reduces the amount of trace pattern available. The decoder reports lower confidence on small regions, and at the extreme end the trace becomes unrecoverable. An honest limit — not every leak is attributable.
An attacker who runs the leaked image through a heavy Gaussian blur, a generative AI image filter, or hand-redraws the visible content can destroy the trace pattern along with much of the original information. At that point the leaked image is no longer a faithful copy of what was on screen — attribution is not the only thing lost.
Pre-IPO documents, M&A materials, trading positions — high-value information read by many people before public disclosure. When a leak appears in the press, identifying which session it came from is the difference between an unsolved incident and an actionable investigation.
Healthcare staff legitimately read patient data on screen. When a leaked patient record appears externally, the visible watermark deters casual leaks, and the invisible trace ID identifies the session if a leak does occur — supporting HIPAA accountability for view-only roles.
Analyst desks where multiple people see the same classified content. Per-user marks make individual accountability concrete; the invisible trace ID makes investigations possible when a leak surfaces in open-source intelligence.
External parties granted view-only access into your environment. The visible per-user mark on every screen reminds them they are identifiable; the invisible mark makes it provable if a leak appears in their downstream network.
See ZeroLeak's forensic watermark in a live demo. We will run a session, take a screenshot, crop it, downscale it, photograph it from a monitor — and decode the trace ID back to the session each time.