Privacy Notice

This English-language notice describes NextGen Social Media's current processing and identifies functions that have not yet been enabled. The German-language version is available at /datenschutz. Both versions describe the same processing. NextGen Social Media is being developed for international operation, but no country is enabled for restricted functions merely by this notice. Restricted functions remain unavailable until the relevant country or region, provider, transfer safeguards and legal requirements have been approved.

1. Controller and privacy contact

Represented by managing director Julian Wehe.
Telephone: +49 174 269 89 85
Email: mail@bestitgmbh.de

Privacy requests and objections may be sent to these details. Because the planned procedure requires a data protection impact assessment, an expert and independent data protection officer will be appointed under section 38(1), second sentence, BDSG before activation and the contact will be published here. Appointment and availability are a technical activation gate.

2. Current service status

The current production state permits approved, non-age-restricted content only. External age, identity, creator-KYC and payment providers, and the publication or delivery of 18+ content, are disabled. The hybrid live-media function is technically prepared but remains blocked until the provider, privacy, SFW, moderation, operations and transfer checks described in sections 5 and 12 are documented and approved. Before activating further functions we will document the provider and product version, approved territories, subprocessors, data regions, legal bases, retention and transfer safeguards. Unknown or unapproved territories will fail closed for restricted content.

3. Service delivery, security and local settings

We process connection and security data such as IP address, time, requested resource, status code, browser and device information, and rotating derived security identifiers. We use this to deliver and protect the service, diagnose faults and rate-limit abuse. For people protected by the GDPR, the bases are Article 6(1)(b) and our legitimate interest in a secure service under Article 6(1)(f). A theme preference may be stored locally. A country code supplied by the delivery network may select a display currency; it is not proof of residence, tax status or age.

4. Accounts, authentication and essential storage

We process account and display names, roles, optional or federated email addresses, password verification values, passkey public keys and counters, recovery-code verification values, session and CSRF values, security events, and acknowledged legal-document versions. If Google sign-in is chosen, we receive the authorised OpenID account identifier, email and basic profile claims. Essential session, CSRF and sign-in cookies secure the account and are not used for advertising. Under the GDPR, the bases are Article 6(1)(b), supplemented by our security interest under Article 6(1)(f). Without required account and security data, an account cannot be provided. An email delivery provider remains disabled until contract approval.

5. Profiles, social features and communications

Depending on the features used, we process profiles, privacy choices, posts, media, categories, audiences, follows, friendships, communities, lists, reactions, comments, private saves, messages, invitations, live-room and matching metadata, and notifications. Public profiles may use a pseudonym, and public profiles or intentionally public posts may be visible without an account. Private content is delivered only after a server-side authorisation check. Under the GDPR, Article 6(1)(b) supports requested features and Article 6(1)(f) supports rights control and abuse prevention.

NextGen Social Media operates at least one specially privileged administrator account. Active people explicitly authorised as administrators may use a labelled, read-only inspection mode to view non-public profiles, posts, approved media, comments, stories and communities even where an audience, visibility, block, community or paid-access rule would prevent ordinary display. This is used only for moderation, legal and policy compliance, protection of users and rights holders, and handling legal requirements. Inspection does not create membership, friendship, purchase entitlement or any other interaction permission and is not counted as a profile view.

Private direct messages are expressly excluded from this general administrator access. Administrators cannot open or search conversations merely because of their role. Only where a participant reports a specific message may that exact message be displayed as evidence inside the secured moderation case. Administrative inspection records the administrator identifier, time, resource type and resource identifier, but not a copy of the content, in the audit log. Access is restricted to signed-in, active administrator accounts, confidential, purpose-limited and reviewed. Under the GDPR, Article 6(1)(c) applies only where a concrete legal duty requires the processing; otherwise Article 6(1)(f) supports our legitimate interests in lawful and secure platform operation.

Hybrid live audio and video

Once approved, private one-to-one and small interactive sessions are routed primarily through LiveKit Cloud. Public creator broadcasts are distributed through Cloudflare Realtime SFU; Cloudflare may also be selected only for a newly starting room when the approved LiveKit allowance is exhausted. A running session is not silently moved between providers. In a public broadcast only the creator may send audio or video; viewers receive subscribed media only. Camera and microphone access requires the corresponding browser permission. The current implementation does not record live audio or video at NextGen Social Media or through a provider recording feature enabled by us.

For this purpose, NextGen Social Media processes the account and room identifier, membership, room type, publisher or viewer role, selected provider, routing and session state, pseudorandom provider session identifiers, audio/video track metadata, participation start, update and end times, short-lived viewer leases, and aggregated monthly usage and budget values. LiveKit receives a random participant identifier, display name, technical room identifier and short-lived credentials limited to the room and role. Cloudflare receives provider-issued SFU session identifiers and technical track identifiers plus the session-description, ICE, network and connection data required for WebRTC. Both providers process the live audio or video and technically necessary connection data such as IP address, timestamps, quality and error information to establish, secure and deliver the connection. The platform does not submit its own account identifier to Cloudflare as the provider session identifier.

In the current implementation, a LiveKit access token is valid for 60 seconds. Viewer leases expire after a short period without renewal; leaving or ending a room closes tracks or provider rooms and failed cleanup is retried. The platform stores no recording, but retains the room, participant, track, billing and cleanup metadata described above under section 13; monthly usage aggregates contain no user identifier. The specific provider retention of connection, security and telemetry data, deletion after session end and effectiveness of provider cleanup must be verified contractually and technically before activation.

6. Audience measurement

A creator profile view is counted at most once per viewer or pseudonymous network identifier, creator and day. A daily rotating HMAC prevents recovery of the originating IP address. Raw count events are deleted after 45 days; daily aggregates contain no directly identifying viewer value. Under the GDPR, this is based on our legitimate interest in reliable, duplicate-resistant statistics under Article 6(1)(f). We currently use no third-party advertising tracker and do not sell personal data or share it for cross-context behavioural advertising. Objections may be sent to the contact above.

7. Managed pages, campaigns and billing

Managed-page processing may include ownership, team roles, permissions, responsibilities, invitations and transfers. Campaign records may include parties, briefs, terms, versions, acceptances and advertising disclosures. Platform invoices may contain billing contacts and addresses, VAT identifiers, service, tax, payment and bank-reconciliation data, plus immutable invoice snapshots. Under the GDPR, the bases are Article 6(1)(b) for performance, Article 6(1)(c) for legal accounting duties and Article 6(1)(f) for access control and evidential integrity. Statutory accounting records are retained for the applicable legal period. External live payment processing is not enabled: no payment provider is configured for checkout or payouts, and separate checkout and payout kill switches remain enabled. Before activation, we will document the actually selected provider, its role, data categories, processing terms, locations, subprocessors, transfer mechanism, retention, webhook and reconciliation procedures, and required approvals.

8. Age and identity checks — not yet enabled

Age and identity checks are currently disabled. Once approved, the selected method may be operated either by a specialist provider or by a specially authorised internal review team. An external provider may process an identity document, selfie or video, liveness signals, document authenticity, an age attribute, device data and fraud signals and, depending on the method, biometric data for a unique match. A separate gateway minimises and normalises the response and sends NextGen Social Media only purpose-bound pseudonymous evidence and technical binding data.

Under the planned internal method, NextGen Social Media would temporarily process a redacted capture of a German identity card, permanently marked as a copy, together with an active face-video task, encrypted in a review vault separated from ordinary media storage. The separately recorded consent would relate only to making and using the identity-card copy under section 20 of the German Identity Card Act; it would neither determine the GDPR lawful basis nor replace any condition required under Article 9 GDPR, and acceptance of the Terms would not substitute for it. The Article 6 basis and, if technical biometric identification were introduced, the Article 9 condition remain expressly open pending legal and DPIA approval. Access would be limited to specifically assigned and qualified reviewers using a fresh passkey confirmation and a managed device; every view and decision would be logged and two independent reviewers would be required. No biometric template, facial feature vector or automated face matching would be generated or stored.

Name, document number, machine-readable zone (MRZ), and card access number (CAN) must be physically covered before camera capture. The image is normalised to the identity-card aspect ratio and, before any persistence, the server fails closed unless the expected black cover areas are present; a side-specific transform masks those areas again. Non-conforming captures are discarded. Those values would not be extracted, indexed as separate fields, hashed, or used to recognise a person or link accounts. The minimised raw capture is destroyed immediately after the decision and technically within 24 hours at the latest. eID blocking passwords or blocking features would never be collected. A service-and-card-specific identifier lawfully received through German eID, or a platform-specific provider subject, could only be read transiently, transformed immediately using a domain-separated secret HMAC segregated by purpose and environment, and then discarded. The HMAC remains pseudonymous personal data; it could be used only for the approved purpose and period and could not be linked across services or purposes.

Raw captures, derivatives, direct media hashes and technical content fingerprints would be destroyed immediately after the final decision and technically no later than 24 hours, including primary storage, replicas, queues and key material; an appeal after deletion would require recapture. Only a minimised pseudonymous review, policy and deletion record would remain: case and user references, the outcome “adult confirmed” or “not confirmed”, approved method and policy version, decision, expiry and deletion times, reviewer and second-approval evidence, and necessary revocation and passkey-binding data. A versioned, secret-key-bound commitment receipt over the evidence or deletion payload would additionally remain solely to verify internally that the review and deletion record was not replaced unnoticed. It contains neither the manifest nor raw data or direct, freely comparable media hashes. Name, exact date of birth, document data, image, video and raw-evidence fingerprints would not form part of this durable record. Short-lived passkey-linking grants and adult sessions receive a fixed deletion timestamp and are automatically removed no later than 24 hours after technical expiry. A time-limited legal hold would be permitted only for an existing legal matter or a binding order, and must specify its purpose, legal basis, exact records, owner and expiry; it could not justify precautionary retention. The current authority workflow rejects holds on raw identity material. Before supporting an EPOC-PR, the order type, official channel and Article 11 Regulation (EU) 2023/1543 lifecycle—normally 60 days, a formal 30-day extension, continuation following a confirmed production request, and immediate cessation after withdrawal—must be technically and legally approved.

For planned adult access, only pseudonymous binding and revocation records for securely linked passkeys could additionally be retained. A passkey with mandatory WebAuthn user verification combines possession of the private key with a local PIN or biometric and therefore provides technical multi-factor authentication. Additional TOTP could only be an additive security step; it would not replace the user-verified passkey or renewed person verification. Ordinary sign-in, password, Google sign-in, recovery or TOTP alone would never activate adult access, and a new device would obtain the age status only through the separately approved linking or re-verification process. The lawful basis, DPIA, staff training, retention and a version-bound internal controller release for the exact end-to-end design must be approved. Until then it remains technically blocked.

The supporting TOTP persistence and endpoints are implemented but remain blocked behind the disabled adult-system policy. If later approved and enrolled, the TOTP seed would be stored only in encrypted form together with its initialisation vector, key version and encryption domain, the bound age assurance and enrolment session, last accepted counter, failed-attempt count, blocking time and lifecycle timestamps. An accepted attempt would be recorded without the entered code and bound to the factor, user, age assurance and, where applicable, authentication session, its “authentication” or “continuity” purpose, counter, outcome, creation, consumption and deletion times. The sole purposes are additional access protection, session and person binding, replay prevention and abuse prevention. Following approval, Article 6(1)(b) GDPR would support the protected access requested by the user and Article 6(1)(f) would additionally support replay, attack and abuse protection; the necessary balancing assessment remains an activation condition.

Accepted TOTP-attempt evidence is deleted within 24 hours at the latest; its internal deletion marker becomes due after 23 hours. A revoked TOTP factor, including its encrypted seed, initialisation vector and key version, is deleted once its attempt records have been removed and within 24 hours after revocation at the latest; effective account deletion removes both factor and attempts immediately. Active factors remain only until revocation, re-verification, loss or the end of the required access purpose. TOTP alone is never sufficient for adult access, continuity transfer or recovery.

Age assurance, person binding, provider-side liveness or document matching, and re-registration prevention are separate purposes. Before activation, each market and method requires a lawful-basis assessment, any required condition for biometric processing, a DPIA, provider due diligence, processing terms, accessible alternatives, human review, retention and transfer approval. Technical uncertainty, an invalid document or liveness failure is not treated as proof that a person is underage.

9. Pseudonymous re-registration restriction — not yet enabled

For a proportionate five-year account sanction, NextGen Social Media intends to transform the provider-specific subject using a versioned secret HMAC. The resulting restriction identifier is pseudonymous personal data, not anonymous data. We retain only provider, key version, HMAC, sanction reference, status, start, expiry and revocation. It remains separate from the profile during the sanction even if the former account is deleted or anonymised, so that changing an email address does not bypass the sanction. Once expired it is no longer used to deny access and must be deleted or cryptographically destroyed after the approved operational and backup interval.

A match must not be treated as infallible identification. The current appeal route covers only a sanction attached to a signed-in account. Before re-registration prevention is enabled, a securely claimant-bound human-review route must also exist for a newly rejected account, mistaken identity, identity misuse and false age outcomes; a successful appeal must revoke the restriction. The five-year period, legal basis, balancing assessment, error handling and automated deletion must also be approved.

10. Uploads, 18+ content and participants — not yet enabled

Current uploads are limited to approved non-age-restricted material and enter private quarantine first. Before 18+ uploads can be enabled, uploaders must be verified adults. Every identifiable participant will also require separate evidence of adulthood, identity, rights, informed consent, permitted use and a withdrawal or takedown process. Verifying the uploader does not verify other participants.

Adult material may reveal sex life, sexual orientation, health or other specially protected information under Article 9 GDPR. The necessary Article 6 legal basis and Article 9 special-category condition will be determined before activation; general account terms are not sufficient. Illegal, underage, non-consensual or unauthorised material remains prohibited.

11. Moderation, reports, sanctions and appeals

We may process the reporter, reported content or account, reason, statement, evidence, rule and model version, classification label and confidence, case state, reviewer identifier, outcome, sanction and appeal. A report submitted from a live chat copies only the specifically reported message as case-bound evidence, makes it visible to authorised reviewers and audits review access without copying its content into the audit record. At exactly 180 days this live-chat evidence is no longer available to reviewers. Physical deletion follows in the next scheduled run, which starts every 30 minutes with up to five minutes of random delay; under normal operation this is within 35 minutes after expiry. An operational outage may delay physical deletion, is monitored and is caught up by the next successful run. Reporter and victim information is not disclosed to the reported person unless legally required. For people protected by the GDPR, the bases are Article 6(1)(c) where processing is necessary for a legal duty and Article 6(1)(f) for our legitimate interests in platform safety, enforcement, evidence and defence. Automated systems may prioritise or quarantine material; serious final measures are reviewable, and five-year or permanent sanctions require independent second approval. Other evidence is retained only for the proceeding, repeat-abuse assessment, required reporting or documented legal defence.

Authorised administrators may use the inspection mode described in section 5 for these purposes. It is not a concealed user account and does not bypass write, purchase or communication permissions. Access records are retained only as long as needed for access control, misuse detection, accountability and legal defence.

12. Recipients and international transfers

Hetzner Online GmbH, Industriestraße 25, 91710 Gunzenhausen, Germany, acts as processor for VPS application, database and log infrastructure intended for Germany or the EU. The selected server region and the Hetzner DPA concluded in the customer account govern that processing.

Cloudflare, Inc., 101 Townsend Street, San Francisco, California 94107, USA, is intended to act as processor for D1, R2 and edge database, private media, network, security and log data and, through Cloudflare Realtime SFU, for live audio, live video, WebRTC session and connection data. Its global network may involve third-country access. Following documented acceptance, the current Cloudflare DPA, incorporated EU Standard Contractual Clauses for restricted transfers and any necessary supplementary measures apply. The exact account configuration, contractual product coverage, subprocessors and transfer impact assessment must be documented before live-media production use.

LiveKit Incorporated, 4285 Payne Avenue, #9154, San Jose, California 95157, USA, is intended to act as processor through LiveKit Cloud for realtime audio and video and room, participant, network, security, quality and telemetry data. Only after documented acceptance are the current Data Processing Addendum and subprocessor list applicable to this operation. Before activation, contractual product coverage, EU region pinning, actual data paths, retention, third-country safeguards, supplementary measures and deletion after session end must be assessed and recorded.

If Google sign-in is voluntarily selected, Google Ireland Limited generally provides the Google account service in the EEA and Switzerland and Google LLC generally does so elsewhere, acting independently for that service; NextGen Social Media controls the OpenID claims it receives. See the Google Privacy Policy. Other identity, age, email, moderation or payment providers remain disabled until their entity, role, subprocessors, locations, deletion and transfer mechanism are documented.

Transfers outside the EEA require an applicable adequacy decision or appropriate safeguards such as EU Standard Contractual Clauses and necessary supplementary measures. Executed contracts, account configuration and transfer assessment are operational requirements; links to provider terms alone do not satisfy them.

Personal data may also be disclosed to courts, law-enforcement, security or other competent authorities where a concrete legal duty binding on NextGen Social Media or a lawful order requires it. Each request is checked for authority, legal basis, form, scope and any required judicial authorisation. Only responsive data that actually exists and is necessary is transmitted through a verified secure channel; a request does not justify precautionary collection or longer retention. Formal validation, the scope bound exactly to the order, specified accounts, categories and data that actually exists, and separate Legal and Privacy approvals are recorded immutably. EPOC and EPOC-PR processing remains fail-closed until Regulation (EU) 2023/1543 and the addressee/notification duties under the German EBewMG are implemented. Export receipts contain neither exported data nor a freely comparable content digest. Affected people are notified where legally permitted, subject to statutory secrecy and notification restrictions.

13. Retention and account closure

Short-lived sign-in, challenge, live-access, viewer-lease and reservation data expires technically; raw profile-view events are deleted after 45 days. Live media is not stored as a recording. Expired leases and released reservations are deleted within 24 hours. After a live room has ended and provider cleanup has succeeded, technical participant and track data is also deleted within 24 hours. Successful cleanup jobs are deleted after seven days; pending or terminally failed jobs remain available for recovery until provider deletion is proven. Provider, session, capacity and deadline fields on the ended room are removed after 30 days and only when no pending or terminally failed cleanup job remains. User-free monthly usage aggregates are retained for 24 months. The automated job starts every 30 minutes with up to five minutes of random delay; an operational outage may delay physical deletion and is monitored through the freshness marker. Account data and content are generally retained until deletion or account closure. After that they are deleted or anonymised unless a statutory invoice record, active re-registration restriction, moderation evidence hold, claim, reporting duty or legal defence requires separate limited retention. A complete self-service deletion and export path is still in development; requests can be sent to the contact above. Live media remains blocked until the provider-cleanup drill and the other launch approvals have passed.

14. Sources, required information and automated decisions

Account data comes from the person, technical data from the device or delivery network, Google data only after chosen sign-in, and future verification results from the approved provider. Required fields are identified; without them the relevant function cannot be provided. Age or restriction decisions may significantly affect access. Alternative verification, clear statuses, human review and appeal are therefore activation requirements. Before using solely automated decisions with legal or similarly significant effects, we will explain the principal criteria, significance and consequences.

15. Your rights

Where the GDPR applies, rights may include access, rectification, erasure, restriction, portability, objection and withdrawal of consent, plus a complaint to a competent supervisory authority. Other regions may grant additional rights to know, correct or delete data, limit sensitive-data uses, opt out of sale or behavioural-advertising sharing, and receive non-discriminatory treatment. NextGen Social Media currently does not sell personal data or share it for cross-context behavioural advertising. These rights are considered even where the general interface is globally reachable; necessary regional supplements and request methods must be added before collecting additional regional or restricted-function data.

No payment provider is configured for live checkout or creator payouts. Until a documented activation, we therefore do not process payment or payout data for such a provider.

16. Changes and new territories

We update this notice when providers, purposes, data categories, retention, transfers or legal requirements materially change. Registration displays the current privacy version; existing users will be notified or asked for consent where required. This notice does not itself activate any country or external verification provider.