🔒Credible Encryption

You don't have to trust us

Credible Encryption is a standard for web apps that encrypt your data in the browser before it ever reaches a server. You don't take the developer's word for it — you verify it yourself.

The idea

Most apps ask you to trust that they handle your data responsibly. Credible Encryption is different: your data is encrypted before it leaves your browser, using a key that only you have. The server never sees plaintext. This isn't a privacy policy — it's a verifiable property of the code.

No one can read your data. Not the developer. Not a hacker who breaches the server. Not the hosting provider. Not Amazon Web Services. Not even the NSA — AES-256 has no known cryptographic weakness, and brute-forcing a 256-bit key would take longer than the age of the universe.

Any app that adopts this standard derives an encryption key from your password using PBKDF2 (100,000+ iterations, SHA-256) and encrypts sensitive fields with AES-256-GCM client-side. The key stays in your browser. The server stores ciphertext it cannot read.

What qualifies

An app meets the Credible Encryption standard when:

  1. All sensitive user content is encrypted in the browser before any network request
  2. The encryption key is derived from the user's password and never transmitted
  3. The server only stores and returns ciphertext — it cannot decrypt user content
  4. Anyone can verify this by inspecting network requests in DevTools

Standard parameters

Every CE app uses the same encryption, so verification is universal — not per-app.

Algorithm AES-256-GCM
Key derivation PBKDF2, SHA-256, 100,000 iterations
IV mode Deterministic — SHA-256(plaintext), first 12 bytes
Ciphertext format ENC: + base64(iv + ciphertext)
Key storage localStorage under ce_key

Because the parameters are fixed, a single verification tool works for every CE app. Apps integrate using a small open-source library — ce.encrypt(plaintext) — which handles both the encryption and the communication with the verification extension.

What's typically encrypted vs. visible

Encrypted (unreadable to server)

  • User-created content (names, text, entries)
  • Relationships and labels between items

Visible (structural metadata)

  • Number of items and connections
  • Numeric scores or settings
  • Account email and timestamps

Each app's specific encrypted vs. visible fields may vary, but the principle holds: your words are yours. The server sees structure, not meaning.

How to verify

  1. Open your browser's DevTools (F12 or Cmd+Opt+I)
  2. Go to the Network tab
  3. Use the app normally — create or edit something
  4. Inspect the request payload — you should see ciphertext (e.g. ENC:...) where your content should be
  5. Check Application > Local Storage — that's where the encryption key lives, never sent to the server

No special tools needed. Every browser has this built in.

Honest trade-offs

Credible Encryption is upfront about what it does and doesn't protect.

Deterministic encryption. Some apps use deterministic IVs so the server can match encrypted values without decrypting them. This means the same input always produces the same ciphertext — useful for lookups, but it means an attacker with your key could confirm whether a specific value exists.
Password loss = data loss. There is no recovery backdoor. If you lose your password, your encrypted data is gone. This is the point — no one else can recover it either.
Metadata is visible. Structural metadata (counts, scores, timestamps, graph shape) is typically unencrypted. The server knows how much data you have and how it's connected, but not what it says.

Plaintext manifest

Some apps need to send specific data in plaintext to function — an email address for authentication, a prompt for an LLM call. Credible Encryption doesn't require zero plaintext. It requires zero ambiguity.

Every CE-certified app publishes a plaintext manifest: a complete list of every unencrypted field, who receives it, and why. Encryption is the default. Plaintext is the exception, and every exception is declared.

Here's what a manifest looks like:

Field Status Recipient Reason
task names encrypted app server Core user content
relationships encrypted app server Core user content
email plaintext auth provider Account identity and recovery
scores plaintext app server Sorting and ranking (no user words)

If a field isn't in the manifest, it shouldn't be leaving the browser. If it's leaving the browser unencrypted, it must be in the manifest. That's the contract.

Badge

Apps that adopt Credible Encryption can display a badge linking back to this page.

🔒 Credible Encryption 🔒 Encrypted

Embed it with a single line of HTML:

<a href="https://credible-encryption.aisloppy.com" style="display:inline-flex;align-items:center;gap:6px;padding:6px 12px;background:#0a0a0a;border:1px solid #2a5a2a;border-radius:6px;color:#4ade80;font-size:13px;font-family:system-ui;text-decoration:none">🔒 Credible Encryption</a>

Trust model

The badge is a claim by the developer. Verification is your responsibility.

The code is already on your machine. Client-side JavaScript is delivered to your browser in full. There's no binary, no compiled blob — you can read every line. Open DevTools, go to Sources, and the encryption logic is right there.

The network doesn't lie. Your browser's Network tab shows every byte sent to the server. If a field contains ENC:... ciphertext, that's what the server received. No server-side process can change what your browser sent.

The key never leaves. Confirm in the Source tab that the encryption key is derived locally and stored in localStorage. If it's never in a request payload, the server can't have it.

Automated verification

Manual inspection works but doesn't scale. A browser extension can verify the contract continuously and cryptographically — not by observing the app, but by participating in the encryption.

When a CE app encrypts a field, the library sends the plaintext to the extension via postMessage before encrypting it. The extension then:

  1. Receives the plaintext from the app via postMessage
  2. Reads the key from localStorage (ce_key)
  3. Encrypts it independently using the standard CE parameters
  4. Adds the result to a whitelist of ciphertext tokens the app is allowed to transmit
  5. Monitors all outgoing requests — scans every request body for registered plaintext strings or non-whitelisted content

This catches everything:

App sends plaintext in a request? The extension has the plaintext in its registry — it sees the match in the raw request body. Red X.

App encrypts with a different key? The ciphertext won't match the extension's independently derived version. Red X.

App leaks plaintext to a hidden field? The extension scans the entire request body, not just declared fields. Red X.

App sends data to an undeclared domain? The Content-Security-Policy header restricts connect-src to declared domains. The browser itself blocks it.

Extension not installed? The app works normally. The postMessage goes nowhere.

Not a trust exercise — a math check. The extension re-derives the expected ciphertext and confirms the app produced it correctly. If anything doesn't match, you see it immediately.