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, six-month pre-minimum-age buffer acknowledgement state, optional human-reviewed age-verification status, and derived age eligibility used for Terms of Service enforcement, 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.
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.
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.
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, .SREC. COMMS, 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.

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.

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, Suggestions, 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.

Suggestions and community feedback may process the submitter identity, profile reference, title, message, comments, votes, moderation state, review state, implementation state, and staff audit entries where needed to run suggestion workflows, 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 Committee votes may process candidate display names, representative phase 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 representative phase, 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.

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.

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, suggestions, 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.
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 and technical requests are routed to Support staff, moderation reports are routed to Moderation, staff-conduct complaints are routed to Internal Affairs, and staff applications, onboarding, training, transfers, and lifecycle requests are routed to Human Resources. Human Resources is separate from Internal Affairs and is not the ordinary staff-misconduct investigation route. Internal Affairs and Admin roles may access broader case categories for oversight, and Admins 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.
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 Development/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.
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. 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.

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.

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.

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.

Suggestions, 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. A limited buffer may apply before the standard minimum age where the Terms allow it. For normal member accounts, buffer eligibility may create a Support review ticket; for staff access, review is handled through .SREC. Access. Some features remain restricted until the normal age threshold is met. 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.