Skip to content

Verify Client-Side Encryption

Overview

This guide shows non-technical users how to verify that encryption truly happens client-side in your browser before files leave your computer. A zero-knowledge service encrypts your data in your browser, meaning the provider never sees plaintext—only encrypted ciphertext.

This verification takes about 15 minutes using only your browser's built-in tools.

Why This Matters

A service claiming "zero-knowledge encryption" means:

  • Your files or secrets are encrypted in your browser before they leave your computer.
  • The company never sees plaintext—only ciphertext (random data).

If encryption happens server-side, the provider could decrypt it. This guide teaches you how to see that encryption really occurs before upload.

What You Need

  • Chrome, Edge, Brave, or Firefox (desktop version)
  • A free or test account in UnoLock
  • A small text file (e.g., test123.txt) containing obvious text like: 
    Hello, this is my secret.
  • About 15 minutes

Step 1: Open Developer Tools

  1. Visit https://safe.unolock.com and log into your vault.
  2. Right-click anywhere on the page and select Inspect.
  3. In the DevTools panel, choose the Network tab.
  4. Enable "Preserve log" so traffic isn't cleared when pages change.

Step 2: Start Recording and Upload a File

  1. Ensure the Network tab is recording (red dot active).
  2. Upload your sample file to the vault (or create a note with the text).
  3. Wait until the upload finishes, then review the recorded requests.

You'll now see many requests in the Network list.

Step 3: Find the Upload Request

  1. In the search box above the request list, type upload, file, or api.
  2. Click the request that looks like the file upload (often a POST or PUT request).
  3. Select the Payload tab (in Firefox it may be labeled Request Body).

Step 4: Inspect What Was Sent

Look at the payload contents:

  • ✅ Good: You see gibberish (long random text, base64 strings, or binary bytes like JFk4s9ds/7x...)—this is ciphertext.
  • ❌ Bad: You can still read Hello, this is my secret.—this is not encrypted client-side.

The contents should look like pure entropy: no words, no filenames, no JSON fields named "content".

Step 5: Check Filename and Metadata

Still in that request:

  • Filename should be hashed (e.g., 7e2a9d6f...) or absent entirely.
  • Headers may include Content-Type: application/octet-stream or binary/octet-stream—that's a good sign.
  • There should be no readable text in either the request URL or body.

Step 6: View Response Headers (Optional)

Select the Headers tab and confirm:

Request Method: POST
Status Code: 200

If the server only responds "OK" without echoing your plaintext back, that's good. If the server response body contains your text file contents, it's not zero-knowledge.

Step 7: Spot-Check with Another File

Repeat Steps 2–6 using a different file or secret. Ciphertext should change completely each time (due to encryption randomness). If it looks identical each time, that's a weak sign indicating non-random encryption.

Step 8: Entropy Test (Advanced, Optional)

  1. Copy a small chunk of the Payload data (around 1 KB).
  2. Paste it into an entropy calculator such as https://www.browserling.com/tools/entropy.
  3. A score above 7.5 bits/byte indicates strong randomness—typical of real ciphertext.

Step 9: Confirm No Plaintext Storage Locally

  1. In DevTools, go to the Application tab.
  2. Check Local Storage and IndexedDB.
  3. Make sure your secret text isn't stored there in clear. Zero-knowledge apps keep only random tokens, not actual content.

Step 10: Document What You Found

Create a simple record:

Check Result Notes
Payload unreadable ✅ / ❌
Filenames hidden ✅ / ❌
No plaintext in local storage ✅ / ❌
Randomness high ✅ / ❌

Keep screenshots—they're useful evidence if you later audit or report results.

What "Good" Looks Like

  • Upload request shows random bytes (ciphertext).
  • No readable content anywhere in network tab.
  • No plaintext remnants in local storage.
  • Every upload looks different.

What "Bad" Looks Like

  • Your text or filename appears in the upload payload.
  • The server echoes your data back.
  • Plaintext stored in browser storage.
  • Identical ciphertext across uploads.

Optional Deeper Checks (For Technical Users)

  • Use Fiddler, Burp Suite, or mitmproxy with your own test cert to intercept HTTPS locally (never do this with real secrets).
  • Confirm ciphertext before TLS encryption is identical to what you saw in the browser.
  • Compare with open-source zero-knowledge tools (Tresorit, Proton Drive) for baseline behavior.