“End-to-end encrypted” is useful only when the ends and the threats are named. For a protected Inpages.me Memory, one end is the owner's unlocked browser. The server stores and returns ciphertext. That boundary reduces several serious risks, but it does not turn a web application into a trusted device.
Start with assets and adversaries
The primary protected assets are a Memory's title, rich-text body, external-link values, keepsake files, and inline-image bytes. The key asset is the 256-bit Master Key held by an unlocked browser. The system is designed to limit disclosure when someone obtains server-side stored data without also controlling that browser.
The model considers several different events rather than collapsing them into “a hack”:
- a database dump is copied;
- the Active Storage volume is copied;
- an operator inspects protected records through normal server tools;
- a password-derived encrypted Master Key is exposed;
- malicious JavaScript runs in the Inpages.me origin;
- a browser extension or device is compromised; or
- the owner deliberately publishes a Standard Memory.
Those events do not have the same outcome. Treating them separately is how we avoid giving one lock icon more meaning than it deserves.
What client-side encryption reduces
Reduced
Database disclosure
Protected fields remain AES-GCM ciphertext in the database. A dump does not contain their plaintext or the usable Master Key.
Reduced
File-storage disclosure
Protected file and inline-image bytes are encrypted before Active Storage receives them. A copied volume contains opaque blobs.
Reduced
Routine server access
Rails has no normal code path that decrypts a protected Memory. Operational access alone is insufficient to render its writing.
The encrypted Master Key stored by the server is useful only after a browser derives the correct KEK from the vault password. Argon2id raises the cost of offline password guessing, but it cannot make a weak password strong or guarantee that future parameters remain appropriate forever.
Transport encryption still matters. HTTPS protects requests, cookies, metadata, and application code in transit. Client-side encryption is not a substitute for TLS; it changes what the application sends inside that protected connection.
What it does not solve
Not protected
Malicious same-origin JavaScript
An XSS payload running after unlock can read page content or call the same browser APIs that legitimate code uses.
Not protected
Compromised device or extension
Malware, browser extensions, screenshots, clipboard access, and physical observation operate at or beyond the trusted endpoint.
Not protected
An already unlocked session
A person using an unlocked browser can read what its owner can read. Encryption at rest does not replace device locking or session hygiene.
Inpages.me currently persists the unlocked Master Key in per-account localStorage for convenience across page refreshes. Logout and explicit vault locking remove it. This choice avoids asking for a password on every navigation, but it increases the consequence of XSS or a malicious extension while the key is present.
Content Security Policy, output sanitization, dependency review, and narrow logging reduce parts of this risk. They do not prove that arbitrary browser code can never execute. The OWASP threat-modeling guidance is useful here because it treats security as a repeatable analysis, not a one-time label.
The metadata boundary
The service must still route requests, authorize records, retain storage references, and operate accounts. As a result, encryption does not hide the existence of an account, Journal, or Memory from the service. Depending on the feature, operational data can include identifiers, timestamps, record relationships, protection state, attachment counts, file sizes, filenames, content types, and hashtags.
Filenames and content types deserve special care. Encrypted file bytes use the generic application/octet-stream type for storage, but display metadata can still be needed for a browser to reconstruct the experience. A private-content claim must therefore distinguish the protected bytes from the surrounding record.
This is why we do not describe Inpages.me as invisible to its own server. The more precise statement is: for a protected Memory, the server does not receive the plaintext title, body, external-link values, or protected file bytes. See the practical journal metadata guide for questions a non-technical reader can ask of any journaling product.
Availability is a separate problem
Encryption can preserve confidentiality while making recovery harder. If a person loses both the password needed to unlock the EMK and the exported Recovery Key, support cannot reconstruct the Master Key. That is a property of the boundary, not a support policy that can be overridden later.
Backups solve a different class of failure. They can preserve ciphertext, encrypted files, the EMK, and vault parameters after disk or database loss. They cannot manufacture a missing user-held secret. Conversely, possessing a Recovery Key does not restore a deleted database record or unavailable file blob.
The production backup tooling exists, but the recovery process is not described as operationally proven until a full restore drill succeeds. Confidentiality, integrity, availability, and recoverability need separate evidence.
How the boundary shapes the product
Protected Memories cannot be public. Publishing requires a deliberate transition back to Standard protection because a public reader and search crawler need server-readable content. The interface must make that change visible instead of implying that one piece of content is simultaneously server-unreadable and publicly indexable.
Search, AI assistance, thumbnails, previews, and background analysis also have to respect the boundary. A server-side feature cannot quietly inspect protected text merely because doing so would be convenient. If a feature needs plaintext, it must stay in the browser or require a separate, explicit product decision with accurate copy.
Our standard is not “trust us, it is encrypted.” It is to state which data is transformed, where the usable key lives, which failures are reduced, and which endpoint risks remain. For the mechanics behind that boundary, start with the browser encryption architecture. For a consumer checklist, read how to choose a private journaling app.