Money Tree Browser que oferece recompensas por bugs do Chromium

Apresentação do Chromium Money Tree Browser

• O Chromium Money Tree Browser é um site que vincula as recompensas do Chrome VRP (programa de recompensa por bugs) às alterações (correções) em arquivos específicos.
• Este site foi feito de forma muito simples, e é melhor não esperar muito da experiência do usuário nem da precisão dos dados.
• As recompensas por bugs são divididas por arquivo; por exemplo, se um bug no valor de US$ 1000 foi corrigido com alterações em 5 arquivos, cada arquivo recebe US$ 200.
• Os dados têm como base informações até o início de novembro de 2023.

Opinião do GN⁺

• O Chromium Money Tree Browser é uma ferramenta interessante para desenvolvedores e pesquisadores de segurança, pois mostra visualmente quais arquivos foram corrigidos no programa de recompensa por bugs do Chrome e como a recompensa correspondente foi distribuída.
• O site oferece uma visão de como a recompensa por correções de bugs é calculada e pode ajudar a compartilhar informações úteis na comunidade de segurança.
• Embora seja preciso moderar as expectativas quanto à experiência do usuário e à precisão dos dados, o site pode contribuir para aumentar a conscientização sobre vulnerabilidades de segurança em projetos de código aberto e motivar desenvolvedores a dar mais importância à segurança.

[GN⁺]

Opinião do Hacker News

• Interesse em algo semelhante a uma funcionalidade que um desenvolvedor queria construir há muito tempo

  • Reflexão sobre a utilidade de um método para calcular a probabilidade de uma determinada mudança causar problemas com base em alterações ocorridas no passado em um arquivo ou em partes específicas dele.
  • Atribuir uma pontuação de risco a cada mudança e vinculá-la ao PR (Pull Request), para alertar os revisores de código sobre trechos que exigem atenção extra e usá-la como sinal para destacar mudanças arriscadas no momento do deploy.
  • É difícil rastrear a mesma parte do código quando ela se move para cima ou para baixo devido a inserções/remoções. Algoritmos baseados apenas em números de linha podem ser problemáticos.
  • Sugere que até mesmo um trabalho feito no nível de arquivo já pode ser útil o suficiente.

• Apontamento de que correções em determinadas bibliotecas de terceiros foram omitidas

  • Parece que algumas correções feitas em bibliotecas de terceiros, como o ffmpeg, ficaram de fora. Essas correções muitas vezes são tratadas primeiro a montante, o que dificulta seu rastreamento.

• Ao observar muitos bugs na UI do navegador Chrome, reflexão sobre problemas de use-after-free em dados cujo desempenho da gestão manual de memória não é importante

  • Observações sobre problemas de use-after-free que ocorrem em códigos como o ciclo de vida da caixa de diálogo de "seleção de arquivo", mesmo quando o desempenho da gestão manual de memória não é importante.
  • Sugere que, nesses casos, pode ser melhor sempre usar ponteiros mais inteligentes e mais lentos.
  • Menção de que tipos como raw_ptr<T> parecem ter sido criados para ajudar nisso e podem até ter conseguido evitar a falha ocorrida em [2].
  • É lamentado que não exista uma forma, dentro do projeto, de alternar entre diferentes dialetos para código sensível a desempenho e código em que desempenho não precisa ser uma grande preocupação.
  • Reflexão sobre se quase valeria a pena misturar duas linguagens diferentes para distinguir claramente entre partes sensíveis a desempenho e partes com muito estado assíncrono, nas quais há maior chance de algo dar errado.

• Elogio à eficácia da visualização e observação sobre uso de CPU

  • Visualização muito limpa, com a observação de que o uso de CPU fica um pouco alto ao expandir áreas.
  • Expectativa de que a equipe do Chrome use internamente uma ferramenta parecida e opinião de que ela seria útil para entender a superfície de ataque.

• Elogio à ideia e à execução, além de pergunta sobre os dados brutos

  • Elogio de que a ideia é ótima e a execução também foi muito bem feita.
  • Comentário perguntando se há acesso aos dados brutos e mencionando o valor de tentar um sunburst ou um tree map.

• Sugestão para não incluir certos tipos de arquivo

  • Observação detalhada sugerindo não incluir arquivos DEPS, AUTHORS e BUILD.gn.

• Sugestão de ponderação com base no número de linhas de código alteradas

  • Opinião de que seria interessante ponderar o "dinheiro" atribuído a um bug de acordo com o número de linhas de código modificadas.
  • Sugestão de que, se 10 linhas do arquivo A e 1 linha do arquivo B forem alteradas, o arquivo A receba 1/11 do "dinheiro", por ter representado a maior parte do bug.

• Pedido por uma funcionalidade para mostrar a recompensa média por arquivo

  • Solicitação de uma funcionalidade que exiba, em cada nó, a recompensa média por arquivo.

• Ideia de exibir valores normalizados pelo número de linhas de código

  • Sugestão de uma versão que mostre os valores normalizados pelo número de linhas de código.

• Elogio ao insight visual sobre onde concentrar esforços

  • Avaliação de que é muito legal oferecer um insight visual sobre onde os esforços devem ser concentrados.