Your information

Privacy Policy

PrivateChat limits the information needed for temporary, private conversations. This policy explains what the service processes, what stays in your browser and the limits of those protections.

Draft version 2026-10-30-draft-2 · Updated 30 October 2026 · Not yet effective as a final public notice.

At a glance. Creator registration uses a voucher, username and password; it does not require an email address or telephone number. Guests can join an invitation without an account. Message content is encrypted in participant browsers, while the service still processes the connection and room information needed to operate. Temporary conversations and browser cleanup do not erase copies outside the application's control.

1. Controller and contact

The person or organisation responsible as data controller for operating PrivateChat is Thomas Firas. The controller determines why and how personal data are processed for the service.

For privacy questions or a request concerning your information, contact support@privatechat.tv. The controller's verified identity and suitable contact details must replace the provisional information before this notice is published.

This policy covers the PrivateChat application, its public pages and support or voucher communications handled by the operator. An external email provider, social network or invitation-sharing service also has its own privacy practices.

2. Information processed

Creator accounts and vouchers: Username, an internal account identifier, a password hash, account status and creation time, and the password-change time when known. Voucher records include hashed identifiers, issuance or redemption information and creator-access entitlement. The account does not require your civil name, phone number or email address. A username or account identifier can still be personal data.
Authentication sessions: Hashed session tokens, session identifiers, the associated account, creation, last-seen and expiration times, and a session label. The current application uses a generic browser-session label rather than deriving it from your browser's User-Agent. An authenticated session is associated with its account.
Room and delivery information: Room identifiers, associated creator accounts and any explicitly linked guest accounts, participant roles, invitation and access-verification records, approval or rejection state, cryptographic public material, timestamps, expiry, event ordering, message counts and encrypted-payload sizes. Anonymous guest access still uses technical credentials and room/session identifiers; it does not make all activity unobservable.
Conversation content: The relay stores encrypted messages or protocol payloads so it can deliver them. Participant browsers handle readable message content and the cryptographic state needed to use the room. Encryption does not by itself remove encrypted records or associated metadata from the scope of data-protection law.
Terms acceptance: For registrations using the new acceptance flow, the account is associated with the accepted Terms of Service version, the Privacy Policy version made available with that registration and a server-generated acceptance time. The acceptance record does not add an IP address or device fingerprint. Older accounts are not assigned an acceptance they never gave.
Connections and abuse prevention: Connecting to PrivateChat exposes an IP address and ordinary request information to the network and hosting path. Application rate limits use temporary pseudonymous client identifiers derived from connection information. These controls do not establish that reverse-proxy, hosting or infrastructure logs contain no IP addresses. Section 14 distinguishes application records, diagnostics and infrastructure logging.
Support and voucher requests: If you contact support or request a voucher by email or another channel, the operator receives the address or profile you use, your message, attachments and related correspondence. These communications are separate from an encrypted PrivateChat room. Do not send your password, session tokens, room keys or invitation secrets to support.

3. Purposes and legal bases

The intended legal bases for this draft are:

Providing the service you request: creating and authenticating accounts, redeeming vouchers, admitting participants and delivering encrypted conversations, where necessary to perform the service contract or take requested steps before it (Article 6(1)(b) GDPR).
Service security and abuse prevention: validating requests, limiting abusive activity and maintaining the service, where necessary for legitimate interests and subject to the required balancing of those interests with your rights (Article 6(1)(f) GDPR).
Legal obligations: processing information where a specific applicable legal duty requires it (Article 6(1)(c) GDPR).
Requests and contractual evidence: responding to service-related correspondence and retaining proportionate evidence of registration and terms acceptance, based on the relevant contract or legitimate interest in handling requests and establishing or defending rights.

Accepting the Terms of Service is a contractual action. Making this policy available is an information obligation; it is not a request for blanket consent to every form of processing. Any future optional processing that requires consent must have its own appropriate choice.

A valid voucher and credentials are necessary to create a creator account. Without the required information, the requested account or room operation cannot be completed. Guest entry through an invitation does not require creating a creator account.

4. Encryption and practical limits

PrivateChat is designed to encrypt message content before it reaches the relay and decrypt it on participant devices. The server still processes operational metadata, including room membership state, timing, ordering and encrypted-payload sizes. It is not an anonymity network.

Protection depends on the browser, device and delivered application code. A compromised device, malicious extension or altered client can expose information while it is used. An interlocutor can copy or disclose a conversation. An invitation and creator approval control access, but do not independently verify a person's civil identity.

V2 adds an MLS-based protocol, invitation codes and encrypted durable browser state. The local V2 implementation and test results do not establish that those features are already deployed in the public service. Features and security claims must match the version actually released. No independent security audit is claimed by this policy.

5. Cookies and browser storage

The application uses an authentication cookie to maintain an account session. Its configured maximum lifetime is 30 days; logout, revocation or other security actions can end access earlier. Production cookie policy includes HttpOnly, Secure transport and SameSite restrictions.

PrivateChat also uses browser storage for room credentials, cryptographic state, locally stored conversations, pending messages, recovery records and preferences. The storage used depends on the protocol and feature. V2 seals persistent conversation records using browser-held encryption keys. A local room name is a browser-side label.

The reviewed application source contains no advertising or third-party analytics integration. This statement does not describe extensions installed in your browser or tracking by a separate service you choose to use. Introducing non-essential tracking would require a separate assessment and, where required, prior consent.

You can clear site data through your browser or use the available local-wipe control. Clearing local data can remove keys permanently and make conversations unrecoverable on that browser. It does not itself delete the server account or every server room.

6. Retention and deletion

Accounts, entitlements and vouchers: These records remain while needed to maintain the account, creator access and voucher-redemption integrity. The current application has no automatic account-expiry or self-service account-deletion feature. A deletion request can be made through the contact above and must be assessed against any applicable retention duty or justified need to retain limited records.
Terms acceptance: The initial acceptance record remains associated with the account. It identifies the document versions and time, rather than recording a history of browsing or communication. A final retention schedule for contractual evidence must be set before public use of this draft.
Authentication: A session stops authorising access when it expires or is revoked. Session records are removed through the application's revocation and cleanup paths. Cookie expiry is not a promise that every corresponding database record is physically erased at exactly 30 days.
Rooms and encrypted messages: Room access ends at expiry or confirmed destruction. The application removes the active server room and its stored encrypted messages through its deletion and cleanup paths. Availability of a cleanup worker affects the timing of removal; loss of access and physical erasure are different events.
Browser records: Local data can remain until the relevant client cleanup completes or the user removes site data. An offline or closed browser cannot be assumed to have run cleanup. Browser or operating-system backups and copies held by another participant are outside a server room-deletion operation.
Connection logs, infrastructure backups and correspondence: The deployed configuration and provider arrangements determine whether connection logs are retained and for how long. Actual periods or sufficiently specific criteria for logs, backups and support correspondence must be completed before publication. Disabling access logs would not by itself remove operational diagnostics, database records or older backups. Section 14 describes this boundary.

Deletion in the application is logical deletion through its storage mechanisms. It does not guarantee physical overwrite across storage devices, database journals, replicas, backups, screenshots or exported copies.

7. Recipients and international transfers

The other participant receives the messages you choose to send. Information needed to host, secure and support the service can also be processed by authorised operators and relevant infrastructure or communication providers, within their actual roles and applicable arrangements.

If a binding legal obligation requires disclosure, the operator may have to provide information it actually holds. This policy does not promise immunity from lawful requests, or the ability to recover plaintext or keys that the service does not possess.

Primary application hosting: Germany, within the European Union and European Economic Area. This identifies the application-server location supplied by the operator. It does not establish the locations of every backup, support mailbox, provider support operation or other recipient.

The actual providers and their roles, backup locations and any transfers outside the European Economic Area must be documented before publication, including the applicable safeguards where required. Hosting in Germany alone does not establish that every related processing operation stays in Germany or remove the controller's obligations.

8. Your rights

Subject to the conditions in applicable law, you may request access, correction, erasure, restriction or portability of personal data, and object to processing based on legitimate interests. Where processing relies on consent, you may withdraw that consent without changing the lawfulness of processing already carried out.

Send a request to support@privatechat.tv. Explain the request and give only the information reasonably needed to identify the relevant account or records. Proportionate verification may be necessary; never email passwords, private keys or live access tokens. A privacy request does not provide a password-reset or lost-key recovery mechanism.

The GDPR normally requires a response within one month. An extension of up to two further months can apply when justified by the complexity or number of requests, with notice and reasons within the first month. Rights do not require reconstructing information or plaintext the controller does not hold.

You may complain to the Italian Garante per la protezione dei dati personali or another competent supervisory authority. Contacting support first is not a condition for making a complaint.

9. Young users

Applicable age, contractual-capacity and parental-authorisation requirements continue to apply. An age threshold for consenting to some online data processing is distinct from the ability to enter a service contract. The final eligibility policy must be settled before this draft becomes effective; the current registration form does not verify age.

10. Automated controls

The application uses automated request validation, rate limits and access controls to protect accounts and rooms. These can reject or temporarily restrict requests. The reviewed source does not implement advertising profiles or automated decisions of the kind described in Article 22 GDPR producing legal or similarly significant effects.

11. Changes to this policy

Changes must carry a new version and date and describe the practices actually introduced. A material change in processing may require further information or a separate legal basis before it begins. An account's recorded notice version identifies the notice supplied with that registration; it is not proof of consent to future changes.

12. Details to complete before publication

This draft deliberately leaves the following matters unresolved rather than replacing them with assumptions:

The controller's real identity, suitable contact details and the actual service-management arrangement.
The legal identities and roles of hosting and support providers, backup and support-processing locations, and any required data-processing agreements or international-transfer safeguards. The primary application-server location is Germany, as stated in section 7.
Reverse-proxy, application and infrastructure logging, backup arrangements, actual retention periods and deletion procedures.
Retention of account and acceptance records, service eligibility, and any processing connected to paid voucher distribution.

These are publication requirements for this draft. The placeholder and this section must be resolved in a reviewed final version; local tests do not establish legal compliance.

13. Technical reference: browser, relay and invitations

This reference describes the reviewed application and the implemented V2 development flow. It does not establish which V2 features are deployed in the public service. The running version, its client code and operational configuration determine the protections actually available.

Content and transport are separate layers: Participant browsers encrypt and decrypt message content. The relay receives encrypted payloads and the identifiers and delivery information needed to route them. HTTPS protects transport to the service; it is not a substitute for end-to-end content encryption. The operator still distributes the browser application and must secure that delivery path.
V2 conversation state and membership: V2 uses an MLS-based conversation protocol through a local WebAssembly module. The creator reviews a guest claim and approves admission bound to the reviewed cryptographic material. Membership changes and epochs have explicit state transitions. Approval does not prove a person's civil identity, and protocol labels alone do not establish an independently audited implementation or protection against every compromise.
Invitation links and short codes: The two entry paths coexist with creator approval. The V2 code flow uses a blinded VOPRF evaluation with the ristretto255-SHA512 suite and an AES-GCM-protected invitation envelope. Blinding concerns the evaluation input; it does not hide connection metadata or turn a six-character code into an unlimited-strength secret. The evaluation service has its own secret, and online throttling, valid invitation state and creator approval remain important controls.
Browser persistence and origin trust: V2 seals durable protocol and conversation records with AES-GCM before storing them in IndexedDB. Protected conversation state uses browser-held, non-exportable Web Crypto keys. Non-exportability restricts direct key export through that API; code with the relevant origin privileges may still use accessible keys or read content while the application runs. Storage loss can mean permanent loss of local access. Clearing server records does not remotely overwrite an offline browser.
What the relay can observe: The relay handles room and account associations, participant roles, access and approval state, event type and order, protocol epochs, timestamps and encrypted-payload sizes. Message padding uses bounded size classes; it reduces precise length disclosure within a class but does not conceal timing, traffic volume or every size distinction. These operational records are distinct from readable message content.
Credentials and abuse controls: Server-side account, session and room-access records use the application's password or token verification mechanisms. The authentication-session table includes an account reference and creation, last-seen and expiry fields; avoiding an email field does not make an account unidentifiable in every context. The application derives pseudonymous rate-limit keys with HMAC-SHA256 from connection information and keeps limiter state in process memory. Pseudonymisation does not eliminate network-layer IP visibility.
Deletion and verification limits: Expiry and authorised destruction stop room access and invoke active-record cleanup. Database journals, backups, recipient copies and browser or device backups have separate lifecycles. Development tests check specific cases and versions; there is no claimed independent security audit, absolute anonymity, post-quantum guarantee or universal forensic-erasure guarantee.

Technical reviewers can contact support@privatechat.tv for questions about an identified version or a reproducible issue. Never send real credentials, invitation secrets, private keys or another participant's conversation to support.

14. Logging scope and operational records

No plaintext message-transcript logger is implemented in the reviewed chat application. The relay's conversation records are encrypted payloads with the functional metadata described above. That statement is deliberately narrower than saying that no logs or personal data exist anywhere in the service.

Application records: Accounts, authentication sessions, voucher redemption, room membership and delivery records are retained for their stated functions. New-registration acceptance records contain an account reference, document versions and server time, without adding an IP address or device fingerprint. These are still records and may still be personal data; they must not be described as absent under a blanket no-log claim.
Operational diagnostics: The reviewed cleanup worker can emit generic failure messages. Runtime errors and process supervision can also produce diagnostics. The manual development runner disables HTTP access logging, but that setting does not establish the production backend configuration or the absence of diagnostic output. The logging destinations and retention depend on how the service is operated.
Proxy, host and provider layers: A reverse proxy, operating-system journal, hosting provider or network security service can process connection data independently of a dedicated application logger. HTTP access logging, error logging, request-URL handling, IP handling, rotation, backups and provider retention must be checked separately. No infrastructure-wide zero-log claim is made by this draft.

Before final publication, the operator must replace unresolved operational details with the verified policy for the actual deployment. Any final no-logging statement must name its scope and match both the configuration and its ongoing operation. Choosing not to retain a class of data does not mean it is never processed transiently.