Aller au contenu

Privacy Policy

Last updated:

This document is written in English. Website language settings do not translate its legal text.

1. Scope and responsibility

This Policy explains how Mikhail Bovt, the individual operator of Vyach based in Singapore, handles personal information when providing the Discord bot, website, dashboard and related services. For accounts, authentication, service administration, security and support, we determine the purposes of processing and act as a controller where that concept applies.

For meeting data processed on an organisation’s instructions, that organisation or other person determining the recording’s purposes is the controller and Vyach acts as its processor under the DPA. Owning a Discord server does not alone settle every legal role. If you participate in an organisation’s meeting, its notices and lawful instructions also apply. Discord and Polar have separate responsibilities for their platforms and transactions.

2. Sources and categories of information

We receive information from you, Discord, people in your meetings, authorised server operators and our service providers. We process the following categories as relevant to the features you use:

  • Account and server information: Discord user, server, channel, role, message and thread identifiers; usernames, display names, historical meeting aliases, avatar and server-icon URLs; server names, ownership, membership and permission information. Voice-state and membership events support meeting operation and Payer eligibility.
  • Meeting participation: meeting titles, tags, dates, channels, creator and participant IDs, display names, join and leave times, speech timing and recording status. Participation metadata can exist for a person whose audio is not recorded.
  • Consenting speakers’ audio and meeting content: temporary WAV chunks, transcription text and timing, detected language, summaries, tasks, catch-up digests and text-search or vector-index records. What other participants say may include information about non-speakers.
  • Preferences and instructions: recording acceptance or refusal and its time; access grants; retention, language, channel and feature settings; custom templates, descriptions and personality prompts.
  • Questions: question text, related reply context, relevant retained meeting excerpts and display-name aliases are processed to answer the request. The text of the question and answer is not saved as a Vyach question-and-answer history. Request metadata is described below.
  • Operational and usage records: timestamps, statuses, recording duration, quota use, technical error categories and identifiers, processing jobs and deletion/export receipts. Non-question AI operations can generate model, provider-request, token-count and estimated-cost records. Owner-linked usage can be combined across that owner’s Free servers for the shared cap.
  • Sign-in and browser information: Discord profile data, encrypted OAuth access and refresh tokens, hashed session identifiers, anti-forgery tokens and short-lived sign-in states. Network addresses and request headers are necessarily processed to deliver and protect web requests; an IP-based sign-in limiter uses a per-window in-memory counter that resets on the next check after the rate-limit window has expired; it is not stored in the database.
  • Purchases and support: Payer and inviter IDs, subscription and customer references, plan and period dates, add-on balances, payment or cancellation status, payment-event and reversal references, and information you voluntarily supply in support or rights requests.

We do not request your Discord password or the OAuth email scope. Payment details supplied to Polar are separate from Discord sign-in. A support message or checkout can nevertheless contain an email address. We do not deliberately create voiceprints to identify people; speaker attribution uses Discord account identifiers.

3. Purposes and legal bases

Meeting processing serves the recording, transcription, summarisation, search and publication purposes selected by the server’s authorised operator. That controller must identify its lawful basis, provide notices and satisfy recording and special-category-data requirements. Vyach’s accepted recording preference is a technical permission to capture a speaker’s audio, not a substitute for every legal requirement.

Where we are a controller and GDPR or UK GDPR applies, we rely on performance of a contract for service requested by a contracting user, legitimate interests for proportionate authentication, service security, abuse prevention, administration and support, and legal obligations where necessary. For people acting for a customer rather than personally contracting, appropriate administration can instead rely on legitimate interests. Where consent is required for a particular purpose, we obtain it and allow withdrawal. Our legitimate interests do not override your rights.

Information required for login, permission checks or a requested purchase is necessary for those features; without it they cannot work. Optional feature settings and meeting participation are your choices. We do not use meeting content for advertising, sell personal information, or share it for cross-context behavioural advertising.

4. Recording choices

Only recognised human speakers with an accepted preference for the current server are eligible for capture. Acceptance can carry over to later meetings on that server. Bots, unknown accounts, declining users and users who have not answered are excluded. Closing private messages or ignoring a consent prompt does not enable recording.

Use /privacy consent to see or change your preference. Declining during a meeting stops further capture for your account; audio already captured and material already generated are not automatically erased. Leaving the voice channel stops new capture for that connection. To delete prior attributed material, use the separate personal-erasure control.

Consent controls cannot prevent a consenting participant from mentioning you or relaying someone else’s voice. Such relaying without the necessary permissions is prohibited by the AUP. We do not promise that an excluded speaker’s name or all references to them will disappear from other people’s contributions.

5. Speech-to-text, AI providers and training

Speech-to-text runs in the deployed Vyach STT service, using the Nemotron ASR model through NeMo on infrastructure operated for Vyach. The application does not send raw meeting WAVs to the OpenAI or Alibaba text APIs for transcription. Discord transports voice, and hosting operators may process or have infrastructure access to stored audio; “local STT” does not mean processing on your device or the absence of infrastructure providers.

Alibaba Cloud Model Studio/DashScope supplies the Qwen inference API used for summaries, tasks, catch-up digests and meeting answers. Requests can contain transcripts or excerpts, meeting titles and dates, participant names, questions, reply context and configured prompts. OpenAI’s embedding API receives transcript or summary text for indexing and retrieval queries, which can include question text and speaker aliases. Embeddings and indexed excerpts are retained with searchable meeting history.

Vyach does not use your recordings, transcripts, summaries or questions to train or fine-tune AI models. This describes our use of data; it is not a claim that every provider retains nothing. Provider inference, safety logging, retention and contractual data controls also apply. We do not claim an approved zero-data-retention arrangement merely because a request is ephemeral in our application.

The production service uses the international DashScope endpoint associated with Singapore and the standard OpenAI API endpoint, with no deployment-specific EEA residency or zero-data-retention approval represented here. Provider contracting entities depend on the account's contracting country and agreement. Their current processing terms, rather than a model name, determine any onward transfers and retention.

Alibaba Cloud's published standard policy allows inference prompts and responses to be retained for up to 30 days, with exceptions for legal or service-security needs. Approved enterprise zero-retention controls are separate from this standard policy. Deleting data from Vyach does not itself erase a provider's independently retained safety records. See the provider's retention policy and the provider roles and transfer terms in our DPA.

See OpenAI API data controls and Alibaba Cloud regional endpoints. The configured DashScope international endpoint is associated with Singapore; an API hostname alone does not establish an EU-only processing guarantee.

6. Question and answer ephemerality

Vyach processes questions and answers in memory while answering and sending a Discord reply. It does not persist their text in its question table or create a local question-and-answer archive. For quotas and per-member usage, it keeps only a request identifier, server and user ID, timestamp and status such as answered, rejected or failed.

Request records are deleted after 30 days by background maintenance. User attribution and question references are also removed from older question-usage events. Usage amounts and event timestamps may remain without user attribution while the server’s operational records exist. Removing an identifier does not guarantee anonymity if other information can link an event to a person; applicable privacy rights still apply to identifiable information. Question AI-usage events are not kept as a separate query analytics history. A per-user anti-abuse counter temporarily enforces one question per 30 seconds.

Your original Discord message, the bot’s reply and any subsequent quoted reply can remain on Discord under that platform’s and the server’s controls. AI providers receive request text for processing and have their own applicable retention rules. “Ephemeral” therefore does not mean that the text never leaves memory anywhere, never reaches a provider, or is automatically deleted from Discord.

7. Retention periods and cleanup

  • Raw audio: cleanup is attempted after the transcription result is successfully committed. Pending, processing or failed chunks become eligible for deletion 24 hours after the chunk ends; a periodic filesystem sweep also removes stale WAV files after 24 hours based on modification time. Deletion is asynchronous and retried if storage or services are unavailable.
  • Meeting data: the server selects 7, 30, 60, 90, 180 or 360 days, with 30 as the default. This measures server inactivity, not the age of each meeting. Bot commands, meeting-related activity and dashboard use can refresh the reference time. Stored transcripts, summaries, indexes, digests, participation and consent metadata are removed when inactivity cleanup applies.
  • Free storage and downgrades: Free ordinarily retains the latest five completed meetings containing stored transcripts. After a paid-to-Free transition, excess history and paid custom settings have a 30-day recovery grace. Custom templates and personality features are inactive during Free and are removed after grace; this grace can also defer inactivity cleanup. Historical meetings can still contain the template and prompt snapshots used to produce them until those meetings are erased.
  • Removed servers: removal starts a new inactivity reference. Complete removal of the server’s service records follows expiration of retention and any downgrade grace, once active work is absent and an ongoing subscription or checkout has been cancelled. Re-adding the bot before deletion can cancel pending removal; it does not restore already deleted data.
  • Question metadata: 30 days from creation, followed by deletion or removal of personal attribution as described above.
  • Export archives: download authorisation expires 24 hours after the archive first becomes ready. Expired files and records are queued for cleanup; failed export-job records are normally cleared after 30 days. Erasure can invalidate an archive earlier.
  • Web authentication: a main session expires after 30 days or earlier logout/revocation; OAuth states expire after 10 minutes. Analytics sessions expire after at most one day and never outlive their parent session; one-use access grants expire after 60 seconds. Expired database rows are removed by maintenance.
  • Anonymous analytics: page-view and invitation-redirect events, including approved campaign labels, are pruned after 90 days by daily maintenance. No individual visitor history is collected by the Vyach collector.
  • Server administration and accounting: settings, delegated permissions, Payer/subscription references and usage totals can remain while the server’s service record exists; there is no general 30-day expiry for all administrative records. Complete server deletion removes its associated rows, subject to limited independent notices, minimal payment/erasure guards and legally necessary records. Cancellation, reversal and callback references can remain separately to prevent duplicate processing or reactivation; cleanup/revision records protect erasure. These safeguards do not contain meeting text, but identifiers may still be linkable personal data. There is no universal automatic expiry for those guard records; their necessity and applicable rights must still be assessed.
  • Deletion notices and preference safeguards: a failed Payer notification can retain the Payer ID, server name and notice language for up to 30 days for retries. Personal erasure leaves a declined recording preference to prevent unintended new capture until changed or removed by server-data cleanup.

Background cleanup runs periodically rather than as a hard real-time deadline. It can wait for recording, transcription, other active work, filesystem retries or successful subscription cancellation. Retention is not a promise that data is unrecoverable at an exact second. If a deletion is overdue or a statutory request cannot wait for automatic cleanup, contact us privately.

Published Discord messages, downloaded copies, provider records and any legally required payment records have separate lifecycles. The inactivity setting does not erase them. We keep support and legally necessary records only for their relevant purposes; no fixed universal support or infrastructure-log retention period is represented here.

8. Your deletion controls

/privacy delete-my-data requests erasure of data attributed to your Discord user ID in the current server. After confirmation, capture is stopped and your preference becomes declined. The job removes your attributed audio, transcript segments, participation, consent and request metadata; affected stored summaries, digests and indexes are removed, and transcript files and the search index are rebuilt from remaining data. Processing may wait until active work safely finishes.

This is not a global deletion of every Discord identity, every server, website session, payment reference, role grant or mention of your name in someone else’s speech. Minimal refusal information and separately necessary administration can remain. Contact us for broader account or rights requests or personal references not attributable by user ID.

Authorised owners can use /privacy delete-data to erase the server’s stored meeting data and related personal metadata while keeping settings, billing and usage records without user attribution. /privacy delete-server additionally removes server configuration and associated service records after subscription cancellation. Both actions require confirmation and may be blocked while work is active.

Already published Discord summaries, tasks, catch-ups and replies remain after these actions. They may still contain personal data. This limitation does not extinguish erasure, objection or other legal rights: contact us and the relevant server operator about those copies, and use Discord’s controls where necessary.

9. Access and exports

Authorised owners can request /privacy export or the dashboard equivalent. The archive is a compressed JSON export of stored server records, including retained meeting content and relevant settings and metadata; it is not an audio-download or OAuth-token export. A whole-server export is not automatically appropriate for an individual access request because it may reveal other participants’ information.

A download requires Discord sign-in, current owner-level authorisation and the valid expiring export token. Possession of the URL alone is insufficient. The link expires after 24 hours from readiness and may be revoked earlier on erasure. Keep archives and links private. Downloaded copies leave our storage controls; recipients must protect and delete them appropriately.

10. Cookies, local storage and caching

Our application uses first-party authentication and preference storage, separate from page-view analytics:

  • vyach_session: an opaque main-dashboard session token, normally up to 30 days.
  • vyach_oauth_state: a browser-binding token protecting Discord sign-in, up to 10 minutes and cleared during callback.
  • vyach_analytics_state: a temporary browser-binding token for owner analytics sign-in, up to 10 minutes and cleared during callback.
  • vyach_analytics_session: an opaque owner-analytics session token, up to 24 hours, subject to the parent session’s earlier expiry or revocation.
  • PARAGLIDE_LOCALE: your language preference, set for up to 400 days when you select a language.
  • theme local storage: the appearance library reads a stored preference if present; the current site forces light mode. Local storage has no automatic cookie-style expiry; clearing site data removes it.

Authentication cookies are host-specific, HttpOnly and SameSite=Lax, and Secure on the HTTPS deployment. Language storage is readable by client-side code. Browser and server caches can retain avatar URLs, names, server lists and static assets for performance; caches are not an alternative source of authorisation. Clearing or blocking required sign-in storage prevents authenticated features; clearing preference storage resets preferences.

We do not use advertising cookies or a browser Umami tracking cookie. Functional storage does not establish an exemption from every country’s privacy rules. Discord and Polar can set their own cookies when you visit their pages; their notices and choices apply there.

If Cloudflare presents a security challenge, it may use a cf_clearance cookie to remember successful verification for the configured challenge-passage period. Security challenges and their necessary storage protect service access; they are separate from our aggregate site counters. Cloudflare's cookie documentation describes these security controls.

11. Support email and correspondence

Email sent to our contact addresses is routed by Cloudflare Email Routing to a Gmail mailbox operated by Google. These services process sender and recipient addresses, routing and delivery information, message contents and attachments to deliver, protect and store the correspondence. Support records can also include the identifiers and information you choose to send. Do not email passwords, access tokens, full meeting archives or sensitive third-party material unless we have agreed an appropriate secure channel.

Cloudflare's Self-Serve Subscription Agreement, section 6.1 incorporates its DPA for covered processing, including services on the Free plan. Google states that consumer Gmail is governed by its own Privacy Policy and does not provide a processor DPA for consumer Gmail. A Google Workspace DPA applies only under an applicable Workspace agreement; it cannot be assumed merely because mail is forwarded to a Gmail address. Support email is not an authorised channel for submitting Customer Data for meeting processing under our DPA.

We use correspondence to answer requests, resolve issues, handle rights and legal notices, and protect the Service. We retain it only as needed for those purposes and applicable legal obligations, then delete it. Mailbox and delivery-provider records have their own applicable retention and rights processes; deleting bot data does not automatically delete an email thread.

12. Anonymous site counters and operational metrics

The self-hosted Umami integration receives server-to-server events only for allowlisted public marketing pages, including home, pricing, about, guide and commands and their language variants. The event contains the public path, configured site hostname, an hour-rounded timestamp and, when present, approved shared campaign labels described below. It omits the raw query string, visitor IDs, visitor IP addresses, browser fingerprints and visitor request headers. A fixed collector identity is used instead of the visitor’s identity. We also count requests for the bot and community invitation redirects using fixed action names. These counts do not establish a completed bot installation, purchase or number of unique people.

We use campaign labels to understand which publications, sources and campaigns bring requests to our public site, including links placed in AI services and advertising. The supported labels are utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id, utm_source_platform, utm_creative_format and utm_marketing_tactic. They describe the shared campaign, placement or creative, not a recipient. Unknown query parameters and advertising click IDs such as gclid, fbclid and msclkid are not collected. Labels are limited to 500 characters each; ambiguous duplicate labels and labels containing obvious contact information, credentials, precise request timestamps or invalid characters are rejected rather than truncated. Campaign links must not contain personal details or per-person identifiers.

Each page request is counted independently. A redirect request can include labels on its own URL; otherwise only these labels can be extracted from its same-site, allowlisted public referring page. The full referrer is not retained, and external or private-page referrers are not used. Labels are not stored in a browser cookie or local storage, carried through the site, or joined to Discord accounts, login sessions, payments or other visits. Untagged links, including links from AI services, do not identify their source in these reports. We do not maintain visitor sessions, session funnels, cross-site profiles or per-visitor conversion paths, or send these events to an advertising platform.

Dashboard, authentication, legal, export and private analytics routes are excluded. Prefetch requests and requests carrying Do Not Track or Global Privacy Control signals are not counted. We count page views, not identifiable visitors or their paths through the site. Network addresses needed to serve a page or protect login are a separate function and are not forwarded as visitor data to Umami.

The private interface also shows STT availability, model/device state, aggregate request and chunk counts, failures, processing durations, queue depth and age, and process/container resource usage. Runtime counters and up to 60 one-minute aggregate buckets are held in STT process memory and reset on restart. Queue counts are calculated from existing processing records; these metrics contain no speech text, user IDs or meeting IDs and are not visitor analytics.

The private analytics interface is available only to configured instance owners through Discord-backed sign-in. Its security cookies identify the owners’ access sessions, not public visitors.

13. Recipients and access

  • Discord: authentication, voice transport, server/member information, avatars and delivery of messages and tasks. Avatars and server icons can load directly from Discord’s CDN. Discord processes those connections under its own Privacy Policy.
  • Alibaba Cloud and OpenAI: the specific text-processing operations described above. They do not receive raw WAVs through Vyach’s text APIs.
  • Polar / Polar Software, Inc. (United States): sole Merchant of Record and authorised reseller. Polar handles hosted checkout, payment methods, receipts, taxes, renewals and refunds. We send the selected product and billing references that link the purchase to its Discord server, server incarnation, Payer and, where applicable, inviting owner. We receive relevant customer, order, subscription and payment-status information through its API and signed webhooks, including the billing email. We do not send meeting audio, transcripts, summaries or question text to Polar. Its Privacy Notice describes its own processing of checkout and payment data. Polar acts independently for its reseller, legal, tax and fraud-prevention obligations. Hosted Polar checkout and its customer portal can use their own essential cookies and payment-provider services under that notice. Vyach links to those pages rather than embedding a payment form. Polar is not a meeting-transcription subprocessor merely because it handles a purchase.
  • OVHcloud: the application, website, self-hosted STT, databases and application backup archives are hosted on an OVHcloud VPS in Beauharnois, Quebec, Canada. OVHcloud's Canadian provider is Hebergement OVH Inc. under its published Canadian service terms. OVHcloud also provides disk-level backups. Hosting operators can have infrastructure access to the stored content.
  • Cloudflare, Inc.: proxied DNS records route website and dashboard HTTPS traffic through Cloudflare for delivery, TLS termination and DDoS/security protection. Cloudflare can process IP addresses, request URLs, headers, cookies, transmitted request and response contents, and security/network metadata. TLS is established separately between your browser and Cloudflare and between Cloudflare and our origin; this is not end-to-end encryption that excludes Cloudflare. Its distributed network and subprocessors can process data outside Canada and the EEA. Email Routing processes contact correspondence as described above. Cloudflare is a processor for covered customer content in transit and acts under its own privacy policy for network data for which it determines purposes; the customer DPA does not describe all its independent processing.
  • Google (Gmail): receives, stores and protects forwarded contact correspondence, including its contents and attachments, under the mailbox service's applicable terms and privacy policy. This does not send meeting audio to Google for transcription.
  • Authorised operators: limited administration, support and security access. Designated instance owners have cross-server administrative permissions, even without server membership.
  • Model distribution: the STT service downloads model weights from Hugging Face when needed. This creates server network requests; it is not an upload of meeting audio to a hosted transcription API.
  • Server recipients: users who can access the configured publication channels or use permitted meeting queries, and authorised owners receiving exports. Paying alone does not grant management, export or deletion permissions; independent permissions still apply.
  • Lawful recipients: competent authorities or advisers where disclosure is required by law or necessary and proportionate to protect rights, address serious abuse or manage a lawful business transfer with continuing safeguards.

We do not disclose meeting content to unrelated advertisers. Support staff are not automatically instance owners; access must be authorised for its purpose. Do not assume a server is accessible only to its Payer or only to meeting participants.

14. International processing

Discord, Polar, our AI providers and the infrastructure used for Vyach can operate in different countries. We do not promise that all information stays within the EEA, your country or a single cloud region. A server’s language setting does not determine storage location.

Where GDPR or UK GDPR transfer rules apply, processing must use an applicable adequacy decision or another lawful safeguard, such as properly completed standard contractual clauses and any required UK instrument, transfer assessment and supplementary measures. We will provide relevant safeguard information on request, with necessary redactions. Using this Service or accepting this Policy is not blanket consent that replaces those requirements.

The operator is based in Singapore; the application, databases and self-hosted STT are hosted in Canada. Cloudflare and Google use global infrastructure, and the AI providers' international services introduce additional processing locations. Singapore's PDPA requires comparable protection for overseas transfers through legally enforceable duties or another permitted basis. Provider terms and any customer-specific transfer agreement must cover the relevant processing; publishing this Policy does not execute SCCs on anyone's behalf.

15. GDPR, UK GDPR and other privacy rights

Depending on applicable law and its conditions, you may request access and a copy, correction of inaccurate information, erasure, restriction of processing, portability of eligible data, or objection to processing based on legitimate interests. You can withdraw required consent without affecting the lawfulness of prior processing. We do not use the Service to make decisions about you with legal or similarly significant effects solely through automated processing; server operators must not misuse outputs for that purpose.

You may complain to your competent data-protection authority and seek available judicial remedies. Requests are generally free. Where GDPR applies, we respond without undue delay and normally within one month; a lawful extension of up to two further months for complex or numerous requests will be explained within the initial period. We may verify identity proportionately and protect other people’s information; we do not require your Discord password.

For meeting data controlled by a customer, we will help that controller address your request and tell you the appropriate route where needed. Lack of a built-in command for a particular right does not remove it. Built-in controls are not the sole way to make a valid legal request.

16. California and US state rights

If an applicable US state privacy law, including the CCPA as amended by the CPRA, covers our processing, eligible residents may have rights to know/access, delete, correct, obtain a portable copy, opt out of sale or covered sharing/targeted advertising, and limit certain uses of sensitive information. We do not sell personal information or share it for cross-context behavioural advertising, and use sensitive information only as necessary for the requested service or another permitted purpose.

For a CCPA request we respond within the applicable period, generally 45 days, with a further 45 days where permitted and notified. An authorised agent may act with the verification and authority required by law. We will not unlawfully discriminate because you exercise a right. Where a state law provides an appeal, you may request one through the same private contact and use any applicable regulator-complaint process. Global Privacy Control already prevents public-page counting.

17. Children and sensitive information

Vyach is not directed to children under 13 or the higher applicable minimum age. Purchases and Payer responsibilities are restricted to adults aged at least 18. We do not independently collect dates of birth through Discord login to verify age. If we learn of use below the applicable minimum, we will restrict it and address deletion as required; a parent or guardian can contact us privately.

Do not submit credentials, full card data, identity-document numbers or regulated health, criminal-offence or other highly sensitive data unless a separate written arrangement and the necessary legal safeguards permit that use. Ordinary meetings can incidentally contain such information. We do not claim HIPAA suitability, biometric verification or another regulated-data certification by publishing this Policy.

18. Security and backups

The Security Policy describes implemented protections and their limits. OAuth tokens are encrypted with AES-256-GCM, session tokens are hashed in the database, and authenticated mutations require anti-forgery and origin checks. Application logging filters message bodies, questions and meeting content, while allowing technical identifiers and diagnostics. These controls are not end-to-end encryption: Vyach and necessary processors must handle readable content to provide the Service.

The deployed application backup worker creates AES-256-GCM-encrypted database archives every 24 hours and before deployment, with seven-day retention. These archives reside on the same VPS. Raw WAVs and generated export archives are not included in this application archive. An erasure revision invalidates older backup generations, and restoration rejects incompatible revisions. Purging and rotation require the backup worker to run; this is not a claim that no residual copy can exist during an outage or with another operator’s downloaded export.

Separately, OVHcloud creates a daily disk-level restore point, which can include temporary WAVs, exports, credentials and other disk data. Bot deletion and the application privacy-revision guard do not purge those provider restore points. They must expire or be removed under the provider's backup lifecycle, and any restore must reapply erasure instructions before data is served. A successful application deletion is therefore not a claim that every provider backup is immediately physically erased.

Guest full-disk encryption is not configured on the current VPS. No system guarantees absolute security or forensic overwriting of every storage block.

19. Contact, requests and updates

Contact Mikhail Bovt about privacy requests, complaints or questions at inbox@vyach.app. You can also request a private channel through our support server. State the relevant Discord user and server IDs, the right or issue involved and how we can reply. Ask for a secure channel before sending sensitive content; never publish credentials or an export link in a public support channel.

We will update this Policy when processing changes and indicate the revised date. Material changes will be communicated where required, and new consent will be requested when required for a new consent-based purpose. A policy update does not revive erased data or replace a lawful basis.