GitHub CLI agora coleta telemetria pseudonimizada

• A telemetria pseudonimizada é enviada pelo GitHub CLI com o objetivo de dar visibilidade ao uso de recursos e apoiar melhorias no produto
• Adoção de subcommands e padrões de uso de flags são usados para definir prioridades de trabalho, avaliar se as necessidades dos usuários estão sendo atendidas e revisar discoverability e design
• Com a implementação open source, é possível revisar diretamente o código de telemetria no repositório cli/cli, e no modo de logging verificar o payload JSON antes do envio real
• O opt-out pode ser feito com a variável de ambiente GH_TELEMETRY=false, DO_NOT_TRACK=true ou gh config set telemetry disabled, e as variáveis de ambiente têm prioridade sobre a config
• Os eventos de telemetria são enviados para a infraestrutura interna de análise do GitHub, e esta página trata apenas da coleta de dados no lado do cliente do gh; extensions e Copilot CLI são tratados separadamente

---

Telemetria

• O GitHub CLI envia telemetria pseudonimizada com o objetivo de apoiar melhorias no produto
• As informações são fornecidas para que os usuários entendam quais dados são enviados e por quê

Por que a telemetria é coletada

• É mencionada a necessidade de obter visibilidade sobre o uso dos recursos do GitHub CLI, especialmente com o aumento da adoção agentic, para entender como ele é realmente usado
  • A equipe usa esses dados para definir prioridades de trabalho
  • Avaliar se os recursos estão de fato atendendo às necessidades dos usuários
• Também é declarado o objetivo de verificar a adoção após o lançamento de novos subcommands
  • Se quase ninguém usar, pode ser necessário revisar a discoverability ou o design desse recurso
  • Se for identificado alto uso com determinadas flags, isso ajuda a encontrar onde investir em uma experiência melhor

Revisão da telemetria

• Como o GitHub CLI é open source, é possível revisar diretamente a implementação de telemetria no repositório cli/cli
• Para verificar quais dados seriam enviados sem realmente enviá-los, é possível usar o modo de logging
  • Há suporte via variável de ambiente
    • export GH_TELEMETRY=log
  • Há suporte via configuração da CLI
    • gh config set telemetry log
• No modo de logging, o payload JSON que normalmente seria enviado é exibido no stderr
  • É possível inspecionar cada campo antes de decidir se deseja manter a telemetria ativada
  • É apresentado como comando de exemplo GH_TELEMETRY=log gh repo list --archived
• São especificadas as informações de evento incluídas no payload de exemplo
  • Tipo de evento command_invocation
  • Como itens de dimensions, inclui agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
  • Como valores de exemplo, são mostrados architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0
• Esse comando só pode registrar a telemetria referente ao comando exato executado e ao contexto
  • Se as variáveis de ambiente mudarem, os events e event dimensions incluídos no payload também podem mudar
  • Os itens incluídos também podem mudar se a conta autenticada for alterada

Como fazer opt-out

• É possível fazer opt-out da telemetria verificada no modo de logging
• Há suporte via variável de ambiente
  • export GH_TELEMETRY=false
  • Valores falsy como 0, false, disabled e string vazia podem ser usados
  • A convenção DO_NOT_TRACK também é suportada, com o exemplo export DO_NOT_TRACK=true
• Há suporte via configuração da CLI
  • gh config set telemetry disabled
• As variáveis de ambiente têm prioridade sobre o valor de config

Para onde os dados são enviados

• Os eventos de telemetria são enviados para a infraestrutura interna de análise do GitHub
• Para mais informações sobre como os dados são processados, é indicado consultar a GitHub General Privacy Statement

Informações adicionais

• O GitHub CLI oferece suporte à adição de recursos por meio da instalação de extensions do GitHub e de terceiros, incluindo agents
• Essas extensions podem coletar seus próprios dados de uso
  • Isso não é controlado pela configuração de opt-out
  • É necessário verificar a documentação de cada extension para saber como ela reporta telemetria e se é possível desativá-la
• Esta página trata apenas da coleta de dados no lado do cliente do GitHub CLI gh
  • Não se aplica ao GitHub Copilot nem ao Copilot CLI
  • O Copilot CLI lida com a coleta de dados separadamente
  • São indicados Using GitHub Copilot CLI e Responsible Use of the GitHub Copilot CLI como locais com informações relacionadas

[GN⁺]

Comentários do Hacker News

• Fico me perguntando por que equipes corporativas de desenvolvimento sempre querem observar os usuários com telemetria
  Dá vontade de perguntar se boa engenharia e bom design por si só não bastam
  O Git funcionou bem por mais de 20 anos sem análises detalhadas de quem usa quais recursos e comandos, então fica a dúvida se a telemetria realmente o teria tornado melhor ou se só teria aumentado a quantidade de dados que distraem

  • Antes eu também achava desnecessário, mas depois de criar uma startup mudei de ideia
    Sem analytics, é como dirigir vendado
    Não dá para saber o que os usuários realmente valorizam nem quais fluxos precisam ser otimizados, e a diferença entre o que as pessoas dizem e a forma como de fato usam o software é surpreendentemente grande
  • Como desenvolvedores e usuários têm necessidades e pensamentos diferentes, considero que bom design sozinho não basta
    Em muitos casos também é difícil conseguir bom feedback das pessoas, e mesmo que todo mundo diga gostar da ideia do recurso X, na prática talvez ninguém o use
    Também pode parecer que existe uma base de fãs muito barulhenta, sem que isso se converta em receita ou uso real
    Acho bem provável que o Git tivesse melhorado se tivesse tido telemetria
    O Git é famoso por ter uma UI ruim
    Os dados teriam mostrado logo no começo o quanto as pessoas se perdiam e, por exemplo, melhorias como git restore teriam chegado muito antes em vez de comandos pouco intuitivos como git checkout -- foo.txt
  • Infelizmente, acho que esse fenômeno acontece porque há muitos tomadores de decisão não técnicos
    Como pessoas que não usam a ferramenta diretamente não entendem como ela é usada na prática, o PM responsável por ferramentas de desenvolvimento acaba pedindo esse tipo de dado para conseguir fazer o próprio trabalho
    Parece uma estrutura parecida com a de PMs de e-commerce enchendo o frontend de scripts de rastreamento
    Engenheiros sozinhos já conseguiam projetar a interação com o usuário, mas depois da era do VC se consolidou o paradigma de produtos técnicos sendo liderados profundamente por pessoas não técnicas, e isso parece problemático
    No fim, os dados vão para as mãos delas, e alguém acaba justificando o salário do PM
  • Não acho que dê para afirmar com certeza que ter telemetria no Git não teria ajudado
    Para mim isso não é claro
  • Acho que o Git é péssimo em design e usabilidade
    Parece um caso clássico de engenheiros criando interfaces para engenheiros, sem um bom ciclo de feedback
    Ironicamente, esse próprio exemplo mostra que desenvolvedores precisam entender melhor como seus produtos são realmente usados
    O cenário de uso na cabeça do desenvolvedor costuma ser bem diferente da realidade

• Acho que a questão do opt-out no CLI gh é mais complexa do que parece
  O gh também roda em pipelines de CI/CD e em ambientes de servidor, e nesses ambientes talvez não se queira nenhuma conexão de saída para github.com, não por privacidade, mas por restrições de rede
  Em lugares assim, se a telemetria vier ativada por padrão, o CI pode falhar ou o bastion host pode simplesmente não conseguir alcançar o GitHub
  Já o próprio Git funciona totalmente de forma local até o usuário fazer um push explicitamente
  É um modelo de confiança diferente
  O Git nunca phone home se você não configurar isso, enquanto o gh é um wrapper da API do GitHub, então é compreensível que chamadas sejam necessárias por funcionalidade
  Mas, independentemente disso, acho que vale discutir separadamente se também é preciso coletar e enviar padrões de uso dos comandos

  • Não acho que o programa vá morrer com erro fatal só porque não conseguiu enviar telemetria
  • Fico curioso se o gh fica praticamente inútil sem conseguir se conectar ao GitHub.com
    Ou se a principal situação de uso seria conexão com GitHub Enterprise

• Se três desenvolvedores estão gastando 80% do tempo em alguma área da codebase, mas na prática quase ninguém a usa e não parece realista que isso cresça no futuro, talvez faça mais sentido realocar esse pessoal ou repensar o recurso como um todo
  O problema desse tipo de analytics, porém, é que parte do entendimento de que, mesmo sendo usado de forma inofensiva, ainda dá para reconstruir identidades com aprendizado de máquina ligando identificadores únicos a padrões de comportamento
  Com timestamps, isso fica ainda mais grave
  Por isso, acho que seria bom deixar exatamente claro quando e qual telemetria é enviada
  Por exemplo, poderia existir uma opção de modo verboso que mostrasse o que seria enviado sem de fato transmitir nada, e então o usuário decidiria se quer ativar
  Acho que o modelo certo é como o Steam Hardware Survey, que mostra o que será enviado

• Todos os comandos do gh no fim são só wrappers da API do GitHub, e sinto que isso deixa essa discussão ainda mais confusa

• Gosto de PRs curtos assim
  https://github.com/cli/cli/pull/13254
  O conteúdo também é simples, então entendo que isso remove a env var que bloqueava a telemetria e a transforma em ativada por padrão

  • Parece não ser apenas ativada por padrão, mas até mesmo impossível de desativar
    Tirando enterprise, a estrutura parece praticamente forçar isso

• Fiquei muito satisfeito por ter implantado gitea no homelab no mês passado
  Tem função de importar do GitHub e, sinceramente, me parece mais rápido e com uptime melhor do que o GitHub
  O Claude também se integra bem com tea CLI e Git, e é quase como uma cópia do GitHub, mas até agora me parece até melhor

  • Eu uso Forgejo, e como compartilha o mesmo código-base principal, também acho excelente
    É rápido e tem bom uptime
    Inclusive roda em um Pi 4 no armário ao lado da minha mesa, então continua funcionando mesmo se a internet cair
    Mando backup off-site com borg e syncthing
    Dá um pouco de trabalho para configurar, mas depois disso o tempo de manutenção fica praticamente perto de zero
    Mais ou menos uma vez a cada duas semanas eu só entro por SSH para conferir espaço no SSD, uso de RAM, apt update, upgrade e upgrades de versão principal

• Fico pensando se as pessoas não presumem que o GitHub já coleta e agrega todas as requisições que chegam aos próprios servidores
  Afinal, a razão de existir do CLI gh é justamente interagir com esses servidores
  Se a pessoa realmente não quer rastreamento de requisições, provavelmente teria que fazer opt-out de muito mais coisa do que só essa configuração

  • Como os dados já estão no servidor, acho natural supor que eles já estejam olhando para isso
    Mas agora parece que querem acrescentar métricas do lado do cliente para rastrear melhor não só o que vai para o GitHub, mas também fluxos que vão para outros lugares como GitLab e Codeberg

• Do ponto de vista do GitHub, isso pode ser bom
  Toda empresa precisa desse tipo de dado, algumas usam para melhorar o produto e outras para fins menos nobres
  Sei que usuários do HN odeiam telemetria, mas se você já construiu um SaaS, acaba percebendo que telemetry é praticamente indispensável

  • Acho que o GitHub CLI não é um SaaS, e sim um utilitário de linha de comando
  • Eu preferiria que primeiro perguntassem diretamente ao usuário
    No fundo, a crítica é à falta de diálogo
  • Fico curioso sobre qual seria a melhor prática para verificar o conteúdo da telemetria de uma ferramenta
    O ponto central está nos detalhes, e estou pensando se existe algum tipo de serviço intermediário confiável que consiga criar um meio-termo aceitável para usuários e fabricantes do produto
    Digo que estou organizando em um Gist o que pesquisei com ajuda do Claude
  • Acho que o jeito de falar dos defensores de IA soa sempre muito parecido

• Isso me lembra o Embrace, extend, extinguish da Microsoft
  As duas primeiras etapas já aconteceram, e eu prevejo que, em cinco anos, o GH CLI será a única forma de interagir com repositórios do GitHub
  Aí a terceira etapa estará concluída e o ciclo terá terminado

  • Eu toparia apostar contra essa previsão
    Dá até vontade de perguntar quanto você quer apostar, de tão irrealista que isso parece
  • Esse tipo de afirmação realmente cansa
    As pessoas continuaram encaixando EEE em WSL, suporte a GPU, WSLg e PowerShell, mas isso nunca aconteceu
    Continua não acontecendo agora, e nem sequer há muito sinal de que esteja planejado
    Não é algo para interpretar no feeling; a posição aqui é pedir evidências de onde exatamente o truque repetível que a Microsoft realmente usava nos anos 90 está sendo reproduzido agora
    Não existe um Microsoft Git bloqueando com mais recursos do que o open source, e o mesmo vale para algo como Microsoft Linux
    O GitHub é um wrapper sobre Git e tem como projeto central ser um servidor Git rodando sobre HTTP e SSH
    Quebrar essa base e travar o acesso aos repositórios só pelo gh seria uma mudança grande demais, então isso parece pouco realista
    O gh é só uma ferramenta para facilitar chamadas de API, e a maioria dos usuários do GitHub mal sabe que ele existe
    O que tem mais chance de arruinar o GitHub não é um EEE malicioso, e sim gestão incompetente
    Parece mais provável que ele desande por causa de executivos que não entendem os usuários nem o produto
  • Eu não descarto totalmente essa previsão
    Já existem repositórios que parecem mais incômodos de lidar sem gh, e acho que alguns fluxos forçados estão surgindo aos poucos
    Não sei exatamente o que o gh entrega a mais porque nunca usei, mas para mim os comandos padrão do Git já bastam

• Fico confuso se pseudonymous telemetry aqui quer dizer telemetria pseudônima ou se na prática quer dizer uma telemetria que não é anônima
  As duas expressões têm sentidos quase opostos e, com a redação atual, parece que estão dizendo que coletam dados identificáveis

  • Nessa página aparece apenas a expressão pseudonymous, e pseudoanonymous parece ser um termo inventado por quem escreveu o post no HN
  • Entendo que isso significa que não fica vinculado à identidade da pessoa nem à conta do GitHub, mas ainda dá para ver toda a telemetria vinda de uma mesma máquina em conjunto
    Parece uma estrutura em que cada máquina recebe um UUID e passa a ser identificada com base nisso