Le langage de programmation Go de Google veut activer la télémétrie par défaut,provoquant la colère des développeurs
Russ Cox, un ingénieur logiciel de Google qui dirige le développement du langage de programmation open source Go, a présenté un plan possible pour implémenter la télémétrie dans la chaîne d'outils Go. Cependant, de nombreux membres de la communauté Go s'objectent car le plan appelle la télémétrie par défaut.
Ces développeurs alarmés préféreraient un régime opt-in plutôt qu'un régime opt-out, une position que l'équipe Go rejette car cela garantirait une faible adoption et réduirait la quantité de données de télémétrie reçues au point qu'elles seraient de peu de valeur.
Google est à nouveau au centre d'une controverse concernant la vie privée, avec une proposition d'ajouter la télémétrie au langage de programmation Go.
Go est un langage de programmation développé chez Google. Bien que similaire au langage C, il apporte un certain nombre d'ajouts importants et modernes. Russ Cox est l'ingénieur de Google qui dirige actuellement le développement de Go, et il a présenté une proposition controversée, qui impliquerait d'activer la télémétrie dans Go par défaut.
Cox a révélé la proposition sur GitHub.
La télémétrie, comme le décrit Cox, implique qu'un logiciel envoie des données du logiciel Go à un serveur pour fournir des informations sur les fonctions utilisées et sur les performances du logiciel. Il soutient qu'il est avantageux pour les projets open source de disposer de ces informations pour guider le développement.
Envoyé par Russ Cox
Comment les développeurs de logiciels comprennent-ils quelles parties de leur logiciel sont utilisées et s'ils fonctionnent comme prévu*? La réponse moderne est la télémétrie, ce qui signifie qu'un logiciel envoie des données pour répondre à ces questions à un serveur de collecte.
Je pense que les projets de logiciels open source doivent explorer de nouvelles conceptions de télémétrie qui aident les développeurs à obtenir les informations dont ils ont besoin pour travailler de manière efficace et efficiente, sans collecter de traces invasives de l'activité détaillée des utilisateurs.
J'ai écrit une courte série d'articles de blog sur une telle conception, que j'appelle la télémétrie transparente, car elle collecte le moins possible (kilooctets par an à partir de chaque installation) et publie ensuite chaque élément qu'elle collecte, pour inspection et analyse publiques.
J'aimerais explorer l'utilisation de la télémétrie transparente, ou d'un système similaire, dans la chaîne d'outils Go, qui, je l'espère, aidera les développeurs de projets Go et les utilisateurs. Pour être clair, je suggère seulement que l'instrumentation soit ajoutée aux outils de ligne de commande Go écrits et distribués par l'équipe Go, tels que la commande go, le compilateur Go, gopls et govulncheck. Je ne suggère pas que l'instrumentation soit ajoutée par le compilateur Go à tous les programmes Go dans le monde : c'est clairement inapproprié.
La télémétrie transparente possède les propriétés clés suivantes*:
- Les décisions concernant les mesures à collecter sont prises dans le cadre d'un processus public ouvert.
- La configuration de la collecte est automatiquement générée à partir des métriques activement suivies*: aucune donnée n'est collectée qui n'est pas nécessaire pour les métriques.
- La configuration de collecte est servie à l'aide d'un journal transparent inviolable, ce qui rend très difficile la fourniture de différentes configurations de collecte à différents systèmes.
- La configuration de la collecte est un module Go mis en cache et proxy, de sorte que tout proxy Go local améliorant la confidentialité déjà utilisé pour les modules ordinaires sera automatiquement utilisé pour la configuration de la collecte. Pour atténuer davantage les inquiétudes concernant les systèmes de suivi par le téléchargement de la configuration de collecte, chaque installation ne se soucie que de télécharger la configuration chaque semaine avec une probabilité de 10*%, de sorte que chaque installation ne demande la configuration qu'environ cinq fois par an.
- Les rapports téléchargés n'incluent que le nombre total d'événements sur une semaine complète, pas n'importe quel type de suivi d'événements classés dans le temps.
- Les rapports téléchargés n'incluent pas les ID utilisateur, les ID machine ou tout autre type d'ID.
- Les rapports téléchargés contiennent uniquement des chaînes déjà connues du serveur de collecte*: noms de compteur, noms de programme et chaînes de version répétées à partir de la configuration de collecte, ainsi que les noms des fonctions dans des programmes de chaîne d'outils Go spécifiques et non modifiés pour les traces de pile. Les seuls types de données autres que des chaînes dans les rapports sont le nombre d'événements, les dates et les numéros de ligne.
- Les adresses IP exposées par la session HTTP qui télécharge le rapport ne sont pas enregistrées avec les rapports.
- Grâce à l'échantillonnage, seul un nombre constant de rapports téléchargés est nécessaire pour atteindre un objectif de précision spécifique, quel que soit le nombre d'installations existantes. Plus précisément, seuls 16 000 rapports environ sont nécessaires pour une précision de 1 % à un niveau de confiance de 99 %. Cela signifie qu'à mesure que de nouveaux systèmes sont ajoutés au système, chaque système signale moins souvent. Avec une estimation prudente de deux millions d'installations Go, environ 16 000 rapports chaque semaine correspondent à un taux de rapport global bien inférieur à 2 % par semaine, ce qui signifie que chaque installation téléchargerait un rapport en moyenne moins d'une fois par an.
- Les métriques calculées agrégées sont rendues publiques sous forme graphique et tabulaire.
- Les données brutes complètes collectées sont rendues publiques, de sorte que les responsables du projet n'ont aucun avantage ou aperçu exclusif dans leur rôle de collecteur direct de données.
- Le système est activé par défaut, mais la désactivation est simple, efficace et persistante.
Bien que l'idée derrière la proposition ne soit peut-être pas mauvaise, l'idée actuelle prévue peut effrayer les développeurs, actuels ou potentiels, du langage de programmation Go dans tout projet futur. Il faut rappeler que la plupart des développeurs et utilisateurs open source sont notoirement opposés à la plupart des formes de télémétrie.
Russ vise à introduire un concept de « télémétrie transparente » pour aider les projets open source à mieux comprendre le logiciel, en gardant à l'esprit la confidentialité. Dans ses billets de blog (une série de 3 articles), il mentionne que les sondages et les rapports de bogues sont insuffisants. Il est donc nécessaire d'introduire le moyen le plus simple de collecter des données sur l'utilisation d'une application (c'est-à-dire la télémétrie) tout en gardant les choses ouvertes à tous.
Cela signifie que l'ensemble du processus de collecte des données, de la manière dont elles sont traitées et de ce qui en résulte, est ouvert à tous.
Pas mal, n'est-ce pas ?
Alors, quel est le problème*? Pourquoi la discussion est-elle verrouillée au moment de la publication ?
Eh bien, la proposition actuelle prévoit d'ajouter la télémétrie avec une option de désactivation. En d'autres termes, la télémétrie est activée par défaut à moins que quelqu'un ne la désactive explicitement.
D'où certaines réactions.
« Cela devrait être désactivé par défaut », a écrit l'utilisateur Stolas. «*Il n'y a aucune raison pour qu'une chaîne de développement ait un type de télémétrie activé par défaut. Ou, comme je comprends la nécessité qu'il soit activé par défaut, il devrait vérifier ce que l'utilisateur veut au premier démarrage ».
« Je pense que proposer un opt-in est une meilleure solution que d'aller sur un opt-out », a ajouté l'utilisateur w3bb. « Les personnes qui refuseraient la télémétrie à une invite sont des personnes qui ne veulent pas de la télémétrie, rendre la vie de ces personnes plus difficile est vraiment mauvais, que ce soit intentionnel ou non ».
Outre l'aversion naturelle de la communauté open source pour la télémétrie, le fait que ce soit Google derrière cette proposition s'ajoute à l'angoisse. Google, malheureusement, a une longue histoire de non-respect de la vie privée des utilisateurs. Même si la télémétrie dont il est question est en grande partie des mesures de performance sur le langage de programmation lui-même, de nombreux utilisateurs n'étaient pas à l'aise avec le fait que Google ait encore plus d'informations à leur sujet ou sur les outils qu'ils utilisent.
« Personnellement, je n'aime pas l'idée d'une collecte automatique de télémétrie qui m'est imposée », a écrit Szymon Ulewicz. «*Google n'a-t-il pas déjà suffisamment d'informations sur moi*?*»
Certains utilisateurs ont également souligné la longue histoire de Google qui a ignoré d'autres intérêts dans la poursuite des siens.
« Google a une histoire de décisions unilatérales qui ont des conséquences imprévues », écrit khm. « Considérez ce document : https://support.google.com/maps/answ.../1725632?hl=en La position de Google est simple. Si vous ne souhaitez pas que nous géolocalisions votre hôte Wi-Fi, reconfigurez le nom de votre réseau en "_nomap". Les souhaits du propriétaire du réseau, les réglementations locales et la conformité de l'entreprise ne sont pas pertinents pour Google*; changez votre SSID ou nous collecterons vos données ».
Le comportement passé de Google consistant à imposer sa volonté à d'autres personnes et à leur laisser le soin de s'adapter a laissé à certains développeurs le sentiment qu'ils n'avaient pas grand-chose à dire sur la question, malgré le fait que Cox demandait des commentaires.
« Je ne veux pas trop lire dans l'intention, mais j'ai la nette impression que la décision de livrer une version avec la télémétrie activée a déjà été prise et qu'on nous demande de l'approuver automatiquement », a écrit Louis Thibault. « J'espère sincèrement que ce n'est pas le cas ».
Le consultant informatique Jacob Weisz précise que Go ne peut pas échapper à son association avec Google, pas plus que Java ne peut être séparé d'Oracle ou Swift d'Apple. Il a écrit dans une réponse à la proposition sur GitHub qu'il avait résisté à Go pendant des années en raison de son association avec Google et n'a commencé à travailler avec lui que récemment parce que des amis l'ont convaincu qu'il n'était pas si étroitement associé à l'entreprise.
«*Maintenant, vous voulez introduire la télémétrie dans votre langage de programmation*?*» regrette Weisz. « C'est ainsi que vous chassez toute personne qui a même envisagé de donner une chance à votre projet malgré les signes avant-coureurs. S'il vous plaît, ne faites pas cela, et s'il vous plaît, présentez des excuses publiques ne serait-ce...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.