AccueilTechniqueServices → Nitter

    Nitter

    Fonctionnement🔗

    Le service Nitter est un front-end alternatif à Twitter : il permet de consulter Twitter sans pistage ni publicité. Notre instance agit comme intermédiaire entre les utilisateur·ices et Twitter, les protégeant ainsi du pistage. Il s’utilise via navigateur, et offre également la possibilité de récupérer des flux RSS de comptes Twitter.

    Par design, il fonctionne donc de manière entièrement dépendante de Twitter et peut cesser de fonctionner au moindre changement en amont.

    Historique🔗

    Notre service Nitter a été ouvert le 12 septembre 2019, à l’époque où Nitter était encore en cours de développement actif. Il s’agit de la deuxième instance historique de Nitter encore en fonctionnement, derrière l’instance principale.

    Nous avons pris la décision difficile de fermer notre service Nitter en octobre 2023 suite à de nombreux blocages de Twitter mis en place après le rachat de l’entreprise, et une surutilisation de notre service par des robots d’indexation / IA, qui nous donnaient beaucoup trop de travail de maintenance sur ce service.

    Installation🔗

    Nous utilisons l’image Docker officielle de Nitter, zedeus/nitter. Nous modifions légèrement cette image pour y copier notre fichier de configuration. Le dossier correspondant à ce service dans notre dépôt Core se situe ici.

    La mise en place de Nitter nécessite une instance Redis qui sert de cache (il semblerait que seules les URLs soient cachées). Cette instance de Redis est installée dans un autre conteneur sur le même sous-réseau, dont le dossier de configuration est disponible ici.

    Tests🔗

    Nitter dépend entièrement de Twitter, il arrive donc qu’il soit momentanément indisponible pour les causes suivantes :

    • Rate limit atteint : il suffit généralement de redémarrer l’instance pour résoudre ce problème ;
    • Trafic entrant trop important : lorsque le service subit une vague de spam, il arrive que notre instance sature complètement ;
    • Changements d’API et de contenu sur Twitter : une mise à jour de Nitter règle généralement le problème. Un tour dans le canal Matrix de Nitter peut également aider à savoir s’il s’agit d’une situation individuelle ou collective.

    Pour tester le logiciel, il suffit de s’y rendre dans son navigateur et de chercher un profil Twitter (ex.: celui de La Contre-Voie). Si la page s’affiche correctement, le service est opérationnel. Si plusieurs instances font fonctionner le service à l’aide d’un système de répartition de charge, il est nécessaire de tester chaque instance.

    Statistiques d’utilisation🔗

    Voici les statistiques d’utilisation du service Nitter de La Contre-Voie.

    Il s’agit de moyennes journalières mesurées pendant la 5e semaine (calendrier ISO) de chaque année listée.

    AnnéeRequêtesUtilisateur·ice·s uniquesBande passante
    202015 9543030,81 GB
    2021682 2995 16629,54 GB
    20221 880 81510 02970,92 GB
    20238 281 97839 982363,17 GB

    En date de février 2023, il s’agit du service le plus utilisé de La Contre-Voie (et de très loin). Cette forte activité s’explique par le fait que notre instance Nitter est la plus ancienne encore en fonctionnement derrière l’instance principale. Nous recevons donc beaucoup de trafic de l’international.

    En production, en date de février 2023, nos deux instances redondées de Nitter consomment chacune environ 600 MB de RAM. Son conteneur Redis consomme en moyenne 200 MB de RAM, bien que ces chiffres restent très variables.

    Précautions🔗

    Nitter subit régulièrement des vagues de crawlers qui cherchent à indexer les données de Twitter. Ce crawling peut avoir de sérieux impacts sur la disponibilité et la rapidité du service. Quelques conseils pour éviter les ralentissements et dénis de service :

    • Ajustez votre fichier robots.txt pour demander aux bots de ne pas indexer votre site web.
    • Utiliser des outils comme fail2ban pour limiter le nombre de requêtes. Cette limite doit être vraiment large afin de prévoir les nombreux cas d’utilisation qu’il ne serait pas judicieux d’interdire.
      • Par exemple, limiter le nombre de requêtes vers des flux RSS à 1000 requêtes par heure.
      • Ou encore, limiter le nombre de requêtes vers des images par heure, à un nombre particulièrement élevé (plus de 5000 ?) pour permettre l’utilisation de l’instance malgré tout.
    • Appliquer une limitation sur le nombre de requêtes par seconde selon les routes via le reverse-proxy. Il faut que le service puisse toujours être utilisable sans problème malgré cette limite.
    • Surveiller régulièrement les journaux du reverse-proxy.
      • Un tail -f nitter.log peut vous aider à voir si votre service n’est pas en train de crouler sous les requêtes.
      • tail -n 400000 nitter.log | cut -d " " -f1 | sort | uniq -c | sort -nr | less vous permet d’identifier les IPs les plus actives dans les 400 000 dernières requêtes. S’il y en a quelques-unes qui dépassent largement les autres, vous subissez peut-être une attaque ou une tentative d’indexation.
    • Préparez-vous à stocker des journaux d’accès d’une taille conséquente (si vous en stockez). À La Contre-Voie, en date de février 2023, un fichier qui journalise les connexions sur une semaine pèse 16 Go sans compression.
    • Le fonctionnement de ce service dépend entièrement d’un service tiers (Twitter), il est donc susceptible d’être en panne plus souvent à cause de rate limits ou d’autres facteurs (problèmes de connexion, pannes sur Twitter…). Un monitoring externe rigoureux est donc recommandé.
    • Un monitoring interne s’avère nécessaire pour ce service qui peut subitement consommer beaucoup de RAM.
      • Les journaux internes du conteneur peuvent également servir d’indicateurs pertinents.
    • Déployer un système de répartition de charge avec plusieurs instances Nitter peut aider à supporter un trafic important et assurer le fonctionnement du service même lorsque l’une des instances est en panne.

    Autre précaution importante : vous pourriez recevoir des demandes de retrait de contenu pour des raisons légales. Ces demandes peuvent conduire à la suspension de votre serveur et à des poursuites judiciaires si vous ne les traitez pas convenablement. Voir la section dédiée.

    Entretien🔗

    Pour les raisons évoquées ci-dessus, ce service nécessite une supervision rigoureuse afin d’assurer la qualité de service.

    Plantages réguliers🔗

    La plupart des plantages de Nitter peuvent être résolus en redémarrant le conteneur. Assurez-vous que votre instance (ou vos instances) Nitter sont à jour.

    Attention à ne pas redémarrer votre instance trop régulièrement : votre instance récupère des tokens au démarrage qui lui sont nécessaires pour fonctionner, et Twitter semble appliquer un rate limit sur la demande de tokens. Demander trop de tokens d’un coup peut vous faire atteindre le rate limit de Twitter, causant une indisponibilité de 30 minutes minimum.

    Traitement des demandes de retrait🔗

    Selon le trafic que votre instance va recevoir, il est possible que vous ayez régulièrement à faire face à des demandes de retrait, au nom du respect des données personnelles des personnes concernées, de contenu illégal (présent sur Twitter, qui se retrouve donc sur votre instance) ou des lois copyright (DMCA ou autre).

    Argumentation juridique🔗

    Nous vous partageons ici notre analyse juridique « de comptoir » (car la seule analyse juridique qui a une valeur est celle d’un·e juge, or il n’y a pas encore eu de jurisprudence à ce sujet).

    Votre responsabilité juridique peut être engagée pour les contenus affichés sur Nitter si vous considérez que la loi applicable à l’hébergement de ce service est la LCEN (loi pour la confiance dans l’économie numérique).

    Cela dit, vous pouvez également considérer que l’hébergement de Nitter relève du CPCE (code des postes et des communications électroniques : en effet, votre instance agit seulement comme intermédiaire de transmission entre Twitter et l’utilisateur·ice, de la même manière qu’un FAI (à quelques détails techniques près, certes).

    Si vous considérez que l’hébergement de votre instance Nitter relève du CPCE, alors votre responsabilité juridique ne peut théoriquement pas être engagée en vertu de l’article L32-3-3. C’est la position que nous avons choisie avec l’instance Nitter de La Contre-Voie. En pratique, seul·e un·e juge peut confirmer cette interprétation de la loi.

    Une page sur le wiki de Nitter propose des modèles de réponse pour répondre aux demandes DMCA.

    Voici celle que nous utilisons, une sorte de compilation juridique qui présente les différents boucliers légaux à notre disposition :

    Hello,
    
    I am writing on behalf of ORGANIZATION_NAME. I am the webmaster of ORGANIZATION_WEBSITE and all of its subdomains.
    
    I see you are filing a claim for NITTER_INSTANCE_ADDRESS. NITTER_INSTANCE_ADDRESS hosts Nitter, a private Twitter front-end, meaning it is simply a proxy to access Twitter assets and user generated content without tracking from Twitter. Thus, all content is proxied from Twitter and is not stored on our servers and if Twitter chooses to remove an asset, it will no longer appear on our site.
    
    Our hosting provider HOSTING_COMPANY is hosted in France, so French laws apply. Under the Code des postes et des communications électroniques (CPCE) of 10 July 2004, article L32-3-3, all entities providing content transmission cannot be liable of the transmitted content.
    
    Under the directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonization of certain aspects of copyright and related rights in the information society, "temporary acts of reproduction referred to in Article 2, which are transient or incidental [and] an integral and essential part of a technological process and whose sole purpose is to enable: a transmission in a network between third parties by an intermediary" is allowed, and legal.
    
    Under the United States law, following the copyright law 17 U.S.C. § 512(a), part of the Digital Millennium Copyright Act, we cannot be liable for content that "is transmitted through the system or network without modification of its content."
    
    Thank you,
    
    NAME
    ORGANIZATION_NAME − ORGANIZATION_WEBSITE
    

    Cette réponse, promptement envoyée, dissuade les personnes qui nous ont contacté d’engager des poursuites judiciaires (jusqu’à présent).

    Interruption de service🔗

    Dans la catégorie « scénario catastrophe » : selon la rigueur de vos hébergeurs et des personnes qui effectuent les signalements, il peut arriver que votre serveur soit suspendu sans préavis. C’est la situation dans laquelle s’est retrouvée TheFrenchGhosty, administrateur de PussTheCat.org. Il hébergeait alors l’une des instances Nitter les plus utilisées. Son retour d’expérience est disponible sur son site web.

    Pour mitiger ce genre de situation, disposer d’un serveur virtuel dédié à Nitter peut être utile pour éviter qu’une telle manœuvre impacte vos autres services. Cela semble toutefois représenter un risque assez faible si votre instance n’est pas fortement utilisée.

    Mise à jour🔗

    La mise à jour de Nitter se réalise simplement en téléchargeant l’image Docker officielle de Nitter, zedeus/nitter. Il est nécessaire de reconstruire l’image pour y ajouter le fichier de configuration de Nitter.

    Il peut être nécessaire de surveiller les commits sur le fichier de configuration d’exemple pour éviter de passer à côté de paramètres qui pourraient changer.

    Pour la maintenance du cache Redis, voir la page dédiée.

    Évolutions envisagées🔗

    Thème🔗

    Nitter supporte l’ajout et l’utilisation de thèmes, mais nous utilisons toujours le thème par défaut. Il pourrait être envisagé d’uniformiser le thème de Nitter avec le thème graphique de La Contre-Voie, ce qui permettrait notamment à des personnes qui nous connaissent depuis notre service Nitter de découvrir nos autres services.