Live Verify: the next logical step up from the iPhone'sLive Text.
TL;DR: For this prototype, Live Verify runs entirely in your browser—OCR, normalization, and hashing stay on-device. During verification, the only network calls are minimal HTTP GET requests to check hashes against certification servers (plus the initial download of the JS libraries listed below).
We expect the same multi-step flow to be embedded directly into iOS and Android camera apps (alongside Live Text / Camera Text) with the same on-device privacy posture.
What Live Verify Does
Live Verify uses native iOS and Android apps to scan text, compute a cryptographic hash,
and verify it against a certification server. The entire OCR and hashing process happens on-device.
A browser extension and email extension also support text-selection-based verification (no OCR needed).
Data Processing: 100% Local
All sensitive operations occur entirely on your device:
Camera access: Native camera APIs capture the document image, which is not saved to your photos and discarded soon after
OCR text extraction: Performed on-device using Apple Vision (iOS) or Google ML Kit (Android)
Text normalization: Character mapping happens on-device
SHA-256 hashing: Computed locally using platform cryptography APIs
Summary: Your document images and extracted text never leave your device to complete verification. They are not uploaded to any cloud OCR service and are not transmitted to certification servers.
Note: the person holding the document is still trusting the verifier (the person using the app) to handle any local copies responsibly. A production deployment could be configured to retain some details locally (or in an approved system) if authorized and legally required.
Verifier roles, logging, and retention
Verification involves two distinct roles:
Document holder: The person presenting the claim. e.g., an ID card or printed (or on screen) credential.
Verifier/operator: The person using a Live Verify app to check it (e.g., a door-person, hotel clerk, employer, bank clerk, law enforcement and many more). The operator is going to hand the ID or printed item back to the document holder after processing it.
This prototype is designed to verify without sending document images or plain text off-device. However, a verifier may still have operational and legal obligations
about what they do with the information that becomes visible during verification.
Example (nightclub door-person): An authorized ID-checking app might log the person’s name, ID number, age-check outcome, and entry timestamp to support safety and incident investigation.
Example (law enforcement): Officers may have access to deeper government systems (e.g., DMV/immigration databases) for in-depth checks beyond what a public hash lookup can provide; logging and retention may be longer, governed by local policy and statute.
Retention: Some deployments may purge such logs after a year; financially important or regulated contexts may retain longer.
It’s also worth noting that parts of the developing world are moving toward fully electronic IDs. In those contexts, a phone tap plus NFC-based ID exchange may become the primary flow,
and can be faster than OCR. Live Verify's scan mode can remain a privacy-preserving fallback for printed documents, screenshots, or situations where NFC is unavailable.
These retention choices are about verifier policy and legal compliance—not about the hash verification protocol. The protocol minimizes what needs to be transmitted,
but it cannot remove the verifier’s responsibility to handle any locally visible or stored data appropriately.
Network Requests: What Gets Sent
Live Verify makes only two types of HTTP GET requests during the verification process:
Future native camera apps: the verification network behavior can stay the same (a minimal GET to the issuer domain), while removing browser-demo specifics
like downloading OCR/image-processing libraries from third-party CDNs.
Request Type
Purpose
Data Sent
Example
Metadata Request
Fetch OCR normalization rules for a domain
None (simple GET)
GET https://example.com/certs/verification-meta.json
Hash Verification
Verify computed hash exists on certification server
SHA-256 hash only (no document content)
GET https://example.com/c/abc123...xyz
What is NOT sent:
Document images or photos
Extracted OCR text (raw or normalized)
Camera feed or video frames
Personal information or identifiers
Geolocation data
Device fingerprints
Important: The SHA-256 hash sent during verification is a cryptographic one-way function. It is mathematically infeasible to reverse-engineer the original document text from the hash. The hash alone reveals nothing about your document's content.
Learn more about the science behind one-way hashing and why such hashes are safe to host publicly (without login) at
one-way-hash.html. At the same time, issuers obviously remain responsible for protecting the plain text documents that underlie those hashes—think PCI-class data separation, strict access control, and logging—so that anyone who could reverse the process still needs the same level of controls you'd expect for any sensitive record.
Third-Party Resources
Live Verify loads the following libraries from CDNs to provide functionality:
PSL (Public Suffix List) (unpkg.com) - Domain parsing for security (browser extension and web pages only)
These libraries are loaded over HTTPS and execute entirely within your browser's JavaScript sandbox. They do not need to transmit your document images or extracted text anywhere to function. If you want to minimize third-party network dependencies and supply-chain trust, you can self-host these assets.
What Live Verify Does NOT Do
Does NOT store scans: No images or text are saved, cached, or persisted
Does NOT upload documents: Your scanned content never leaves your browser
Does NOT track users: No analytics, cookies, or tracking scripts
Does NOT collect personal data: No registration, accounts, or PII collection
Does NOT use external APIs for OCR: All text extraction is local
Does NOT send document content to third parties: This prototype loads JS libraries from CDNs, but verification sends only a hash to the issuer domain
Data Retention
Live Verify has zero data retention:
Images exist only in browser memory during active scanning sessions
Extracted text is discarded when you close the browser tab
No localStorage, sessionStorage, IndexedDB, or cookies are used
Camera access is released when you stop the camera or close the tab
Browser Permissions
Live Verify requests the following browser permissions:
Future native camera apps: permissions would be handled by the OS (camera permission in Settings), and the “clipboard” concept may not apply at all.
Camera access: Required to capture document images (you must explicitly grant this)
Clipboard write: Used when you click "Copy Hash" or "Copy Image" buttons (optional)
When you close the tab, the page can no longer access your camera. Your browser may remember your allow/deny choice for this site until you change it (some browsers offer
“allow once” / session-only permissions, and some may automatically reset unused permissions after a period of time). You can always review or revoke permissions in your
browser’s site settings.
Open Source Transparency
Live Verify is fully open source under the Apache-2.0 license. You can:
Run your own instance on localhost or private servers
Audit the code to confirm this privacy declaration
Verification Server Privacy
When you scan a document, Live Verify connects to the domain specified in the document's verification URL (e.g., verify:example.com/path). The privacy practices of that certification server are:
Not controlled by Live Verify - Each organization runs their own server
May log HTTP requests - Standard web server behavior (IP address, timestamp, user agent)
Receive only the hash - No document content is ever transmitted
Even though only a hash is sent, logging can still create privacy risk: if a national authority (or any operator) controls or monitors the verification domain, it could log hash lookups and infer that your ID was likely presented to a particular verifier at a particular time—e.g., a hotel chain that serves Nepalese cities and tourist locations—and therefore that you are likely (or that someone using a stolen copy of your ID) in Nepal.
This is not a weakness in hashing; it’s ordinary web request metadata. If that risk matters in your context, issuers can mitigate it with careful server-side logging policies, legal controls, and—where appropriate—privacy-preserving proxying or aggregation.
For questions about a specific verification server's privacy practices, contact the organization that issued the document.
Security Considerations
While Live Verify protects your privacy, users should be aware:
HTTPS required: Verification URLs are automatically upgraded to HTTPS to prevent interception
No server-side trust: Live Verify trusts the certification server specified in the document URL
Client-side only: Security depends on your browser's integrity and isolation
Questions or Concerns?
If you have questions about this privacy declaration or how Live Verify handles your data: