How DeepMirror protects your CV without publishing your private context

A CV can contain much more than a work history.

It may include your name, location, contact details, employers, education, career gaps, professional ambitions, and clues about your personal circumstances. A reflective check-in can be even more sensitive: it may describe uncertainty, conflict, relationships, or a decision you have not shared with anyone else.

It is reasonable to ask:

What happens when I share this information over the internet? Does it become publicly discoverable, or is it kept private?

DeepMirror protects stored CVs, cloud-saved check-ins, and related covered personal records with application-level envelope encryption backed by Google Cloud Key Management Service.

A person who obtained only the relevant database records would not receive readable CV or reflection text. The cryptographic keys needed to decrypt protected records are stored separately, and their use is restricted through the application’s cloud identity.

At the same time, DeepMirror can use the information you intentionally provide to support personalized career matching. Privacy and usefulness are not opposites: information does not need to become a public profile before it can be useful.

Private matching is different from public discoverability

Professional networking platforms and private career tools serve different purposes.

A social professional profile is intended to help other people discover you. Depending on your settings, profile information may be visible to signed-in members, public search engines, people who are not signed in, or permitted external services.

LinkedIn provides controls for limiting this visibility, so not every LinkedIn profile is public. Its documentation nevertheless explains that eligible public-profile sections may appear in search engines and that changes can take weeks or months to be reflected by those search engines. LinkedIn also says profiles are generally visible to signed-in members, subject to settings and specific exceptions.

That visibility is not necessarily a security failure. Discoverability is part of what a professional network is designed to provide. It is simply a different privacy model.

Socially discoverable profile	Private DeepMirror context
Designed to be seen by other people	Designed for an authenticated personal experience
May be searchable by name, employer, skills, or other profile fields	Not published as a searchable member profile
Selected sections may appear in external search results	Covered stored content is application-encrypted
Viewers can read, remember, copy, screenshot, or redistribute visible information	A database record contains ciphertext rather than readable CV text
Usually presents a curated professional identity	Can include private preferences, reflections, and uncertainties
Visibility is part of the product’s value	Confidential processing is part of the product’s value

The important distinction is between publication and permissioned processing.

Publication makes information available to an audience. Once another person can see it, technical controls cannot prevent every screenshot, copied note, downloaded document, or remembered detail. Even after visibility settings change, previously copied information may remain outside the original platform’s control.

Permissioned processing means information is used because you requested a particular result. It does not need to be displayed to other users, added to a public directory, or exposed to search-engine indexing.

This separation allows DeepMirror to consider information that would often be inappropriate to publish.

A public profile might say that you are a product manager with healthcare-technology experience. Your private reflections might reveal that you enjoy early product discovery but feel depleted by constant stakeholder negotiation. That distinction could matter when considering whether an opportunity genuinely fits you, but it does not belong on a publicly searchable profile.

DeepMirror can use that private context for the experience you requested without turning it into public profile content. This supports more meaningful matching than simply making a professional profile more visible. It does not guarantee that every suggested opportunity will be right: career fit is partly subjective, available information can be incomplete, and both roles and people change.

Protection begins before storage

There are several distinct moments in the life of a CV or check-in:

1. It travels from your device to DeepMirror.
2. The application verifies who is making the request.
3. The application processes the requested information.
4. Information selected for cloud storage is encrypted.
5. The encrypted record is saved.
6. The record may later be decrypted for an authorized request.
7. It is eventually exported, replaced, or deleted.

A meaningful security design must address each stage. Saying only “the database is encrypted” leaves too many unanswered questions.

Encryption while data is moving

Connections to the deployed DeepMirror application use HTTPS. Transport Layer Security, or TLS, protects information travelling between your browser and the cloud service against ordinary interception on the network.

DeepMirror runs on Google Cloud Run. Google documents that its frontend infrastructure terminates the public TLS connection and forwards traffic through an encrypted channel within the Cloud Run infrastructure. This is encryption in transit. It protects the communication channel, but it is separate from the application-level encryption used for stored personal records.

Application-level encryption before database storage

Firestore automatically encrypts its data before writing it to disk. DeepMirror does not rely on that platform protection alone.

For covered personal records, DeepMirror encrypts the sensitive payload inside the application before sending it to Firestore. Firestore receives an already encrypted value and then protects it again with its own storage-level encryption.

The database does not receive the covered personal text as an ordinary readable field. This application-level layer improves protection in an important scenario: disclosure of Firestore records without simultaneous access to the application’s authorized key-management identity.

A different random key for every payload

DeepMirror does not use one static encryption key directly for every CV and check-in.

Each encrypted payload receives a freshly generated random data-encryption key, commonly abbreviated as DEK. That key encrypts one payload using Fernet authenticated encryption.

This separation matters. Reusing one data key across a large body of personal information would create an unnecessarily broad failure domain. Per-payload keys reduce the amount of data directly protected by any individual DEK.

Fernet provides two connected properties:

• Confidentiality: the payload cannot be read without its key.
• Integrity and authenticity: unauthorized modifications to the encrypted value are detected during decryption.

If encrypted bytes are changed, truncated, or replaced, the system does not silently turn them into altered CV text. Authentication fails and the payload is rejected.

The data key is protected separately by Cloud KMS

The data-encryption key must itself be protected. Storing it as plaintext next to the encrypted CV would defeat the purpose of encryption.

DeepMirror therefore sends the random DEK to Google Cloud Key Management Service. A centrally managed key-encryption key encrypts—or “wraps”—the DEK. Only the wrapped form is stored with the encrypted payload.

The resulting versioned encryption envelope contains:

• the encryption-format version;
• an approved KMS key reference;
• the wrapped data-encryption key; and
• the encrypted personal payload.

To decrypt the payload, the application must retrieve the encrypted record, authenticate to Cloud KMS using its service identity, ask KMS to unwrap the DEK, and use that DEK to authenticate and decrypt the content.

The central KMS key material is not placed in the database or application source code. An authorized caller requests a cryptographic operation from KMS rather than retrieving the master key itself.

Why envelope encryption matters

Imagine that an attacker obtains a copy of an encrypted CV record from the database.

They find ciphertext representing the CV, an encrypted data key, a reference to the KMS key that wrapped it, and limited metadata needed to operate the service. They do not find the plaintext data key or the KMS master-key material.

Possessing the encrypted database value is therefore insufficient. The attacker would also need access to an identity authorized to use the correct KMS key.

This creates two different protection boundaries:

• The storage boundary contains ciphertext.
• The key-management boundary controls whether that ciphertext can be decrypted.

Security still depends on protecting both boundaries, but a database disclosure alone does not expose the covered personal content in readable form.

Encryption is bound to the user identity

When DeepMirror wraps a payload’s DEK, it supplies additional authenticated data derived from the normalized user identity.

Additional authenticated data is not secret. Its purpose is to bind a cryptographic operation to a specific context. Cloud KMS requires the same authenticated context when unwrapping the key.

Copying an encryption envelope from one user’s database location into another user’s location therefore does not make it decryptable as that second user’s record. The cryptographic context would no longer match.

This reinforces ordinary database-path authorization with user separation at the key-unwrapping layer.

Only approved KMS keys are accepted

An encrypted envelope contains a reference identifying the KMS key used to wrap its DEK. That creates a subtle security question: could someone modify a database record so that the application tries to use an arbitrary KMS key?

DeepMirror addresses this through an explicit key allowlist. The application accepts only configured KMS key resources. If an envelope references another key, decryption is rejected before KMS is used.

This prevents database content from turning the application into a general-purpose KMS caller.

Production encryption fails closed

A dangerous configuration failure would allow a production deployment to fall back silently to weaker encryption because KMS was unavailable or omitted during deployment.

DeepMirror’s production behavior is designed to fail closed. KMS-backed encryption is required for covered writes in the deployed service. If the required KMS configuration is missing, the write fails instead of silently downgrading its protection.

This can make a save unavailable during a serious configuration problem, but it prevents an insecure write from being presented as a successfully protected one.

What CV-related information is encrypted?

For stored CV records, the encrypted payload includes:

• the CV text used by the application;
• the original filename;
• the reported content type; and
• the upload timestamp contained inside the payload.

Reusable personal evidence derived from a CV is also stored as an encrypted payload. Career Mirror reports—including their personal report text, user request, region, action, and saved selections—use the same application-level encryption path.

The security benefit therefore extends beyond the uploaded document. Personally revealing conclusions and generated records should not become a plaintext copy of information that was encrypted at ingestion.

Some limited operational metadata remains outside the encrypted payload so the application can locate, order, and manage records without decrypting every document. Depending on the record, this can include document identifiers, creation or update timestamps, version numbers, result counts, and a Boolean indicating whether a report contains saved items.

Encryption hides the covered content, not necessarily the existence, approximate timing, type, or number of records.

How cloud-saved check-ins are protected

For cloud-saved check-ins, the encrypted payload includes the sensitive content needed to reconstruct the check-in, including reflection answers and generated feedback. Relevant derived personal data also uses the shared encryption mechanism across several DeepMirror domains.

DeepMirror offers different check-in storage choices:

• Cloud sync stores the covered check-in payload in encrypted form in the cloud.
• Device and cloud keeps a device copy while also storing the encrypted cloud record.
• Device only avoids persisting the submitted check-in in Firestore.

Device-only should be understood as a storage choice. The application still receives the check-in during the request and processes it to return the requested feedback. It is not equivalent to offline processing or a promise that plaintext never reaches the server.

Authentication comes before decryption

Encryption protects stored data, but it does not decide who is allowed to request it.

DeepMirror’s browser experience uses Google sign-in and verifies the identity token before establishing an application session. The sign-in flow includes state handling, PKCE verifier handling, and token audience verification.

The production session cookie is configured as Secure, HttpOnly, and SameSite=Lax. Protected records are stored under user-scoped Firestore paths and loaded using the identity from the authenticated session. That identity is also involved in the cryptographic context required to unwrap the payload’s data key.

No one layer is a substitute for the others.

When does plaintext exist?

This is the most important boundary to understand.

DeepMirror cannot provide personalized features while keeping all relevant information permanently opaque to its own server. When you request a feature that needs your CV or reflection history, the application must temporarily recover the necessary plaintext.

The intended security flow is:

1. An authenticated request identifies the user.
2. The application loads the user-scoped encrypted record.
3. KMS authorizes unwrapping of the record’s data key.
4. The application authenticates and decrypts the payload.
5. The context required for the requested feature is selected.
6. Authorized processing services may receive information required for that operation.
7. Covered stored results are encrypted before they are written to the database.

This is why the accurate term is encrypted server-side processing, not end-to-end encryption.

With strict end-to-end encryption, only the user’s device would hold the ability to decrypt the data. The DeepMirror server and any processing providers would be unable to recover plaintext. That model would require a fundamentally different architecture for features that rely on server-side personalization.

What the protection helps address

What encryption does not solve by itself

Encryption does not eliminate every possible security risk. The likelihood and required conditions differ considerably between scenarios.

A database-only disclosure is a realistic class of cloud-security incident and is one of the scenarios envelope encryption directly addresses. Reading protected records would require an additional failure: access to an authorized application identity or another way to use the correct KMS key.

A simultaneous compromise of the database, application runtime, and key permissions is generally harder than obtaining a database export alone because it requires crossing multiple independent controls. It is therefore less likely, although its potential impact would be higher.

A stolen authenticated session is a more ordinary user-facing risk. Someone who gains control of a signed-in browser session may be able to act as that user without attacking the encryption itself. Secure cookies, account protection, sign-out discipline, and multi-factor authentication remain important.

Accidental disclosure through logs or unnecessarily broad processing context is another operational risk. It does not require breaking cryptography, which is why data minimization, logging redaction, restricted permissions, and processor governance matter alongside encryption.

No meaningful dataset is available from which to assign responsible numerical probabilities to these scenarios. The accurate assessment is qualitative:

• database-only disclosure is plausible enough to design against directly;
• multi-boundary compromise requires more conditions and is correspondingly harder;
• session and endpoint misuse remain practical risks; and
• no internet-connected system can honestly promise zero risk.

What you can do

• Protect your Google account with a strong password and multi-factor authentication.
• Sign out on shared devices.
• Choose the check-in storage preference that matches your needs.
• Avoid unnecessary personal identifiers in free-text requests.
• Remove CV information you do not need, such as an identification number or handwritten signature.
• Use DeepMirror’s export and deletion options when you want to retrieve or remove stored information.

Summary

A CV does not need to be publicly visible to be useful.

Social professional profiles help people become discoverable. Depending on their settings, information placed there may be visible to members, external search engines, or permitted connected services. That visibility can be valuable, but it means the profile is intended to be read by an audience.

DeepMirror uses a different model. Your CV, check-ins, and covered derived records are private account data rather than public profile content. Stored sensitive payloads are protected with per-payload authenticated encryption. Each data key is separately wrapped by Google Cloud KMS, bound to the user identity, and restricted to approved key resources.

When you request a personalized feature, the application can temporarily decrypt the relevant information under controlled authorization. This enables meaningful career matching without publishing the underlying CV, private preferences, or reflections.

The honest boundary is that this is encrypted server-side processing, not end-to-end encryption. Authorized application components must be able to access the information required to fulfil your request. The protection lies in limiting that access, separating keys from stored data, detecting tampering, and keeping covered content unreadable in a database-only disclosure.

Your private context can help DeepMirror understand what may fit you without becoming another public record about you.

Technical references and platform documentation

1. Google Cloud — Envelope encryption
2. Google Cloud — Encrypting and decrypting with Cloud KMS
3. Google Cloud — Firestore server-side encryption
4. Google Cloud — Cloud Run security design
5. Cryptography project — Fernet authenticated encryption
6. LinkedIn Help — Public profile visibility
7. LinkedIn Help — What people can see on your profile