Srev's Crew (.SREC.) - Privacy Policy

This Privacy Policy explains how Srev's Crew (.SREC.) processes personal data when users access the website, authenticate with a .SREC. ID or enabled external login providers, link external platform accounts, submit tickets, use support chats, interact with moderation systems, subscribe to announcements, or access staff tools. It is written to reflect the current Srev's Crew web, backend, and security model.

1. Responsible Organization

The responsible organization for personal data processing is Srev's Crew (.SREC.). Srevuplo is the founder, sole owner, rights holder, and Chief Executive of Srev's Crew (.SREC.). Public summaries should identify Srev's Crew (.SREC.) as the responsible organization for privacy matters. Data protection and legal requests may be submitted using the contact details listed in the Impressum.

2. Data We Process

2.1 Website, Security, and Session Data

IP address, request time, browser/device information, requested page, and security-relevant request metadata.
Session cookies used to keep authenticated users logged in.
Rate-limit and abuse-prevention signals needed to protect the service.
Hashed IP restriction signals used to prevent account-hopping, ban evasion, abuse of login systems, or security threats.
Public status-page issue reports, including selected affected area, severity, title, message, page path, optional contact detail, submission time, and the logged-in .SREC. identity where available.

2.2 Provider Login, Linking, and External Identity Data

A .SREC. ID can be created and used with local .SREC. credentials without a Discord account. Discord is an optional external login, linking, and notification provider where the user chooses to use it or where a specific Discord-side action requires it.
Discord user ID, username, avatar, and authentication session data received through Discord OAuth where optional Discord login or account linking is used.
Google or Apple account identifiers, email address, email verification status, display name, avatar URL where provided, login time, and provider authentication state where Google or Apple login is enabled and used.
External platform account identifiers, usernames, display names, profile URLs, avatar URLs, verification time, verification method, verification status, and public profile metadata where supported provider linking or verification is used.
Provider-specific verification may include OAuth, OpenID/sign-in flows, official provider APIs, public profile checks, staff review, or another approved method depending on the provider and feature. Examples include Discord, Roblox, Steam, War Thunder, and future supported platforms.
Steam account linking currently confirms the Steam identity through Steam's sign-in/OpenID flow and may use the Steam Web API to retrieve public profile details where configured.
Roblox account verification currently uses Roblox's official OAuth flow where configured.
Where a user chooses to display linked platform identities on a public profile, provider profile images may be shown from stored avatar URLs or through Srev's Crew controlled delivery where needed to avoid exposing unnecessary identifiers.
When a user chooses Discord login and no existing .SREC. ID is linked, Srev's Crew may create a random .SREC. ID for that user and attach the Discord identity to it.
Where Google or Apple login is enabled and a user continues with that provider while no existing .SREC. ID is linked, Srev's Crew may create a random .SREC. ID for that user and attach the verified provider identity to it.
Linked Discord identity data may be used for member records, Discord-side moderation actions, ticket notifications, and optional account association where the Discord link exists.
Staff-only website permissions are assigned to .SREC. IDs and require the required staff security checks, including authenticator-app 2FA. External provider login only reaches staff tools if it resolves to the same authorized .SREC. ID and the required security checks are completed or validly trusted for that device.
Srev's Crew never receives or stores your Discord, Google, Apple, Roblox, Steam, War Thunder, or other external platform password.

2.3 .SREC. IDs, Email, Passwords, and 2FA

.SREC. ID data such as random .SREC. ID, username, normalized username, email address, verification status, creation time, last login time, and linked external-account references where used.
Birthday or date-of-birth information provided during registration or account completion, including minimum-age checks, inactive or future age-buffer acknowledgement state where configured, optional human-reviewed age-verification status, and derived age eligibility used for Terms of Service enforcement, .SREC. Community Hub direct-message access, staff applications, and other age-gated features.
Birthday correction, voluntary age-verification, or staff-required age-verification requests may process two user-submitted images for identity review: a picture of the user and a picture of a legal identification document with all information covered except the birthday and the document photo. These images are used only for the correction or age-verification review and are deleted with the correction ticket after acceptance or rejection.
Age-verification evidence is reviewed by authorized human staff only. Srev's Crew does not use machine-only document scanning or machine-only age-verification decisions for these evidence images.
Password data is stored only as a cryptographic password hash. Plain-text passwords are not stored.
Password reset and email verification tokens are stored as limited-purpose security tokens and should be considered temporary authentication data.
Optional email-code 2FA may process one-time login codes and delivery metadata needed to send those codes.
Optional authenticator-app 2FA stores the secret needed to verify time-based one-time codes. Users are responsible for protecting their authenticator device and recovery access.
If a user chooses "do not ask for 2FA on this device for 30 days", Srev's Crew stores only a hashed trusted-device token server-side and sets a first-party HTTP-only security cookie on that browser until expiry or removal.
User-provided, staff-reviewed, or provider-verified platform links may be stored under the user's .SREC. ID for record matching, support, custom moderation, feature eligibility, public profile display, or abuse prevention.
Srev's Crew profile data such as public status, bio, profile visibility choices, profile picture, banner image, selected public linked-account display settings, and optional friend-request state.
.SREC. Minigames wallet data, including virtual coin balance, win counters, game reward history, annual birthday bonus state, Srev's Crew day bonus state, and related ledger entries.
Acceptance and acknowledgement records for the Terms of Service, Privacy Policy, and Staff Regulations where applicable, including document version markers and timestamps.
Account deletion review and scheduling metadata, including request ticket reference, automated risk summary, review status, approval or rejection details, scheduled deletion time, reactivation-on-login notice state, and audit records needed to prove what happened.
Duplicate-prevention and abuse-prevention checks compare normalized usernames, email addresses, linked identities, login/security signals, and .SREC. IDs where needed to prevent alternate accounts, account evasion, impersonation, and duplicate registrations.
Newsletter preference and email delivery audit data where a verified user opts in to Srev's Crew event or community announcements.

2.4 Tickets, Reports, Appeals, Complaints, Applications, and Support Chats

Ticket type, platform, department classification, status, timestamps, author ID, author name, target user, and message text.
Secure support chat messages, including author type, author ID, display name, body, and timestamps.
Attachments submitted as evidence, limited to approved image, MP4 video, and plain-text log formats.
Roblox in-game report and appeal-experience data where supported, including report or appeal reason, reporter or appealing Roblox user ID, Roblox username or display name, target Roblox user ID, target username or display name, active ban references for the appealing user, consent version and timestamp, game name, place ID, universe ID, server/job ID, in-game server time, receipt time, ticket routing, and staff review outcome.
Roblox appeal statements and confirmations, including the user's acknowledgement that the appeal is submitted honestly, that acceptance is not guaranteed, that future rule compliance may be expected, and that Roblox platform services are used to transmit the appeal to Srev's Crew systems.
Birthday correction and age-verification tickets are handled as evidence-restricted support tickets without normal chat. After the correction or verification is accepted and applied, or rejected, the ticket record and its uploads are deleted to reduce unnecessary identity-document retention.
Staff application data, including desired position, age eligibility information, written answers, quiz responses, computed score, review decision, and reviewer notes.
Audit events such as created, claimed, message added, accepted, rejected, reopened, and web moderation actions.

2.5 Moderation, Enforcement, and Staff Data

Moderation records such as warnings, strikes, timeouts, bans, cross-platform restriction status, reasons, timestamps, appeal outcomes, web punish audit entries, and responsible staff identifiers.
Custom battle bans, appeal references, and linked platform identities where available.
Roblox game-ban records, including stable Roblox user ID, last-known username or display name, reason, strike or ladder context where used, expiry or permanent status, issue and update timestamps, ticket references, evidence references, unban or expiry history, responsible staff/system identifiers, and limited game-session context needed for review and appeals.
Custom battle safety data, including live room/session status, relevant platform identifiers and usernames, linked .SREC. ID context where available, requester identifiers, action/audit records, enforcement status, invite/unban records, and service-health metadata needed for safety, moderation, appeals, and abuse prevention.
Staff activity time statistics where staff systems track operational presence or moderation time.
Internal service notifications for new web tickets and support chat activity.
Temporary or permanent website access restrictions, including target type, reason, expiry, responsible admin, and audit history.
Community chat moderation data, including message flags, profile flags, hidden/restored/deleted message state, profile visibility restrictions, responsible moderator, reason, and timestamp.
AI-assisted safety-review metadata for Discord messages, the .SREC. Community Hub, public profile areas, tickets, reports, appeals, support chats, and other .SREC.-connected channels where enabled. This may include message text or excerpts, message and channel identifiers, message links, author identifiers or usernames, category, confidence or reason labels, ticket references, staff review outcomes, and reviewed correction or training metadata.
Standard, non-TE2EE .SREC. Community Hub content, attachments, upload metadata, website/API traffic metadata, access attempts, session-security signals, restriction signals, device/browser context, and other operational security telemetry where technically available and necessary for safety, security, abuse prevention, child-safety review, legal compliance, or audit accountability.

2.6 Public Profiles, Community Channels, Slide Show, and Uploaded Media

Logged-in Srev's Crew members may create a community profile, upload a profile picture and banner, add a status or bio, choose which linked identifiers are displayed, send public channel messages, reply to messages, flag content for staff review, and send or receive friend requests. Profile visibility controls what is shown to other members. Core trust signals such as the .SREC. ID, join date, staff badges, role badges, or linked public profile references may still be shown where needed for identity context, impersonation prevention, votes, tickets, contests, or staff/member trust. Staff may access additional profile and moderation context, including profiles hidden from ordinary member visibility, where necessary to enforce rules, investigate abuse, protect account integrity, handle support, or protect the community. Staff may not disclose private profile information outside authorized Srev's Crew workflows.

Public community channel messages are member-facing and should not be used for private, sensitive, or confidential information. Staff may hide, restore, delete, or review community profile and chat content where rules, safety, moderation, or legal duties require it. .SREC.-controlled safety and AI assistance may check public or community-facing content for possible Terms violations and route relevant context to authorized human review. Media uploads in public community channels are limited to supported image, GIF, and video formats and may be scanned, restricted, hidden, or removed when needed for safety or moderation.

Standard .SREC. Community Hub messages and ordinary website/API use are not treated as end-to-end encrypted. Where necessary and legally permitted, authorized .SREC. security, moderation, legal, or oversight personnel may review standard Community Hub messages, upload metadata, access attempts, traffic/security telemetry, account-linking signals, and related audit records to protect users, investigate abuse, handle child-safety risks, preserve evidence, enforce restrictions, defend the service, or comply with legal duties. Operational methods, thresholds, dashboards, and internal tool design are not public information.

Child-safety media scanning for images or videos is prepared only for an official European Union or German public-authority backed scanner. Srev's Crew does not route Community Hub media to commercial or other third-party child-safety scanner providers. If no approved official scanner is configured, uploads remain subject to ordinary .SREC.-controlled safety metadata, member reports, authorized human review, and legal preservation duties where applicable. TE2EE-protected message content remains excluded from .SREC. AI and staff content review.

Admins may publish community slide show images, event banners, titles, descriptions, and optional creator or event links. Only media that Srev's Crew is permitted to use should be uploaded. Slide show items are public once published and may appear on the index page or member dashboard.

2.7 Contests, EC Votes, Public Votes, Feedback, and Rewards

Community contests may process submitted media, entry titles, notes, upload metadata, selected public display information, public vote counts, the .SREC. ID used to vote, and limited review or anti-abuse information. Public votes are used as community feedback and contest-integrity signals, but they do not automatically determine the winner.

Contest uploads and votes may require a verified .SREC. ID email. The system may store submission cooldown timestamps, vote ownership, file size, video metadata available to the browser, review status, required media usage-rights confirmation, and staff download access where needed to run the contest or reuse submitted media in public Srev's Crew media such as slide shows.

Feedback, proposals, and feature ideas submitted through support tickets or currently enabled feedback flows may process the submitter identity, profile reference, title, message, comments, votes where available, moderation state, review state, implementation state, and staff audit entries where needed to run the relevant workflow, prevent abuse, and decide whether or how to use an idea.

Where needed to prevent alternate-account abuse, vote manipulation, fraud, or reward misuse, Srev's Crew may compare contest activity with account, login, linked identity, and security signals already processed for account protection and moderation integrity.

Executive Council votes may process candidate display names, department-head or member-representative eligibility results, public vote counts, the .SREC. ID used to vote, vote timestamps, and Staff Central audit entries. Public EC vote statistics show aggregate candidate counts by election category, while private Staff Central views are limited to authorized staff.

2.8 War Thunder Mission Hosting

Mission Hosting may process mission names, descriptions, visibility settings, owner and listed dev-team .SREC. IDs, optional banners, uploaded .blk mission files, file metadata, version notes, generated mission links, approval state, review notes, safety-scan flags, rollback history, and mission-specific audit logs.

Administration reviews uploaded missions for Terms, safety, and platform-rule consistency. Mission Hosting requires account security checks such as verified email, a local .SREC. ID password, and authenticator-app 2FA; it does not require age verification unless a separate age-related concern exists under the Terms.

Private mission owners and listed devs may see mission activity logs and may enable private mission-use notifications where offered. These logs are not a public counter and do not expose confidential security methods. Public missions may be listed for community discovery according to the owner's selected visibility.

Public War Thunder custom battle statistics are separate from Mission Hosting. They cover aggregated activity for official .SREC.-moderated custom battle rooms only and do not publish player statistics, tournament statistics, ratings, or usage analytics for user-hosted missions or third-party custom battles.

2.9 External Links and Services

Public pages may link to external services such as Discord, YouTube, Instagram, X, TikTok, Roblox, Steam, or other platforms. These services are not loaded as embedded widgets by default. When a user chooses to open an external link, the external provider may process technical connection data according to its own terms and privacy practices.

Roblox game experiences, Roblox account linking, Roblox report flows, Roblox ban checks, and Roblox appeal experiences rely on Roblox platform services and APIs where enabled. Roblox may process technical connection data, account identifiers, server/session context, requests, and delivery metadata under its own terms and privacy practices. Srev's Crew controls the data it receives and stores in .SREC. systems, but it cannot control Roblox's independent platform processing, outages, API behaviour, delivery issues, account restrictions, or security incidents on Roblox's side.

2.10 Cookies and Browser Storage

Srev's Crew currently uses only technically necessary first-party session cookies for authentication, account security, staff access checks, and requested website features. These cookies are needed to keep users logged in and to protect restricted pages, tickets, uploads, and staff tools.

The website may show a cookie notice and store the user's cookie-setting acknowledgement in first-party browser storage. This acknowledgement is used only to remember that the notice has been shown and to keep future optional categories disabled unless they are introduced and selected.

When explicitly enabled by the user, a trusted-device 2FA cookie may keep authenticator-app 2FA from being requested again on the same browser for up to 30 days. This cookie is used only for account security and does not replace the user's password, account permissions, or staff access checks.

Srev's Crew does not currently use analytics cookies, advertising cookies, tracking pixels, third-party marketing cookies, or automatically loaded third-party media embeds. Public social media and video destinations are provided as external links unless a future feature states otherwise.

If Srev's Crew later adds analytics, advertising, tracking, or non-essential third-party embeds, the cookie and consent handling will be updated before those technologies are enabled.

2.11 Public .SREC. AI, Staff AI Tools, and Internal .SREC. Assistant

Public .SREC. AI, Discord-facing .SREC. AI, staff-only AI tools, the staff AI channel, AI-assisted safety review, and internal .SREC. Assistant currently operate as Srev's Crew controlled guidance, drafting, routing, safety-review, and review-assistance tools. They do not send ticket contents, user questions, staff prompts, community messages, or training notes to an external AI provider unless this Privacy Policy is updated before such a provider is enabled.

Questions typed into the public guide are used to generate an immediate support-navigation answer and are not saved as a ticket unless the user separately submits the contact form. Discord mentions, direct messages, and staff AI chats may be retained in short-term chat context and related audit records where needed to provide the requested response, enforce access checks, preserve safety context, or improve reviewed .SREC.-controlled behavior.

Internal staff draft generation may use the content of the relevant ticket to prepare suggested wording, but staff remain responsible for reviewing, editing, and sending any final response. AI-assisted safety review may create internal alerts or review tickets with message excerpts, message links, author context, classification labels, confidence or reason notes, and staff review outcomes. These signals do not by themselves impose punishment, decide appeals, or replace human review.

Child-safety report handling may create restricted IAS review metadata for standard, non-TE2EE Community Hub content, including reporter context, message identifiers, category labels, attachment metadata, and preservation status. Automated image or video matching is disabled unless the configured provider is an official EU or German authority-backed system.

Staff-only AI tools may process staff prompts, local AI replies, training proposals, reviewed correction notes, category labels, trust-zone labels, reviewer status, author identity, timestamps, and audit metadata. Reviewed training and correction notes may improve future response style, classification, or routing, but raw chats are not treated as unrestricted self-learning. Staff must not submit unnecessary personal data, unrelated evidence, credentials, or confidential information outside an authorized case purpose.

If a public web lookup feature is enabled and requested, .SREC. AI may retrieve publicly available pages or search results to answer a general chat question. Srev's Crew does not intentionally send confidential .SREC. information, ticket evidence, member records, staff records, credentials, or internal system details to external websites for that purpose. External websites or search services may still receive ordinary technical connection data and the requested URL or query needed to deliver the public page or result.

3. Purposes and Legal Bases

Operating community services, .SREC. IDs, authentication, tickets, support chats, and staff tools: Art. 6(1)(b) GDPR.
Security, abuse prevention, moderation, appeals, complaints, audit logs, custom battle moderation integrity, and community safety: Art. 6(1)(f) GDPR.
AI-assisted support navigation, staff drafting, safety review, possible Terms-violation detection, human-review ticketing, training proposals, and review assistance: Art. 6(1)(b) and Art. 6(1)(f) GDPR depending on the feature and case context.
Running optional contests, feedback flows, EC votes, public votes, reward handling, and integrity checks: Art. 6(1)(b), Art. 6(1)(a), and Art. 6(1)(f) GDPR depending on the feature and context.
Staff applications, staff lifecycle administration, staff conduct review, training, transfers, absence handling, and staff access control: Art. 6(1)(b), Art. 6(1)(f), and where applicable Art. 6(1)(c) GDPR, with German data-protection law including the BDSG considered where it applies to the specific staff or applicant context.
Sending optional newsletter, event, or account-security emails where consent or account operation requires it: Art. 6(1)(a) and Art. 6(1)(b) GDPR.
Compliance with legal duties or lawful requests: Art. 6(1)(c) GDPR.
Optional features or communications where consent is required: Art. 6(1)(a) GDPR.

Where processing is based on legitimate interests, those interests include account security, community safety, moderation accountability, prevention of ban evasion, prevention of request spam and system abuse, custom battle integrity, protection of staff and members, evidence preservation, appeal handling, and defense against misuse or legal claims.

4. Ticket Classification and Access Control

Tickets are classified by type and platform so that only the appropriate staff group can access them. Support requests are routed to Support staff, moderation reports are routed to Community Operations, technical requests are routed to Technology & Systems, staff-conduct complaints are routed to Integrity Review, and staff applications, onboarding, training, transfers, and lifecycle requests are routed to People & Integrity. Integrity Review is separate from ordinary lifecycle administration. Authorized oversight and Administration roles may access broader case categories where policy, security, continuity, or review authority requires it, and authorized staff may reopen or review closed ticket outcomes.

Users can view their own visible tickets and chat messages. Staff access is enforced on the server, including for ticket attachments, so direct file links require authentication and ticket permission.

5. Security Measures

Server-side authentication and .SREC. ID permission checks for staff pages, ticket databases, support chats, and uploads.
Local .SREC. ID passwords are stored as password hashes and are never intentionally stored in plain text.
Usernames are normalized and restricted to a basic Latin character set to reduce impersonation risk.
Optional email-code 2FA and authenticator-app 2FA are available for .SREC. IDs.
HTTP-only session cookies, secure cookies in production, and same-origin checks for ticket write actions.
Content Security Policy, frame restrictions, body-size limits, and API rate limiting.
Attachment size limits, attachment count limits, allowed MIME types, safe filenames, and file signature checks.
Security logging for authentication, access attempts, upload handling, rate limits, route abuse, website/API traffic signals, and restricted staff or security areas where needed for protection and audit accountability.
Ticket uploads are stored outside public static routing and are served only after a permission check.
Internal service notifications use an internal authenticated endpoint rather than a public unauthenticated webhook.
Status-page issue reports are rate-limited, same-origin protected, stored separately from support tickets, and visible only to authorized Technology & Systems/Admin-level operators.
Audit logs preserve case history, including rejected tickets, so staff actions can be reviewed.
IP-based website restrictions are stored as keyed cryptographic hashes where practical, so admin panels do not display raw IP addresses.

No online system can be guaranteed absolutely secure, but Srev's Crew uses technical and organizational controls intended to protect confidentiality, integrity, and availability.

6. Sharing and Recipients

Authorized Srev's Crew staff may access data only where their .SREC. ID permissions and case department allow it.
Discord may be used for optional public login, optional account linking, Discord-side moderation actions, member DMs, custom battle moderation notifications, and internal staff notifications where the feature or user choice requires it.
Google and Apple may be used for optional public login and .SREC. ID creation or attachment where enabled or configured. Data is exchanged with the selected provider only as needed for provider login and according to that provider's own terms and privacy practices.
Roblox, Steam, War Thunder, and other supported platforms may be used for account linking, ownership verification, public profile display, feature eligibility, moderation context, or abuse prevention where enabled. Data is exchanged or checked only as needed for the relevant feature and according to the provider's own terms and privacy practices.
Official Srev's Crew Roblox game servers may receive the minimum active game-ban data needed to enforce current bans, check whether a player may use a dedicated appeal experience, pass the relevant user's active ban snapshot to the in-game appeal UI after consent, and submit in-game report or appeal data to Srev's Crew support systems. Secrets and internal credentials are not published and are not part of user-facing records.
When Roblox is used to transmit report, ban-check, or appeal data, Srev's Crew is responsible for its own receipt, storage, routing, and review of that data. Roblox remains responsible for Roblox's own platform services, API transport, account systems, infrastructure, and independent processing. Srev's Crew cannot guarantee Roblox-side confidentiality, availability, delivery, or correct platform behaviour, except where mandatory law imposes non-waivable responsibility on Srev's Crew.
Email or SMTP providers may process email addresses and email content needed for verification, password reset, 2FA, and opted-in newsletter messages.
Hosting and infrastructure providers may process technical data as necessary to run the service.
Data may be shared where required by law, lawful authority, platform safety requirements, or urgent protection of the community.
Personal data is not sold.

7. Retention

Data is kept only as long as necessary for the purpose it was collected. Account sessions, temporary verification codes, reset tokens, and temporary authentication states are short-lived. .SREC. ID data is retained while the ID exists or while needed for security, abuse prevention, or legal purposes. Platform verification records are retained while the link exists or while needed for moderation, account recovery, abuse prevention, or audit purposes. Provider authorization states are short-lived, and Srev's Crew does not intentionally retain long-lived provider access tokens for normal account linking unless a future provider feature clearly requires it and the privacy information is updated accordingly. Newsletter preferences are retained until changed by the user or removed with the account. Contest entries, suggestion records, EC vote records, public vote records, and reward-related review data are retained while needed to run the relevant community workflow, resolve disputes, prevent abuse, document rewards, or protect Srev's Crew legally. Birthday correction tickets and their identity-evidence uploads are deleted after acceptance or rejection. Other tickets, support chat messages, community profile data, public channel messages, friend requests, flags, attachments, audit logs, moderation records, custom-battle command, vote, room, and restriction records, legal acknowledgement records, staff applications, review decisions, and enforcement records may be retained longer where needed for appeals, safety, accountability, repeat abuse detection, staff oversight, or legal protection. Roblox in-game report metadata, Roblox appeal experience metadata, consent acknowledgements, and Roblox game-ban records may be retained where needed to prove what happened, prevent repeated abuse, enforce active restrictions, process unbans, handle appeals, or maintain staff accountability. Custom-battle operational data may be kept briefly for live-room operation, while moderation outcomes, Custom Battle ban records, unban records, command results, and appeal-relevant logs may be kept longer where needed to prove what happened, prevent repeated abuse, handle appeals, or maintain staff accountability. Hashed IP access restrictions are retained while active and in limited admin audit history where needed to document security decisions. Rejected tickets are not automatically deleted unless a specific flow, such as birthday correction, states that deletion is part of the process.

If an authorized account deletion review is accepted, the .SREC. ID login account may be scheduled for deletion after a thirty (30) day waiting period. A successful login during that waiting period reactivates the .SREC. ID login account, cancels the scheduled deletion, and requires a new deletion request if the user still wants deletion. Automated scheduled deletion covers the login account record unless a separate Data Erasure review confirms that additional associated datasets are eligible for removal.

Associated public profile data, linked-platform references, friend links, public .SREC. Community Hub data, tickets, moderation records, safety records, legal acknowledgement records, staff records, audit logs, and security records are reviewed according to their own purpose and retention need. They may be deleted, anonymized, restricted, detached, or retained where required for safety, accountability, repeat-abuse detection, appeal handling, legal protection, staff oversight, platform integrity, or another legitimate reason. A stable .SREC. ID reference may be retained where removing it would break records or hide the link between retained moderation, safety, legal, or audit context and the correct account.

8. Your Rights

Access to your personal data.
Correction of inaccurate data.
Deletion where legally permissible.
Restriction of processing.
Objection to processing based on legitimate interests.
Data portability where applicable.
Withdrawal of consent where processing is based on consent.
Complaint to a competent data protection supervisory authority.

Users can change newsletter preference, available .SREC. ID security settings, and supported platform links in their account settings where the feature is available. Deletion or correction requests may require verification so staff can ensure the request relates to the correct person and dataset.

Srev's Crew aims to answer verified rights requests without undue delay and normally within one (1) month after receipt. Where a request is complex or numerous requests are received, the response period may be extended where legally allowed, and the requester should be told about the extension and the reason for it. If Srev's Crew cannot identify the requester or the relevant dataset safely, additional information may be requested before acting.

Requests may be limited where access would compromise another person's rights, staff confidentiality, security, legal obligations, or active investigations.

9. Routing and Human Review

Ticket type and platform may route a case to the responsible staff department. This routing does not itself impose sanctions. Moderation and appeal outcomes are handled by authorized staff.

For meaningful moderation, access, account, linked-platform, Community Hub, or safety decisions, the affected user should receive or be able to request the main action, reason, service or platform scope, duration where applicable, and the official appeal or complaint route. Srev's Crew may limit the explanation where disclosure would expose private third-party data, confidential staff information, security-sensitive methods, active investigation details, or information that would enable abuse or evasion.

Where Srev's Crew is legally required to provide an internal complaint-handling route for online-platform decisions, complaints should be available electronically, free of charge, and for the required period after the user was informed of the decision. Any required out-of-court dispute settlement information will be provided where that obligation applies.

Custom Battle moderation may rely on existing moderation records, active restrictions, authorized staff review, and official support or appeal records. Public summaries must not describe internal operational details, account functions, timing, thresholds, or implementation methods.

Feedback routing, routing hints, AI-assisted support tools, and staff drafting tools may assist staff or eligible users, but they do not remove the availability of human review where a moderation outcome is contested.

.SREC. AI and .SREC. Assistant outputs provide guidance or draft text only and do not approve, reject, sanction, erase, disclose data, or verify age-evidence images.

Srev's Crew does not use AI outputs as the sole basis for decisions that produce legal effects or similarly significant effects for a user. Where a user contests a meaningful moderation, access, or appeal outcome, authorized human review remains available through the official flow.

10. Minors

Srev's Crew services are intended for users who meet the minimum age requirements in the Terms of Service and the rules of the external platforms they use. Birthday information is required for .SREC. ID accounts so age-gated rules and applications can be enforced. Normal .SREC. ID access currently requires users to be at least fourteen (14), member-to-member .SREC. Community Hub direct messages require users to be at least sixteen (16), and staff access requires users to be at least eighteen (18). The previous pre-minimum-age buffer is not active unless Srev's Crew expressly republishes and enables a future buffer policy. For users under eighteen (18), Srev's Crew records whether the user confirmed that a parent or legal guardian agreed to the .SREC. ID registration and the current Terms of Service and Privacy Policy. Birthday corrections, voluntary age verification, and staff-required age verification require only the evidence shown in the correction flow and are reviewed by authorized human staff, not by machine-only document-scanning systems. Users should not submit unnecessary personal information and must cover unrelated information on legal identification before upload.

11. Changes

This Privacy Policy may be updated when systems, security measures, or legal requirements change. The current version is published on this website.

12. Applicable Law

This Privacy Policy is governed by the laws of the Federal Republic of Germany where applicable.