Ce que CPYNET conserve, ce qu'il ne conserve jamais, et pourquoi - vérifié ligne par ligne par rapport au code réellement en exécution, pas une politique générique.
Le contenu du paste ne vit qu'en mémoire (RAM) - il n'est jamais écrit sur disque ni dans une base de données. Il est définitivement supprimé au moment où il est lu (ou dès que son quota de lectures est épuisé) ou à l'expiration de son minuteur. Un redémarrage du serveur fait aussi perdre tout paste pas encore lu - ce n'est pas un bug, c'est tout l'intérêt.
S'il est protégé par mot de passe, il est conservé chiffré au repos avec AES-256-GCM ; le serveur ne garde le texte déchiffré en mémoire que pendant le bref instant où il vérifie un mot de passe. Avec le chiffrement zero-knowledge, le serveur ne voit jamais que du texte chiffré - la clé de déchiffrement ne lui parvient jamais.
Chaque requête génère une ligne de journal d'accès standard : IP du client, méthode HTTP, chemin (p. ex. /123456 - juste le code, jamais le contenu), code de statut, durée. Cela va vers le stdout propre du serveur (généralement capturé par systemd ou Docker), non stocké dans une base de données interrogeable par CPYNET lui-même.
Le panneau /admin (désactivé par défaut, accessible uniquement si ADMIN_PASSWORD est défini) conserve les 200 dernières entrées d'activité (qui a fait quoi, depuis quelle IP) et des compteurs de pastes cumulés - uniquement des métadonnées, jamais le contenu, visibles uniquement par celui qui détient le mot de passe administrateur.
Exactement deux : un cookie lang qui mémorise votre choix de langue, et - uniquement si vous vous connectez réellement au panneau d'administration - un cookie de session limité au chemin /admin. Aucun cookie de suivi ou publicitaire d'aucune sorte.
Désactivé par défaut. Il ne se charge que si la personne qui gère un déploiement donné configure un ID de mesure dans son propre panneau d'administration - c'est son choix pour son instance, CPYNET lui-même ne charge jamais de traceur de sa propre initiative.
Le serveur n'a aucune dépendance Go externe (bibliothèque standard pure). La page web charge une police depuis Google Fonts - la seule requête réseau vers un tiers dans tout le produit. Aucun autre script, CDN ou traceur tiers.
CPYNET est fourni « tel quel », sans garantie d'aucune sorte. Vous l'utilisez à vos propres risques. Quiconque exploite une instance donnée (l'opérateur) n'est pas responsable des dommages, directs ou indirects, résultant de son utilisation - y compris la perte de données (les pastes sont éphémères par conception et ne peuvent pas être récupérés une fois expirés ou lus), les interruptions de service, ou tout ce qui est partagé via ce service.
Vous êtes seul responsable de ce que vous collez ou téléversez : sa légalité, son exactitude, et votre droit de le partager. Ne l'utilisez pas pour distribuer quoi que ce soit d'illégal, de contrefaisant ou de malveillant. Un opérateur peut supprimer l'accès, limiter le débit, ou bloquer une source à sa discrétion, bien que dans le cas normal le contenu ne soit tout simplement jamais inspecté (voir ci-dessus) - les abus sont généralement détectés par les limites automatiques ci-dessous, pas par une revue manuelle.
Pour empêcher qu'un acteur malveillant (ou une rafale de bots automatisés) ne fasse tomber une instance pour tout le monde : les écritures et lectures sont limitées en débit par IP, le stockage total en mémoire de tous les pastes actifs a un plafond fixe (les écritures supplémentaires reçoivent un 503 une fois plein, plutôt que le processus ne manque de mémoire), et les téléversements de fichiers ont spécifiquement une durée de vie maximale plus courte que le texte brut (voir la référence de l'API pour les limites actuelles). Rien de tout cela ne nécessite de compte ni n'identifie qui utilise le service dans le cas normal - cela n'intervient que sous charge réelle.
La conception de CPYNET penche par défaut vers la minimisation des données : le contenu des pastes n'est jamais persisté, les journaux de requêtes ne conservent que l'IP, la méthode, le chemin, le code de statut et la durée (aucun nom, e-mail ou compte lié à une requête), et les seuls cookies sont fonctionnels (langue, session admin) - aucun d'eux ne nécessite de bandeau de consentement au titre du RGPD ou de la KVKK turque. Cela dit, CPYNET lui-même n'est pas un responsable de traitement ; quiconque exploite un déploiement donné (auto-hébergé ou non) est responsable de ses propres obligations de conformité - y compris l'emplacement de son serveur et toute journalisation supplémentaire ajoutée par-dessus, comme les propres journaux d'accès d'un reverse proxy.
Il s'agit d'un petit service en un seul fichier - si quelque chose n'est pas clair ici, le comportement décrit ci-dessus est directement vérifiable : regardez ce que renvoie une seconde lecture du même code, examinez les en-têtes de réponse, ou ouvrez l'onglet réseau de votre navigateur avant d'envoyer quoi que ce soit.