Privacy Policy

Last updated: June 20, 2026

This Privacy Policy explains how Disprofanity collects, uses, stores, shares, and otherwise processes personal information when you use our website, authentication flows, dashboards, media review tools, APIs, and related services.

1. Scope and Who We Are

In this Privacy Policy, "Disprofanity," "we," "us," and "our" mean the operator of the Disprofanity service. This policy applies to personal information processed through the Disprofanity website, account system, upload and review workflows, dashboards, support interactions, and operational systems.

2. Information We Collect

We collect the following categories of information:

  • Account and profile information. This includes your email address, password hash, display name, avatar image, account status, referral or access status, login timestamps, credits balance, and credit usage history.
  • Google sign-in information. If you continue with Google, the browser receives a Google OAuth id_token during the redirect flow and sends that credential to our auth API for account sign-in or account creation. We use the Google account identifier, email address, display name, and profile image claims made available for authentication and profile setup.
  • Verification and security data. This includes registration and password-reset verification codes, rate-limit records, security logs, and anti-abuse signals such as hashed IP address and hashed user-agent data used to protect the service.
  • Media and task information. This includes uploaded audio or video files, original filenames, file type, duration, selected review lexicons, custom review words, transcript and ASR task data, detected timestamps or review matches, mute or export settings, generated output files, task status, task errors, and progress metadata.
  • Browser storage and similar technologies. The short-lived access token, which currently lasts about 60 minutes, is kept only in frontend memory so the browser can call authenticated APIs while the page is open. It is not written to localStorage or sessionStorage. Refresh tokens are stored as HttpOnly cookies set by the auth API, so they are not readable by JavaScript. We also use sessionStorage for temporary Google redirect state, nonce, and credential handoff during sign-in completion, plus browser storage for referral continuity, task-list caching, lexicon caching, and local draft recovery.

3. How We Use Information

We use personal information to:

  • create, authenticate, and manage user accounts;
  • send verification emails, password reset codes, and service notices;
  • generate signed upload, multipart upload, and download links;
  • process media files, run speech recognition, support transcript review, and render exports;
  • store, display, and let you manage task history, outputs, and credit balances;
  • detect misuse, enforce limits, troubleshoot errors, and protect system integrity;
  • respond to support requests and operational questions; and
  • analyze service reliability, usage, and product quality on an aggregated or account-linked basis.

4. Authentication and Session Handling

The current authentication flow uses short-lived access tokens for API calls and refresh tokens for session renewal. Access tokens currently expire after about 60 minutes and are kept only in frontend memory. When the page is restored or reloaded, the frontend uses the HttpOnly refresh cookie to request a new access token instead of reading one from browser storage. Refresh tokens are stored in a Secure, SameSite, HttpOnly cookie scoped to/api/auth. Browser requests to the auth API include that cookie when refreshing or logging out, but frontend JavaScript does not read or write the refresh token value. When refresh succeeds, the auth API may rotate the refresh cookie and return a new access token.

Google sign-in is optional. The Google redirect flow uses a temporary id_token credential, along with short-lived sessionStorage state used to complete the login or registration flow. That temporary Google redirect state is cleared after completion or failure.

5. Uploads, Processing, and Storage

For uploads, our backend creates a task and initializes an Alibaba Cloud OSS multipart upload. It then issues short-lived signed URLs for each upload part. Your browser uploads file chunks directly to OSS over HTTPS using those signed URLs; the frontend does not send the raw file through our auth API or tasks API after the signed upload URLs are issued.

After the browser upload finishes, the backend finalizes the multipart upload, verifies the stored media, prepares it for speech recognition, and stores task metadata needed for review and rendering. Download links are also short-lived signed OSS URLs. Backend workers may temporarily download media from OSS while running ASR or rendering, then keep the canonical task files in private object storage until they are deleted under the retention rules below.

6. Service Providers and Third Parties

We share personal information with trusted processors and service providers only as reasonably necessary to operate the service. These may include:

  • Google for optional account sign-in and identity verification in Google-auth flows.
  • Alibaba Cloud infrastructure for Function Compute, relational database, and OSS object storage services used to operate Disprofanity.
  • DashScope International for automated speech recognition and related transcription processing.
  • Transactional email providers, including SMTP-based providers such as Resend, for account verification and password-reset delivery.

We may also disclose information:

  • to comply with law, regulation, court order, or lawful government request;
  • to investigate fraud, abuse, security incidents, or violations of our terms;
  • to protect the rights, safety, and property of users, the public, or Disprofanity; and
  • in connection with a merger, financing, acquisition, restructuring, or sale of assets.

7. International Processing and Data Location

Disprofanity currently operates key infrastructure in Singapore, including cloud infrastructure, object storage, and media-processing flows. Your files, transcripts, task metadata, account data, and related operational records may be processed or stored in Singapore and in other locations where our service providers operate, subject to applicable law.

8. Retention and Deletion

We keep information for different periods depending on the type of data and why it is needed:

  • Completed task media, transcripts, metadata, and outputs. Completed task results are generally retained for up to 7 days after completion so they can be reviewed or downloaded. The scheduled cleanup path deletes the original OSS media object, ASR intermediate object, rendered output object, and the task database record after the retention window.
  • User-initiated task deletion. You can use the product's Delete task action for eligible tasks. That deletion path removes the task record and best-effort deletes the original file, ASR intermediate file, and generated output from OSS. Tasks that are actively transcribing or rendering may need to finish before they can be deleted from the interface.
  • Unfinished uploads and drafts. If an upload is canceled or becomes stale before processing starts, the backend can abort the multipart upload and delete the unfinished task record. Uploaded drafts that are discarded from the confirmation flow are also deleted through the task deletion path.
  • Verification flows. Verification codes are short lived and currently expire after approximately 10 minutes.
  • Authentication tokens. Access tokens and refresh cookies expire automatically on their configured schedules unless revoked or cleared sooner by logout or invalid-session handling.
  • Account, usage, billing-equivalent credits, and security records. We retain these records for as long as reasonably necessary to provide the service, enforce our terms, maintain accurate usage and credit history, resolve disputes, prevent abuse, and comply with law.

9. Your Choices and Rights

Depending on where you live, you may have rights to request access to, correction of, deletion of, restriction of, or objection to certain processing of your personal information, and in some cases portability of that information. You can delete eligible tasks and associated files through the product interface. For other privacy requests, please contact us using the details below.

We may need to verify your identity and may refuse or limit a request where permitted by law, such as when we need to retain information for security, fraud prevention, dispute resolution, usage accounting, or legal compliance.

10. Security

We use a combination of administrative, technical, and organizational measures intended to protect personal information. These measures include private object storage, short-lived signed OSS upload and download URLs, HttpOnly refresh cookies, credential management, access controls, rate limiting, and environment-level security controls. No method of transmission or storage is completely secure, so we cannot guarantee absolute security.

11. Children's Privacy

Disprofanity is not directed to children under 13, or the minimum digital-consent age in the relevant jurisdiction, and we do not knowingly collect personal information from such children. If you believe a child has provided personal information in violation of this policy, please contact us so we can investigate and take appropriate action.

12. Changes to This Privacy Policy

We may update this Privacy Policy from time to time to reflect changes in the service, our processing practices, or legal requirements. We will post the updated version on this page and change the "Last updated" date above. Material changes may also be communicated through the service or by email where appropriate.

13. Contact Us

For privacy questions or rights requests, contact us at support@disprofanity.com.