Client-side encryption versus server-side encryption

Server-side encryption

With server-side encryption, a service commonly receives readable content over an encrypted network connection and encrypts it for storage on its own infrastructure. This protects stored disks and backups from some physical or operational threats, but the service can generally decrypt the content to provide features.

Transport encryption such as HTTPS is essential, yet it protects the connection rather than deciding whether the receiving service can read the payload.

Client-side encryption

With client-side encryption, supported content is encrypted on the user's device before the cloud storage request is made. The storage provider receives encrypted bytes, and an authorized client later downloads and decrypts them locally.

In SovaSpace, this applies to supported Entry content, attachments and separate supporting files such as subtitles and annotations stored as encrypted objects in the customer's Google Drive. NURSOVA's service layer coordinates limited account, device, entitlement and synchronization information without being designed as the plaintext content store.

Client-side encryption versus ordinary cloud sync

Cloud sync describes how copies move between devices and a service; it does not by itself say who can decrypt those copies. A conventional sync service can use HTTPS in transit and server-side encryption at rest while still retaining the technical ability to process readable content for indexing, collaboration, support or other service features.

Client-side encryption changes that trust boundary. Supported content is protected before the storage request, so the cloud-storage copy is encrypted independently of transport security. This does not make synchronization anonymous, eliminate provider metadata or protect an already unlocked endpoint.

When comparing products, ask where encryption occurs, who controls the decryption material, whether exported files remain encrypted, which metadata is still processed and how recovery works if a device or key is lost. “Encrypted sync” is not precise enough to answer those questions.

What client-side encryption protects

The model is intended to prevent a cloud object from revealing readable user content without the required keys. It reduces the need to trust the storage location with plaintext notes, documents and media.

Authenticated encryption also helps the client detect unauthorized changes to protected object data rather than accepting altered bytes silently.

What remains visible

Encryption does not make the system metadata-free. Depending on the provider and operation, visible facts can include:

• Google account identity and authorization state;
• object existence, approximate size and timing;
• device, session and network information;
• encrypted object identifiers and operational counts;
• subscription and transaction status; and
• error categories needed to operate and support the service.

The SovaSpace Security model describes the current product boundary rather than using “zero knowledge” as an undefined slogan.

Endpoint risk remains

An authorized device must eventually display readable content. Malware, a keylogger, screen capture, an unlocked operating-system session or physical control of that endpoint can expose what the user can see.

Client-side encryption is therefore one layer. Device encryption, operating-system updates, secure account recovery, trusted-device review and physical security still matter.

Exports change the boundary

When a user exports plaintext Markdown, PDF, an attachment or another readable copy, that file is protected by the destination device and application rather than by the SovaSpace encrypted object format.

Users should review the export location, backup system and sharing channel before treating the copy as private.

Encryption is not backup

An encrypted object can still be deleted or become unavailable. Keys can also be lost. Confidentiality and availability must be planned separately.

Ask two questions: “Who can read this copy?” and “What other tested copy exists if this one disappears?”

The private workspace backup plan turns the second question into a repeatable checklist.