Skip to content

Privacy Policy

Last updated September 8, 2026

This policy explains what Simple Unmark processes, what we keep, and the choices available to you.

Content you submit and your processing choice

Before a text rewrite, you choose a processing mode. In Private mode, your browser sends plaintext to the Simple Unmark web application, which forwards it over the ordinary HTTPS service path to the separately deployed Python workload. The application, transport infrastructure, workload, and DeepInfra can process plaintext while the request runs. The workload performs deterministic cleanup and DeepInfra performs the model-assisted rewrite, but submitted text and cleaned output are not stored in our application database or sent to analytics.

In Confidential text mode, your browser sends only counts and abuse-prevention signals to the web application for authorization and credit reservation. It then verifies a Google Confidential Space attestation and sends encrypted text to the approved Python workload. The protected workload decrypts the text and DeepInfra processes plaintext for the rewrite, so this mode does not hide text from the approved workload or current model provider.

Media cleaning is no longer available on the website. Previous media requests used browser-verified encryption directly to the confidential workload. File contents and filenames were not sent to the web backend or DeepInfra; historical usage records contain only operational metadata, not the files themselves.

Confidential AI is a coming-soon mode in which the text rewriting model will run inside an attested confidential GPU rather than an external model API. Choosing it today records one deduplicated, pseudonymous interest record — a keyed identifier, your device-similarity hash, country code, and a selection count. It does not upload content or spend credits.

Request records may store content category and counts or byte size; selected privacy mode and media operation; model-token counts; processing status; provider-reported cost and request identifiers; credit activity; errors; and processing times. Submitted content, output, filenames, and removed metadata values are not included in those records or signed receipts.

Confidential-mode verification and limits

Before Confidential-mode content is encrypted, the workload provides a fresh Google Confidential Space token that binds the browser challenge, authorized request, and the encryption key it created in memory for that request. The browser directly verifies Google's signature, nonce, Secure Boot, production/debug status, Stable support, memory-monitoring state, the attested confidential hardware model, command and environment overrides, operator identity, and an approved OCI image digest. The encrypted response is decrypted in the browser. The workload's private key is not exported or persisted, and is not retained after the request is claimed.

This reduces access by the web backend, load balancer, and infrastructure outside the protected workload. It does not prove that approved code is bug-free; make website-delivered JavaScript independently trustworthy; hide traffic endpoints, timing, categories, operations, extensions, byte sizes, or ciphertext sizes; or protect text from DeepInfra in the current text mode. A vulnerable or malicious approved image could still expose content. Historical media processing did not guarantee removal of embedded watermarks.

Account and authentication data

When you sign in, we receive the profile information needed for authentication, such as your email address, name, profile image, provider identifier, and session details. Magic-link emails are delivered through the configured email provider.

We use this information to secure your account, show your balance, prevent abuse, and provide support.

Payments and credits

Stripe hosts checkout and processes payment details. Simple Unmark does not receive or store your complete card number. We store the Stripe Checkout session identifier, pack, amount, currency, credit quantity, account identifier, and purchase status to fulfill and reconcile purchases.

Guest usage and abuse prevention

For guests, we set a signed, essential browser cookie containing a random identifier. The cookie is not available to browser scripts and is used to count free cleans and prevent concurrent abuse. It expires after 30 days.

We use the open-source FingerprintJS library to derive a browser identifier and a coarser device-similarity identifier from browser and device characteristics. The server also derives a request signature from browser headers and, when supplied by a trusted reverse proxy, a TLS fingerprint. Before storage, every identifier is transformed with a server-secret HMAC; raw fingerprint components and raw identifiers are not stored in cleaning request records.

We separately derive a one-way keyed hash from a shortened network prefix (IPv4 /24 or IPv6 /64) to apply shared-network rate limits. We do not store the raw IP address in cleaning request records. Fingerprint matches may be associated with signed-in accounts to identify possible duplicate promotional usage for manual review. These pseudonymous identifiers and request records are retained as needed to operate and protect the service.

Country and operational monitoring

When our trusted proxy or CDN supplies it, we process a two-letter country code derived from the request network location. We store this code on account and cleaning records for service analysis, abuse prevention, and operational context. It is country-level information, not precise location data.

Application errors, registrations, purchases, and completed cleanings may generate operational notifications through Telegram. These notifications can include an account email or pseudonymous guest identifier, account or request ID, country code, usage counts, credit and token totals, provider cost, duration, and error details. They do not include submitted text or cleaned output.

Retention, security, and rights

We retain account, usage, mode-interest, and purchase records for as long as needed to operate the service, measure demand, meet legal obligations, resolve disputes, and prevent abuse. The confidential workload retrieves provider and authorization credentials from Google Secret Manager using its attached service account; VM metadata contains only secret references. This access is controlled by IAM, not gated by attestation. Privileged infrastructure administrators can obtain those credentials through IAM or identity control, although they are not payload-decryption keys. Infrastructure diagnostics may record deployment details and attestation claims; container output redirection is disabled. No system is perfectly secure, and trusted frontend code, workload code, model-provider handling, infrastructure identities, and endpoints remain part of the applicable security boundary.

Depending on your location, you may have rights to access, correct, export, restrict, or delete personal data. Contact privacy [at] simpleunmark.com. We may need to verify your identity and retain legally required transaction records.

International processing and changes

Service providers may process information in countries other than your own. Appropriate contractual and legal safeguards should be used where required. We may update this policy as the service evolves; the date above shows the current version.