Introduction
RackList is an independent hosting provider comparison platform (VPS, game, dedicated, web). Protecting your personal data is a foundational requirement: this policy describes what data we collect, for what purposes, on what legal basis, for how long and how you can exercise your rights. No data is sold, rented or shared with third parties for commercial or advertising purposes.
For the exhaustive list of cookies and local storage entries used by RackList (name, type, lifetime, purpose, consent basis), see our dedicated cookie policy. Consent for non-strictly-necessary cookies (Cloudflare Web Analytics) is collected through the RackList consent banner - accept and reject presented with visual parity per the CNIL 2020 guidelines. No advertising cookie.
Data controller
RackList is operated by Alexandre ETEOCLE (sole trader), acting as data controller within the meaning of Article 4.7 GDPR.
Given the nature of the processing (no sensitive data under Article 9 GDPR, no large-scale profiling, no behavioural tracking), appointing a DPO is not mandatory under Article 37 GDPR. Requests are handled directly by the controller within 30 days pursuant to Article 12.3 GDPR.
Data collected
User account
At sign-up we collect:
- E-mail address (encrypted at rest via libsodium, indexed through deterministic blind-index for authentication)
- Username (encrypted at rest, publicly displayed on your reviews)
- First/last name (encrypted at rest, optional)
- Password (bcrypt hashed - never readable in plaintext)
- OAuth identifiers (Google, Discord, GitHub, ClientXCMS) if you choose federated sign-in
- Preferred language and light/dark theme
Host profile
If you claim or create a host profile:
- Public information about the host (trade name, website, logo)
- Declared infrastructure (datacenters, ASN, hosting types, network carriers)
- Commercial offers (plans, pricing, specifications)
- Company legal information (registered name, country, registration number - when voluntarily provided)
Reviews
Your rating, title, content and user identifier. Reviews are public and associated with your username. A non-identifying browser fingerprint and IP address are retained solely for fraud detection and anti-multi-account.
Internal messaging
Subject, content and participants of conversations between users and hosts. Readable only by the conversation's participants.
Technical data
For service operation and security:
- IP address (session, reviews, fraud detection)
- Browser user-agent (session, fraud)
- Session identifier (server-side encrypted cookie, TTL 24h)
- Non-identifying browser fingerprint (reviews only, anti-duplicate)
OAuth scopes requested per provider
When you choose federated sign-in, RackList only requests the authorisations strictly necessary to create the account. You can verify exactly what we ask for by reading the connect controllers (App\Controller\Security\OAuth\*Controller.php) and revoke the authorisation at any time at the provider.
| Provider | Requested scopes | Data received |
|---|---|---|
| openid email profile | Google identifier (sub), verified e-mail address, display name, profile picture | |
| Discord | identify email | Discord identifier, username (and legacy discriminator), e-mail address, avatar |
| GitHub | user:email | GitHub identifier, public login, public profile, primary e-mail address (the first verified one if several) |
| ClientXCMS | (default scope, no explicit scope requested) | ClientXCMS identifier, e-mail and name exposed by the OAuth2 instance configured via OAUTH_CLIENTXCMS_URL |
What we never request
No write scope (mail send, posting, contacts management, calendar/drive access, Discord guilds.join scope, GitHub repo scope). If an OAuth provider adds a new default scope, we document it here on the next update.
Purposes and legal bases
Each processing activity relies on an explicit legal basis under Article 6 GDPR. A record of processing activities is maintained under Article 30 GDPR and provided upon reasoned request.
| Purpose | Legal basis | Retention period |
|---|---|---|
| Account management and authentication | Performance of contract (Art. 6.1.b) | Lifetime of the account |
| Publication and display of reviews | Performance of contract (Art. 6.1.b) | As long as the account exists |
| Retention of anonymised reviews after partial erasure | Legitimate interest (Art. 6.1.f) | No fixed limit, unless objected to with reasons |
| Fraud detection, anti-multi-account, moderation | Legitimate interest (Art. 6.1.f) | 12 months from last activity |
| User ↔ host messaging | Performance of contract (Art. 6.1.b) | As long as both accounts exist |
| Security, abuse prevention, bans | Legitimate interest (Art. 6.1.f) | 12 rolling months |
| Administrator action log (audit) | Legal audit obligation + legitimate interest | 5 years (PII purged on account deletion) |
| Newsletter delivery | Consent (Art. 6.1.a) | Until unsubscribe |
Focus: retention of anonymised reviews (ERASE_PRIVATE)
When you choose the "Erase my private data" option (ERASE_PRIVATE) from your account deletion page, your personal data (e-mail, name, password, OAuth, private messages, notifications, alerts) is permanently erased. Your public reviews, however, are retained with an anonymised identity. Below we detail the legal basis and the balancing analysis that justify this retention.
Legal basis: legitimate interest (Art. 6.1.f GDPR)
Retention of anonymised reviews relies on the legitimate interest pursued by RackList and the community of hosting consumers, in accordance with Article 6.1.f GDPR. This legitimate interest prevails as long as it does not disproportionately override your rights and fundamental freedoms - severing the link between the review and your identity ensures this proportionality.
Legitimate purpose
- Public utility: informing future customers about the quality and reliability of listed hosts.
- Collective knowledge: removing an individual review would degrade the representativeness of aggregate scores computed over years of history.
- Freedom of expression and information (Article 11 EU Charter of Fundamental Rights, Article 10 ECHR), within which consumer reviews fall.
- Preventing manipulation: allowing an author to delete their negative reviews on demand would enable buy-to-delete practices and distort competition.
Balancing test
We have evaluated the balance between our legitimate interest and your rights in accordance with EDPB guidelines (formerly WP29, WP217). Factors considered:
- Nature of retained data: exclusively content you voluntarily authored for publication, with an anonymised identifier unlinked from your identity. No sensitive data under Article 9 GDPR is involved.
- Reasonable expectation: by publishing a public review, you could reasonably anticipate it would remain consultable over time (established consumer case law - TGI Paris, 11 April 2013; CA Paris 1st ch., 10 March 2021).
- Identity link severed: name, e-mail, OAuth, IP and fingerprint associated with your account are erased. The review is no longer attributable to an identifiable person under Article 4.1 GDPR.
- Public benefit: third-party consumers and the hosting market gain measurable value from the persistence of review history.
Safeguards in place
- You freely choose among five deletion policies (deactivation, hiding, anonymisation, partial erasure, full erasure). Only full erasure removes reviews.
- The ERASE_ALL option is always available and permanently removes your reviews if you deem your interest superior - no tariff barrier or technical friction limits this choice.
- A 30-day reflection period allows you to revert any erasure request (see dedicated section below).
- No residual technical identifier (IP, fingerprint, user-agent) can re-associate an anonymised review with your identity post-erasure.
- Optional "public erasure notice" explicitly displaying the exercise of the right to erasure on the reviews concerned.
Reinforced right to object (Art. 21 GDPR)
Even after choosing ERASE_PRIVATE, you retain the right to object to the retention of your anonymised reviews by invoking legitimate grounds relating to your particular situation (Art. 21.1 GDPR). Send your reasoned request to contact@racklist.eu: we will escalate your case to ERASE_ALL (full removal of reviews + recalculation of host scores) unless we can demonstrate compelling legitimate grounds overriding your interests, rights and freedoms. In case of persistent disagreement, you may refer the matter to the CNIL (French DPA).
Record of processing (Art. 30 GDPR)
This processing is entered in the record of processing activities maintained by the controller. Record contents for this activity: purpose (public utility of hosting reviews and integrity of aggregate scores), categories of data (content + rating + anonymised identifier), recipients (public), legal basis (legitimate interest - Art. 6.1.f), retention period (no fixed limit, unless objected to with reasons), security measures (identity link severance, at-rest encryption of remaining data). A copy of the record is provided upon reasoned request to contact@racklist.eu.
30-day reflection period
When you request an irreversible account deletion (ANONYMIZE, ERASE_PRIVATE, ERASE_ALL), your request is not executed immediately: it is recorded and a 30-day reflection period elapses before any destructive operation on your data.
Legal nature of the delay
This delay is a **reflection period (cooling-off period)**, not a retention period under GDPR. Article 17 GDPR requires erasure "without undue delay" but does not prohibit arranging a cancellation window designed to protect the user against impulsive decisions or fraudulent access to their account. RackList is subject to no legal obligation (fiscal, AML, commercial) that would require retaining your data beyond your request: the 30-day window exists solely in your interest and may be interrupted by you at any time.
Key distinction
Retention period = legal obligation imposed on the controller to retain data for a defined duration (e.g., accounting: 10 years). We have none of these on your account data.
Reflection period = cancellation window offered to the user, revocable by the user themselves. No obligation on our side, purely a guarantee for you.
Right to cancel
During the 30 days, you can cancel your request in two equivalent ways, free of charge and without justification:
- By logging back into your account: the interface offers one-click cancellation.
- By activating the cancellation link in the confirmation e-mail you received when submitting the request.
Cancellation is immediate and complete: all your data remains intact, no irreversible operation has been performed. Cancellation is technically guaranteed as long as the `deletion_requested_at + 30 days` timestamp has not passed.
After the reflection period
Upon expiration of the 30 days, the policy you selected is executed irreversibly by an automated process (transactional purge). You then receive an e-mail confirming execution. After this point, no recovery is possible.
Policies without reflection period
Reversible policies (DEACTIVATE, HIDE_PROFILE) take effect immediately and can be cancelled at any time - no delay, since no data is erased.
Automated decisions and profiling (Art. 22 GDPR)
RackList applies no automated decisions producing legal effects or significantly affecting users under Article 22.1 GDPR. The fraud detection service (`FraudDetectionService`) uses automated rules (fingerprint, IP, patterns) to **flag** suspicious behaviour to a human moderator who takes the final decision. Host scores are public statistical aggregates, not individual decisions about you. No advertising, behavioural or personal-rating profiling is performed.
Data Protection Impact Assessment (DPIA - Art. 35 GDPR)
Article 35 GDPR requires a Data Protection Impact Assessment (DPIA) when a processing operation is likely to result in a high risk to the rights and freedoms of natural persons.
Obligation assessment
Having analysed the cumulative criteria defined by Art. 35.3 GDPR and the French supervisory authority's (CNIL) list of processing operations subject to a mandatory DPIA (deliberation no. 2018-326 of 11 October 2018), RackList considers that a formal DPIA is **not mandatory** at this stage of the service. The reasoning is documented below in line with the accountability principle (Art. 5.2 GDPR).
Criteria ruled out
None of the usual triggers for a mandatory DPIA apply:
- No processing of sensitive data within the meaning of Art. 9 GDPR (health, religious/political/union views, sexual orientation, biometric data, genetic data).
- No large-scale processing: the current user base remains well below the alert thresholds set by the WP29/EDPB guidelines (WP248).
- No systematic large-scale monitoring of a publicly accessible area (Art. 35.3.c).
- No fully automated decision producing legal effects or significantly affecting individuals (Art. 35.3.a and Art. 22) - see dedicated section.
- No processing specifically targeting vulnerable persons (minors, employees, patients) beyond what is strictly necessary for account creation (see Minors section).
- No use of innovative technology carrying new risks (facial recognition, behavioural biometrics, IoT, decision-making AI, etc.).
- No cross-referencing or combination of datasets originating from heterogeneous purposes.
Commitment to reassessment
The current absence of a formal obligation does not relieve us from anticipating. Accordingly:
- A full DPIA will be carried out and documented before crossing large-scale thresholds, introducing any high-risk processing (individual profiling, personal reputation scoring, biometrics), or rolling out any functional change that introduces a new risk.
- Every substantial evolution of the service is preceded by a risk analysis and, where relevant, an update to the record of processing activities (Art. 30 GDPR).
- Privacy-impacting design choices - encryption at rest (libsodium), HMAC pseudonymisation of deleted accounts, 30-day cooling-off period, data minimisation, explicit purposes, strict public/private separation of user artefacts - are documented in the source code and in this policy, operating as the practical implementation of the « privacy by design » principle (Art. 25 GDPR).
- If there is any doubt about the risk level of a new processing operation, a prior consultation of the CNIL (Art. 36 GDPR) will be initiated before going live.
Transparency
The present decision not to run a DPIA at this stage is dated, reasoned and revisable. A summary of the risk analyses carried out (current and future) can be provided on motivated request at contact@racklist.eu.
Transfers outside the European Union (Art. 44-49 GDPR)
Application data is hosted on servers located within the European Economic Area (Hetzner Online GmbH, Germany), with IP transit operated from France by Royale Hosting. No transfer outside the EEA is performed by default. If an occasional provider (OAuth identity provider, CDN, payment processor) involves a transfer, it is covered by the standard contractual clauses adopted by the European Commission (Decision 2021/914) or a valid adequacy decision (notably the EU-US Data Privacy Framework, Decision 2023/1795). The detailed list of sub-processors with access to part of the data is set out in Annex 3 of the Data Processing Agreement (DPA) and is provided upon reasoned request at contact@racklist.eu.
Minors (Art. 8 GDPR)
The service is not intended for persons under 15 years of age. Registration requires having reached the digital consent age (15 years in France under law no. 2018-493). If we become aware that an account has been created by a minor under 15 without verifiable parental consent, the account is deleted and associated data erased.
Personal data breach (Art. 33 and 34 GDPR)
In the event of a breach likely to result in a risk to your rights and freedoms, we notify the CNIL within 72 hours of discovery, in accordance with Article 33 GDPR. If the risk is high, you are individually informed without undue delay through a separate channel (e-mail + in-app banner), in accordance with Article 34 GDPR. Incident details, affected data, measures taken and recommendations are communicated clearly and intelligibly.
Data collected indirectly (Art. 14 GDPR)
Some personal data we process is not collected directly from the data subject but received from a third party. Pursuant to Article 14 GDPR, the table below details these sources, purposes, legal bases and how to exercise your rights.
Why this section
Article 14 GDPR requires the controller to inform any person whose data has been collected indirectly. The information must be provided within a reasonable period and at the latest within one month after obtaining the data, or upon first communication with the data subject. This section serves as that general information; an individual notification is also triggered whenever a specific category of persons is concerned (see table below).
Indirect sources used by RackList:
| Source | Categories of data received | Purpose | Legal basis | Retention | How to object |
|---|---|---|---|---|---|
| OAuth providers (Google, Discord, GitHub, ClientXCMS) | Provider unique identifier, verified e-mail address, public display name, profile picture or avatar (depending on the requested scope - see Data collected section) | Create and link a RackList account on federated sign-in | Performance of contract (Art. 6.1.b GDPR); prior consent given to the OAuth provider itself | As long as the OAuth link is active. Immediate removal via /account ("Linked accounts" section). | Unlink the OAuth account from /account; revoke the authorisation directly with the provider (Google: myaccount.google.com/permissions, Discord: Authorized Apps, GitHub: Settings/Applications). |
| recherche-entreprises API (annuaire-entreprises.data.gouv.fr / Sirene INSEE / RCS BODACC) | Legal name, SIREN/SIRET, NAF code, registered office address, company size category, names and birth year of natural-person directors | Pre-fill and verify hosting-provider listings published on RackList. Director names are accessible only to administrators during moderation and never displayed publicly. | Legitimate interest (Art. 6.1.f GDPR) - publication of a B2B hosting directory based on public data released under Etalab Open Licence 2.0 | 24-hour cache at RackList. Data is rendered only as long as the host is listed. | Any person whose name appears in a listing may object (Art. 21 GDPR) by writing to contact@racklist.eu: we will redact nominative data on the listing as soon as practicable, unless we can demonstrate compelling legitimate grounds (record kept under reference LIA-RACKLIST-001). |
| Hosting-provider invitation form (referral) | Generic e-mail address shaped as info@<provider-domain>, host trade name, invitation reason | Send a single invitation to the maintainer of a listed host so they can claim their listing. No automated follow-up. | Legitimate interest (Art. 6.1.f GDPR) - B2B outreach with an explicit objection notice | Recipient e-mail address is kept for 90 days for anti-spam purposes and then purged. No automated re-contact. | Every invitation carries a one-click opt-out link to /referral/optout/<token> (cf. F-CONS-06). The objection is final and blocks any future invitation for that domain. |
Your rights over indirect data
The rights described in the "Your rights" section apply in full to indirectly collected data. You can exercise the right of access, rectification, erasure, objection or restriction by writing to contact@racklist.eu. If you discover the existence of a processing operation concerning you while reading this policy, the GDPR response deadline (30 days, Art. 12.3) starts running from your request.
Retention periods
- Account data: retained while the account is active. Definitive erasure 30 days after your request (reflection period, cancellable).
- Reviews: as long as the account exists.
- Anonymised reviews (after ERASE_PRIVATE or ANONYMIZE): no fixed limit, unless objected to with reasons (see legitimate interest section).
- Private messages: as long as both participants have an active account.
- Sessions: 24 hours after last activity.
- Administrator action logs: 5 years, with automatic PII purge when the relevant account is deleted.
- Anti-fraud data (IP, fingerprint): 12 rolling months.
Your rights
Under GDPR (Articles 15 to 22), you have the following rights over your personal data:
- Right of access (Art. 15): obtain a copy of all data we hold about you.
- Right to rectification (Art. 16): correct inaccurate information via /account/profile/edit (email, username, first name, last name). Any email change triggers a fresh verification.
- Right to erasure (Art. 17): five granular policies available from /account/delete, including full erasure (ERASE_ALL).
- Right to portability (Art. 20): structured JSON export of your data via /account/export.
- Right to object (Art. 21): notably against processing based on legitimate interest (e.g., retention of anonymised reviews), by invoking grounds relating to your particular situation.
- Right to restriction (Art. 18): temporarily freeze a contested processing pending investigation.
- Right to withdraw consent (Art. 7.3): at any time for processing based on consent (newsletter notably), as easily as given.
- Right not to be subject to automated decision-making (Art. 22) - not applicable at RackList: no automated decisions are applied.
Scope of rights
These rights cover your personal data (account, e-mail, messages, reviews). Host profiles constitute editorial content of public interest and do not fall under personal erasure rights. In accordance with the LCEN (Art. 6) and the EU Digital Services Act (EU 2022/2065, Art. 6 and 8), RackList has no general monitoring obligation and only removes content upon judicial decision or manifestly illegal content properly notified.
How to exercise your rights
Immediate response via /account/export for access and portability (art. 15 and 20). For other rights (rectification, erasure, objection, limitation, automated decisions), write to contact@racklist.eu stating your request and attaching proof of identity (account e-mail). We reply within 30 days as per Art. 12.3 GDPR, extendable by two months in complex cases. In case of unsatisfactory response, you may lodge a complaint with the CNIL (cnil.fr, 3 place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07) or the supervisory authority of your member state.
Security
Technical and organisational measures implemented: at-rest encryption of personal data (libsodium) with deterministic blind-index for authentication, bcrypt password hashing, HTTPS only (TLS 1.3), double-submit CSRF protection, login throttling (5 attempts/minute), secure sessions with automatic expiration, administrator access logging, backup encryption, least-privilege principle on server access, dependency reviews and regular security audits (composer audit + PHPStan level 8).
Backups (3-2-1 rule)
RackList strictly applies the 3-2-1 rule on all PostgreSQL backups, ensuring both operational resilience (DRP) and compliance with the security obligation (Art. 32 GDPR).
3-2-1 rule in practice
One active copy in production + two distinct backups automatically generated (logical dump + physical replication).
Primary storage on the application cluster (NVMe SSD) and secondary storage on an independent backup array (different software stack, different vendor, different format).
At least one geographically distant copy, stored with a third-party European host, isolated from the production network (pull-based, no production credentials reach the backup site).
Backup encryption
All backups are encrypted at rest via AES-256-GCM with a key distinct from the one used for application encryption (libsodium). Backup encryption keys are stored in an out-of-band secret manager and rotated annually. Offsite backups are also encrypted in transit (TLS 1.3) and at rest (remote storage's native encryption).
Backup retention period
- Daily backups: 30 rolling days.
- Weekly backups: 12 weeks.
- Monthly backups: 12 months.
- Beyond this, automatic rotation: each expired backup is destroyed via cryptographic erasure (key destruction) + storage overwrite.
Technical limitation: selective purge on dumps is impossible
**Important GDPR transparency note:** PostgreSQL produces backups as binary dumps or WAL streams. Selective purge targeting a given user's data within an encrypted dump is technically impossible without rebuilding the entire dump - an operation not feasible at scale without compromising the backup chain integrity. This constraint is shared by all state-of-the-art database backup systems.
Compensating measures
- Strictly bounded backup retention (maximum 12 months) and documented.
- Strong encryption at rest and in transit: even in case of illegitimate access to a dump, data remains unintelligible.
- Backup access restricted to the technical administrator, logged, subject to multi-factor authentication.
- No restoration for any purpose other than disaster recovery: dumps are never used to read or export a specific user's data.
- At end of retention, encryption keys are destroyed (crypto-shredding) making data unrecoverable even in case of residual storage persistence.
This design complies with CNIL and EDPB doctrine (EDPB Guidelines 5/2020, §38) which accepts that an erasure request may be held pending while backups are naturally renewed, provided that: (1) retention duration is limited and documented, (2) backups are not reused outside DRP, (3) the user is informed. This section informs you.
Restore tests
Automated monthly restore tests on an isolated environment - verifying dump integrity, encryption, volume and relational consistency. Any failure triggers an alert and manual retest.
Profile picture sourced from an OAuth provider
When you create your account through Google, GitHub or Discord, the identity provider sends us, among the public profile fields, a URL pointing to your profile picture hosted on its own infrastructure. This section explains exactly how this URL is handled.
What we store
Only the public URL of the picture is recorded in the RackList database, as a text string attached to your account. We do not download the picture, we do not copy it to our servers and we do not create any local copy. The picture itself stays hosted with the original provider.
How the picture is displayed
When a RackList page needs to render your picture (your profile, your reviews, your account header), your browser reads the URL embedded in the HTML and fetches the image directly from the provider. RackList does not serve the image, does not cache it and does not act as a technical intermediary for this content.
Concrete consequence at each provider
- Google (lh3.googleusercontent.com): Google receives an HTTP request from your browser every time your picture is rendered on RackList. The request contains your IP address and the fact that you were on racklist.eu at that moment.
- GitHub (avatars.githubusercontent.com): same pattern, GitHub sees one request per render with your IP address and the racklist.eu page of origin.
- Discord (cdn.discordapp.com): same pattern, Discord sees one request per render with your IP address and the racklist.eu page of origin.
How to control this behaviour
You can remove this picture from your RackList account at any time via the Edit my profile page, or by deleting your account. Once the URL is removed, your browser stops sending requests to the provider. You can also control which picture is shown by changing it directly at the provider (Google, GitHub, Discord): on your next login to RackList, the new value is recorded.
Changes to this policy
We may update this policy. In case of substantial changes (new purpose, new recipient, change of legal basis), you are notified by e-mail at least 30 days before the effective date. The last updated date is shown at the top of this page. Version history is kept and provided on request.