6 min read
Read-only sharing: verify the evidence and test the watermark
A security claim should be open to examination. We publish tools for verifying document issuance evidence, testing read-only access and measuring watermark resilience. The results also include transformations that erase the mark.
Four questions you can check
Can the contractor access the original?
Viewing grants access to the pages of the contractor's encrypted copy. The HTTP test checks denial of access to the original, keys and revoked or expired copies, with an owner access check as a positive control.
Has the file changed?
The verifier recomputes the file's SHA-256 hash and compares it with the manifest signed at issuance. Changed bytes no longer match that reference.
Has the journal been rewritten?
Events are linked by their hashes. A timestamped checkpoint, retained outside the server before a compromise, lets you compare the retained state with the journal supplied later.
Does a capture match an issued copy?
The detector searches for the invisible pattern associated with a copy. A match provides evidence about that pattern. It does not prove which person disclosed the document.
A practical example: detecting a change
You issue a PDF copy to a contractor. Its manifest contains the original's hash and a passkey signature. Later, a file presented as that original contains a change. The verifier recomputes its hash: the comparison fails. It also checks the signature so a manifest replaced along with the file is not simply accepted.
If the server is compromised, an attacker can recompute a hash chain. Verification therefore also relies on a checkpoint retained independently before the incident and timestamps checked against an independently chosen trusted authority. Downloading a new checkpoint after the incident does not establish the earlier state.
What the public tests actually run
- Generated and verified ES256 signatures and RFC 3161 timestamp responses, followed by attempts to alter the file, manifest, signatures and tokens.
- Changed, rewritten and truncated journals, duplicate sequences and comparison with a retained checkpoint.
- An actual Chrome screenshot at 100%, crops, JPEG encoding, resizing, rotation, contrast changes and watermark erasure.
- An HTTP tool for a prepared test environment, using distinct owner and contractor sessions. It also rejects WAF HTML responses and changed page bytes.
Cryptographic tests use an ephemeral local authority for reproducibility. It does not provide independent production time or a qualified timestamp. Local HTTP tests validate the tool; auditing a deployed site requires a separate run with its test resources.
Invisible watermark: results, including failures
The benchmark uses three synthetic 1920 × 1440 pages with white, gray or textured backgrounds and eight candidate copy patterns. No personal document is published. Each count represents correct detections in this sample. Crop percentages refer to the area removed.
Rotation by 2° fails on all three pages. Whitening erases the watermark on white paper; it survives on the other two backgrounds. Recreating pixels from the unmarked source erases the pattern. That test uses no OCR engine and does not represent a measured OCR round trip.
The six negative controls, unmarked pages and analyses with a wrong key, produced no matches. This sample cannot establish a false-attribution probability for all documents. Actual photographs, camera perspectives and collusion attacks remain outside this measurement.
Reference measurement: . Pixel hashes, scores and tool versions.
Limitations to keep in mind
- Displayed content can be captured or photographed even when the original cannot be downloaded.
- An absent watermark does not exclude a copy as the source. A match does not prove the leaker's identity; audit-key holders can also generate patterns.
- A signature establishes key use. This evidence alone does not demonstrate non-exportable hardware key storage or the signer's physical identity.
- The journal proves continuity of the supplied links. It does not prove every possible event, events never recorded or a complete history outside the exported range. The portion after the last timestamped checkpoint is not yet anchored.
How to check for yourself
- Review the public results and the evidence-format specification. Read the specification.
- Download the tool archive. Its instructions let you rerun tests with synthetic data without a PrivCloud account. Download the archive.
- For actual evidence, retain the checkpoint before an incident, independently choose the trusted authority, expected origin and RP ID, then run the verifier in strict mode with your original. Detailed instructions.
Verification of a real document remains local: do not publish the confidential original, test sessions or your team's audit key. The public page and archive contain tools and synthetic data only.