Garder votre nom à l'écart d'un serveur : guide pratique

Là où votre identité peut fuiter vers un serveur

Un serveur est privé seulement jusqu'au maillon le plus faible de la chaîne. Votre identité peut s'accrocher à quatre points distincts, et une seule fuite à l'un d'eux dénoue toute la chaîne : le domaine (enregistrements WHOIS publics), le compte d'hébergement (identité KYC et de facturation), le paiement (les cartes et virements bancaires renvoient directement à un nom légal), et les métadonnées opérationnelles que vous générez au fil du temps — clés SSH réutilisées, pseudonymes recyclés, un e-mail que vous utilisez aussi pour vos achats, une session de navigateur qui croise les personas.

Vouloir fermer ces points est ordinaire et légal. Les journalistes protègent leurs sources, les militants se protègent eux-mêmes, les entreprises protègent leur infrastructure des concurrents et des attaques ciblées, et beaucoup de personnes refusent simplement d'alimenter l'économie de la collecte d'identité pour aucune raison autre que de préférer la confidentialité par défaut. Rien de tout cela ne nécessite de justification. Le travail est mécanique : gérez chaque couche délibérément pour qu'aucun enregistrement, assignation ou scraping ne rassemble le tableau complet.

Couche un : le domaine

Le WHOIS public affichait autrefois le nom, l'adresse, l'e-mail et le téléphone du titulaire pour que tout le monde puisse les extraire. L'ICANN masque désormais la plupart des champs personnels par défaut en vertu du RGPD, mais le registrar conserve toujours vos véritables coordonnées et peut être contraint de les communiquer — le masquage est un rideau, pas un mur. Deux mesures le renforcent. Premièrement, optez pour un registrar proposant une véritable confidentialité WHOIS plutôt que de revendre vos données. Deuxièmement, privilégiez un registrar de type Njalla qui enregistre le domaine en son propre nom et vous accorde un droit contractuel de l'utiliser : vos coordonnées ne figurent jamais comme titulaire officiel du domaine.

Payez le registrar en crypto dans la mesure du possible, conservez le compte de domaine sur un pseudonyme et une adresse e-mail que vous n'utilisez pour rien d'autre, et gérez votre DNS sur des serveurs de noms non trivialement liés à vous. Si le domaine et l'hébergeur sont chez deux entreprises différentes dans deux pays différents, ni l'un ni l'autre ne détient à lui seul l'histoire complète.

Couche deux : le compte d'hébergement

La plupart des hébergeurs exigent une identité à l'inscription — un nom, une adresse, parfois une copie de document — et cet enregistrement réside dans leur système de facturation pour toute la durée du compte. Un hébergeur no-KYC supprime ce point de fuite par conception. Chez nous, le compte entier est un pseudonyme et un mot de passe ; un pseudonyme est parfait, aucun e-mail n'est enregistré, et aucune vérification d'identité n'a lieu à aucune étape. Ce que nous conservons techniquement est court et inventorié sur la page de politique no-KYC : le pseudonyme choisi (les fichiers de compte sont indexés par un hash SHA-1 de celui-ci), un hash argon2id du mot de passe, votre solde, les caractéristiques de vos commandes, et des journaux serveur supprimés par rotation rapidement. Rien dans cet ensemble n'est votre nom légal, car nous ne le collectons jamais.

La juridiction importe plus que la dissimulation ici. Choisir où se trouve physiquement le serveur détermine quels tribunaux peuvent contraindre quoi que ce soit. Notre position est fixée et mérite d'être connue avant de construire : les demandes DMCA ne sont ni traitées ni répondues — le DMCA est une loi américaine sans valeur dans nos juridictions — et nous n'agissons que sur une ordonnance contraignante d'un tribunal compétent sur le serveur concerné. Choisissez la région délibérément ; le guide complémentaire sur le choix d'un emplacement offshore couvre les compromis.

Troisième couche : le paiement

Le paiement est le point où la plupart des configurations privées échouent discrètement. Une carte, un compte PayPal ou un virement bancaire se lie directement à votre identité légale et laisse un enregistrement permanent chez le processeur, peu importe le soin apporté au domaine et à l'hébergeur. La crypto rompt ce lien — mais toutes les cryptos ne se valent pas. Le Bitcoin est pseudonyme, et son registre est public et perpétuellement traçable ; une société d'analyse de chaîne peut souvent remonter un paiement BTC jusqu'à un retrait depuis un exchange effectué avec votre pièce d'identité. Monero (XMR) est privé par défaut, avec des signatures de cercle, des adresses furtives et des montants confidentiels qui rendent la même analyse impraticable, ce qui explique pourquoi il est en tête de notre liste de coins.

Notre modèle de solde préserve aussi la confidentialité de l'achat lui-même : vous rechargez votre compte à partir de $30.00 avec l'une des 17 devises (21 coins et variantes réseau), puis vous payez les serveurs depuis ce solde. Aucun processeur de paiement par commande ne voit jamais ce que vous avez acheté — il voit une recharge, rien de plus. Si vous devez utiliser Bitcoin, traitez-le comme traçable et convertissez via un échange no-KYC avant de recharger. Gardez des recharges modestes et banales plutôt qu'un grand chiffre rond qui se démarque dans n'importe quel enregistrement, et évitez d'alimenter directement depuis un retrait d'exchange qui porte votre empreinte KYC dans le paiement.

Couche quatre : hygiène opérationnelle

Ce qui échoue rarement, c'est la cryptographie — c'est l'humain. Authentifiez-vous à vos serveurs avec des clés SSH, pas des mots de passe, et utilisez une clé dédiée par projet pour qu'une compromission ne déverrouille pas tout. Ne réutilisez jamais le pseudonyme, l'e-mail ou le mot de passe de votre configuration privée là où ils touchent votre identité réelle ; un identifiant partagé effondre les personas. Travaillez dans son propre profil de navigateur ou une VM séparée, et ne vous connectez pas à des comptes personnels depuis la même IP de sortie que celle utilisée pour le serveur privé.

Répartissez délibérément la chaîne entre juridictions : le registrar dans un pays, l'hébergeur dans un autre, le rail de paiement dans un troisième, de sorte qu'aucune demande juridique unique n'atteigne l'ensemble. Surveillez aussi les fuites discrètes — des requêtes DNS qui s'échappent d'un tunnel, un enregistrement rDNS qui vous nomme, un script d'analytics, un message de support rédigé avec votre voix habituelle depuis votre adresse habituelle. Faites passer les questions liées aux commandes par le panneau plutôt que par tout canal lié à une identité personnelle, et maintenez un seul persona cohérent par projet pour que les personas ne se contaminent jamais. La confidentialité est le fruit de petits choix constants, pas d'un seul tour de passe-passe.

Ce qui est légal — et ce qui ne l'est pas

Il faut le dire clairement. La vie privée est légale. Posséder un serveur sans diffuser son nom est légal. Payer en Monero est légal. Aucune des techniques ci-dessus ne constitue un acte répréhensible, et les traiter comme intrinsèquement suspects est exactement le réflexe de surveillance auquel elles existent pour résister.

Mais l'anonymat n'est pas une licence, et il serait irresponsable de le suggérer. Cacher son nom ne rend pas légal un acte illégal, et cela ne vous protégera pas d'un tribunal compétent sur le serveur. No-KYC ne signifie pas sans règles : notre politique d'utilisation acceptable interdit le spam, le CSAM, le commandement et contrôle de malware, les attaques par déni de service et le phishing, et sa violation entraîne la suppression du serveur quelle que soit la discrétion du paiement. L'objectif de ce guide est de protéger les activités ordinaires et légitimes de la collecte de données de masse — non de prétendre que la loi s'arrête devant un rideau de confidentialité.

Un modèle de menace réaliste

Adaptez l'effort à l'adversaire. L'approche en couches décrite ci-dessus neutralise de manière fiable les menaces quotidiennes : courtiers en données, scrapers WHOIS, surveillance marketing, un FAI curieux, un attaquant opportuniste pivotant depuis une base de données compromise. Pour l'immense majorité des gens, ce sont les risques réels, et fermer les quatre points de liaison les élimine.

Elle ne neutralise pas un adversaire déterminé et bien doté disposant d'un accès légal à votre juridiction choisie et de la patience de corréler des métadonnées au fil du temps — et elle ne neutralise jamais vos propres erreurs. Un malware sur votre client, un identifiant réutilisé, une connexion personnelle depuis la mauvaise IP, ou un seul message imprudent suffiront à annuler une infrastructure parfaite. Décidez donc contre qui vous vous défendez réellement, construisez en conséquence, et réévaluez le modèle à mesure que votre situation évolue — une configuration qui convenait à une confidentialité occasionnelle peut nécessiter un renforcement si votre exposition augmente. Souvenez-vous que le maillon le plus faible est presque toujours la personne derrière le clavier, pas le chiffrement.