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 .SREC. web, backend, and bot security model.

1. Controller

The controller responsible for processing personal data is Srev's Crew (.SREC.). 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

Discord user ID, username, avatar, and authentication session data received through Discord OAuth where 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 .SREC. controlled delivery where needed to avoid exposing unnecessary identifiers.
When a user continues with Discord and no existing .SREC. ID is linked, .SREC. 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, .SREC. may create a random .SREC. ID for that user and attach the verified provider identity to it.
Linked Discord identity data used for member records, Discord-side moderation actions, ticket notifications, and optional account association.
Staff-only website permissions are assigned to .SREC. IDs and require .SREC. ID password login with authenticator-app 2FA. External provider login does not unlock staff tools.
.SREC. 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 Discord account 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, and derived age eligibility used for Terms of Service enforcement, staff applications, Peacekeeper applications, and other age-gated features.
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.
User-provided, staff-reviewed, or provider-verified platform links may be stored under the user's .SREC. ID for record matching, support, custom moderation, event access, peacekeeper access, public profile display, or abuse prevention.
.SREC. 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.
Newsletter preference and email delivery audit data where a verified user opts in to .SREC. 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.
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, linked Discord and platform identities, and peacekeeper lists.
Staff activity time statistics where staff systems track operational presence or moderation time.
Internal bot 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.

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

Logged-in .SREC. 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 where necessary to enforce rules, investigate abuse, or protect the community.

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. 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 .SREC. 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 .SREC. 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, .SREC. 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 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.9 Cookies and Browser Storage

.SREC. 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.

.SREC. 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 .SREC. 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.10 Public .SREC. AI and Internal .SREC. Assistant

The public .SREC. AI guide and internal .SREC. Assistant currently operate as local guidance and drafting tools. They do not send ticket contents or user questions to an external AI provider.

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

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, and community safety: Art. 6(1)(f) GDPR.
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.

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, complaints are routed to Internal Affairs, and staff applications are routed to Human Resources. 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. 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 bot 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 .SREC. uses technical and organizational controls intended to protect confidentiality, integrity, and availability.

6. Sharing and Recipients

Authorized .SREC. staff may access data only where their .SREC. ID permissions and case department allow it.
Discord is used for optional public login, account linking, Discord-side moderation actions, member DMs, and internal staff notifications.
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, event access, peacekeeper checks, 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 .SREC. 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 event or workflow, resolve disputes, prevent abuse, document rewards, or protect .SREC. legally. Tickets, support chat messages, community profile data, public channel messages, friend requests, flags, attachments, audit logs, moderation 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. 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.

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. Automated Decisions

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

.SREC. AI and .SREC. Assistant outputs are not automated decisions. They provide guidance or draft text only and do not automatically approve, reject, sanction, erase, or disclose data.

10. Minors

.SREC. 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. Users should not submit unnecessary personal information.

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.