What is zero-knowledge encryption?
For cloud photos, “zero knowledge” commonly describes keeping the content-encryption secret with the user rather than the provider. MOC’s Android backup path derives a media key on the device from your account email and private passphrase, encrypts content locally, and uploads ciphertext. It does not upload the passphrase as part of that path.
This term is not a formal zero-knowledge proof, a claim of anonymity, or a certification. The service still handles account information and operational metadata. The security of the design depends on the passphrase, client, device, and implementation.
What the code establishes
Authenticated encryption before upload.
120,000 iterations; account-email-derived salt.
Generated locally and encrypted before upload.
Independently authenticated video chunks, with a whole-file compatibility path.
The same account email and passphrase reproduce the media key on another supported device. The server also receives a passphrase fingerprint used for verification and can store an optional hint. Those are not the plaintext passphrase, but a fingerprint is not a substitute for password-hard key derivation.
A strong passphrase is essential
The current client accepts a minimum of six characters, one uppercase letter, and one number. That is a minimum acceptance rule, not our recommendation for strong security. Use a substantially longer, unique, randomly generated passphrase and store it outside this phone. A 256-bit cipher does not turn a weak secret into 256 bits of protection.
The reviewed fingerprint is a truncated SHA-256 digest of the passphrase. A party that obtains it may be able to test guesses without running the media key’s PBKDF2 step. This is another reason not to use a short or predictable secret. No claim of resistance to every offline-guessing attack is made.
Passphrase, PIN, and pattern are different
MOC creates a text media passphrase. Android’s optional biometric/device-credential path can use a fingerprint or the device’s PIN, pattern, or password on supported versions. The device credential does not replace the passphrase needed to derive the media key on a new device.
Someone takes your phone: the device boundary
If the phone is unlocked, someone may see the original photos in the system gallery or access an already-open MOC session. The reviewed startup code allows a valid remembered passphrase to open the gallery directly. It does not establish a fresh app-unlock requirement on every launch.
The remembered passphrase and background-backup credentials are protected locally using Android Keystore-backed encryption. A separate biometric-gated key path also exists. The ordinary remembered-key path is not conditioned on a fresh biometric authentication. Do not treat the biometric option as a guarantee that every startup requires it.
The app also keeps decrypted cloud media in an app-private disk cache after viewing. That cache relies on the app sandbox and the device’s own storage protection; it is not always stored as MOC media ciphertext. Local gallery originals remain outside the encrypted cloud-copy boundary.
Keep a strong device lock and use Android’s lost-device controls if the phone goes missing. No hidden-vault, plausible-deniability, duress-mode, remote-wipe, or anti-forensic guarantee is claimed for MOC.
What screenshot protection means
The release client can apply Android’s FLAG_SECURE when screenshot protection or hidden previews are enabled. The setting is configurable; defaults may depend on stored or remote configuration. This is a capture restriction, not protection against an external camera or a compromised device. Debug builds do not apply the same restriction.
What if you lose your passphrase?
The app says support cannot restore it. Starting again with a new key does not decrypt old uploads. A key-fingerprint export document does not contain the passphrase. Keep the actual secret in a trusted password manager or another secure place outside the phone, and test retrieval before relying on backup.
Metadata and telemetry are separate
The backup protocol handles data such as file kind, sizes, identifiers, encryption format, and nonces. The service also processes account and device information. The published privacy policy discloses diagnostics, usage events, and advertising attribution through Singular. Photo-content encryption does not mean the service has no information about you.
Read the published privacy policy →
Sharing and recovery features are not assumed
Recipient-encrypted albums, expiring links, and a recoverable secret escrow were not established in the reviewed Android flow. Decrypting a photo and sending it through another app is a different operation from keeping it end-to-end encrypted within a shared vault.
What this review does not prove
The maker supplied local Android source for this review. We did not independently audit the backend, confirm exact equivalence with every installed release, perform a penetration test, or establish any compliance certification or public open-source license. Changes to code or configuration can change the behavior described here.
Basis for this explanation
Client paths reviewed include media encryption, chunked encryption, backup upload and retrieval, key setup and verification, remembered-key storage, startup navigation, app-lock fallback, gallery permissions, and decrypted-media cache. This explanation is limited to those paths.
Questions about your setup? → · Compare other photo services →