Depuis la version 2.91.0 du CLI GitHub publiée mardi, chaque commande que vous tapez dans gh envoie des données de télémétrie vers GitHub par défaut. L'activation est silencieuse, sans message au premier lancement, sans consentement explicite, et il faut fouiller dans la doc pour tomber sur la page dédiée au sujet.

GitHub décrit la collecte comme pseudonyme côté client. Concrètement, le payload embarque le nom de la commande lancée, un identifiant d'invocation, un identifiant d'appareil, l'OS, l'architecture, l'agent et quelques drapeaux.

L'entreprise précise que le contenu exact peut varier d'un appel à l'autre. La justification officielle : les équipes produit ont besoin de voir comment le CLI est utilisé, avec la montée en puissance des agents IA qui le pilotent de plus en plus souvent en arrière-plan.

Côté sortie, il y a trois moyens de couper la télémétrie. Vous pouvez définir la variable d'environnement GH_TELEMETRY à false, ou DO_NOT_TRACK à true, ou lancer gh config set telemetry disabled. Simple en apparence.

Sauf que rien de tout ça n'est signalé à l'installation, et qu'un utilisateur qui n'est pas tombé sur le billet de Brandon Vigliarolo dans The Register ne saura probablement pas que c'est activé sur sa machine.

Le terme pseudonyme mérite aussi qu'on le regarde de près. Pseudonyme ne veut pas dire anonyme : il y a un identifiant d'appareil stable, il y a un identifiant d'invocation, et GitHub connaît déjà votre compte si vous êtes authentifié avec gh auth login.

Du coup, le recoupement entre votre activité CLI et votre identité GitHub n'a rien de théorique, même si GitHub ne promet pas de le faire.

En pratique, la télémétrie des outils de dev n'est pas une nouveauté. VS Code le fait depuis des années, npm aussi, et la plupart des éditeurs jouent le même jeu. Ce qui coince ici, c'est le choix de l'opt-out plutôt que de l'opt-in, et l'absence d'annonce claire sur le changelog principal.

Les utilisateurs reprochent surtout à GitHub d'avoir glissé l'info dans une page de doc au lieu d'un billet de blog dédié. Pour un outil qu'utilisent des gens très à cheval sur leur vie privée, c'est un drôle de calcul.

Bref, un outil CLI qui s'active en mode collecte par défaut sans prévenir, ça pique. Heureusement une variable d'environnement suffit à couper. Mais il faut savoir qu'elle existe.

Source : The Register

Vous avez un logiciel qui cause un peu trop avec Internet alors qu'il n'a rien à y faire ? Ou un petit utilitaire qui balance de la télémétrie dans votre dos sans vous demander votre avis ? Ou peut-être juste une application que vous voulez forcer en mode hors-ligne sans pour autant couper tout votre réseau ?

C'est LA situation classique où pour leur couper la chique, on finit par se battre avec les menus obscurs du pare-feu Windows. Sauf que maintenant, y'a un petit outil CLI qui fait exactement ça en une seconde : ProcNetBlocker .

C'est un utilitaire Windows en ligne de commande qui permet de bloquer l'accès réseau de n'importe quel processus comme ça pas besoin de créer des règles à rallonge. Vous tapez une commande, et hop, le processus est instantanément coupé du monde extérieur. C'est idéal pour blinder sa vie privée face au tracking incessant de certains éditeurs.

L'outil est super flexible puisqu'il propose deux approches. La première, c'est de cibler un processus par son PID (l'identifiant de processus). C'est parfait pour agir dans l'urgence sur un truc qui tourne déjà. La seconde, c'est de bloquer par le chemin de l'exécutable. Là, c'est plus radical puisque l'outil crée une règle persistante qui s'appliquera à chaque fois que vous lancerez cette application précise.

Le truc est portable (un petit ZIP de 7,5 Mo), et faut juste avoir les droits administrateur (logique, puisqu'on touche au pare-feu) et s'assurer que le service du pare-feu Windows est bien en cours d'exécution. Si vous utilisez déjà des solutions comme CrowdSec pour sécuriser vos serveurs, ProcNetBlocker sera un excellent complément pour vos postes de travail.

Une fois le ZIP récupéré sur le site d'AutoClose, voici les commandes magiques à connaître :

1. Bloquer un processus par son PID

Si vous connaissez l'ID du processus (via le gestionnaire des tâches ou un petit tasklist) :

procnetblocker.exe --block 1234

procnetblocker.exe --block "C:\Chemin\Vers\MonApp.exe" --exe

procnetblocker.exe --status "C:\Chemin\Vers\MonApp.exe" --exe

procnetblocker.exe --unblock 1234