Encrypting a photo before upload protects its bytes from ordinary storage inspection. It does not erase all metadata, and it does not help if another part of the upload pipeline creates a readable preview, analysis result, or derivative before the encryption boundary.
Protect bytes before upload
When a Memory uses Encrypted writing & files, the browser reads each selected file, encrypts it with the local Master Key and a fresh initialization vector, and uploads an application/octet-stream blob. Active Storage receives ciphertext bytes rather than an ordinary JPEG, video, or document. The file-encryption implementation note follows that pipeline.
Do not analyze opaque files as media
Storage frameworks commonly inspect uploaded media to extract dimensions, identify content types, generate variants, or create previews. Those jobs assume they can read the original bytes. Inpages skips analysis for encrypted binary blobs because attempting to inspect them would either fail or encourage a server-side plaintext path that conflicts with the protection boundary.
Previews can become plaintext copies
A server-generated thumbnail, OCR result, transcription, or machine-learning label is a new readable artifact. Encrypting the original after such a derivative already exists does not protect that derivative. A private upload design must account for every stage, including temporary files and retry behavior, not just the final object-store blob.
Metadata remains a separate boundary
Encrypting bytes does not erase all metadata. Attachment rows, record relationships, file counts, sizes, and parts of the display contract can remain operationally visible. Inpages does not claim otherwise. The metadata privacy case study explains why small surrounding facts can still be meaningful.
Decryption belongs at the owner endpoint
To display a protected attachment, the browser fetches the opaque blob, decrypts it in memory, and renders a local Blob URL. Rails does not need to reconstruct a plaintext copy for a preview. That keeps the media-readable endpoint aligned with the owner who holds the unlocked Master Key.
Review the complete media path
Test a protected attachment from selection through upload, reload, rendering, deletion, backup, and export. Inspect server logs, background jobs, temporary storage, and derivatives as well as the database. The right claim is not “files are invisible”; it is that protected file bytes are opaque to the server, while remaining metadata and endpoint risks are named explicitly.