Money Tree Browser que ofrece recompensas por errores de Chromium

Introducción a Chromium Money Tree Browser

• Chromium Money Tree Browser es un sitio web que vincula las recompensas del Chrome VRP (programa de recompensas por errores) con los cambios (correcciones) realizados en archivos específicos.
• Este sitio fue creado de forma muy simple, por lo que no conviene esperar una gran experiencia de usuario ni una alta precisión de los datos.
• Las recompensas por errores se dividen por archivo; por ejemplo, si para corregir un error con valor de $1000 se modificaron 5 archivos, a cada archivo se le asignan $200.
• Los datos están basados en información disponible hasta inicios de noviembre de 2023.

Opinión de GN⁺

• Chromium Money Tree Browser es una herramienta interesante que muestra visualmente a desarrolladores e investigadores de seguridad qué archivos fueron modificados dentro del programa de recompensas por errores de Chrome, y cómo se distribuyeron las recompensas correspondientes.
• Este sitio ofrece una perspectiva sobre cómo se calculan las recompensas por correcciones de errores, y puede ayudar a compartir información útil dentro de la comunidad relacionada con la seguridad.
• Aunque conviene moderar las expectativas sobre la experiencia de usuario y la precisión de los datos, este sitio puede contribuir a aumentar la conciencia sobre vulnerabilidades de seguridad en proyectos de código abierto y motivar a los desarrolladores a dar más importancia a la seguridad.

[GN⁺]

Comentarios en Hacker News

• Interés por algo similar a una función que un desarrollador había querido construir desde hace mucho tiempo

  • Reflexión sobre la utilidad de una forma de calcular la probabilidad de que un cambio dado cause problemas, basándose en cambios ocurridos en el pasado en un archivo o en partes específicas de un archivo.
  • Asignar una puntuación de riesgo a cada cambio y vincularla al PR (Pull Request) para avisar a los revisores de código qué partes requieren atención adicional, y usarla como señal para destacar cambios riesgosos al desplegar.
  • Es difícil rastrear la misma parte del código cuando esta se mueve hacia arriba o hacia abajo debido a inserciones/eliminaciones. Un algoritmo basado solo en números de línea puede ser problemático.
  • Se sugiere que incluso trabajar solo a nivel de archivo podría ser lo suficientemente útil.

• Señalan que faltaron correcciones en ciertas bibliotecas de terceros

  • Parece que faltan algunas correcciones hechas en bibliotecas de terceros (por ejemplo, ffmpeg). Estas correcciones a menudo se manejan primero en upstream, por lo que pueden ser difíciles de rastrear.

• Al revisar muchos bugs de la UI del navegador Chrome, surgen dudas sobre problemas de use-after-free en datos donde el rendimiento de la gestión manual de memoria no es importante

  • Observaciones sobre problemas de use-after-free que ocurren en código como el ciclo de vida del cuadro de diálogo de "selección de archivo", aun cuando el rendimiento de la gestión manual de memoria no es importante ahí.
  • Se sugiere que en ese tipo de código podría ser mejor usar siempre punteros más inteligentes y más lentos.
  • Se menciona que tipos como raw_ptr<T> parecen estar pensados para ayudar, y que posiblemente lograron defenderse del crash ocurrido en [2].
  • Se lamenta que dentro del proyecto no exista una forma de cambiar de dialecto entre código sensible al rendimiento y código donde el rendimiento no necesita considerarse tanto.
  • Se reflexiona sobre si casi valdría la pena mezclar dos lenguajes distintos para separar claramente las partes sensibles al rendimiento de las partes con muchos estados asíncronos donde es más fácil que algo salga mal.

• Elogios a la efectividad de la visualización y observaciones sobre el uso de CPU

  • Se comenta que la visualización es muy limpia, aunque al expandir áreas el uso de CPU parece algo alto.
  • Se espera que el equipo de Chrome use internamente una herramienta similar, y se opina que sería útil para entender la superficie de ataque.

• Elogios a la idea y a la ejecución, además de una consulta sobre los datos en bruto

  • Se elogia que la idea es genial y que la ejecución estuvo bien lograda.
  • Se pregunta si hay acceso a los datos en bruto y si valdría la pena intentar un sunburst o un tree map.

• Sugerencia de no incluir ciertos tipos de archivo

  • Comentario detallado que propone no incluir los archivos DEPS, AUTHORS y BUILD.gn.

• Sugerencia de ponderar según la cantidad de líneas de código modificadas

  • Se comenta que sería interesante ponderar el "dinero" asignado a un bug según la cantidad de líneas de código modificadas.
  • Se propone que, si se cambiaron 10 líneas del archivo A y 1 línea del archivo B, al archivo A se le asigne 1/11 del "dinero" porque concentra la mayor parte del bug.

• Solicitud de una función para mostrar la recompensa promedio por archivo

  • Se pide una función para mostrar en cada nodo la recompensa promedio por archivo.

• Idea de mostrar montos normalizados según la cantidad de líneas de código

  • Se propone una versión que muestre los montos normalizados según la cantidad de líneas de código.

• Elogios a la percepción visual sobre dónde concentrar los esfuerzos

  • Se valora como muy bueno que ofrezca una percepción visual de dónde conviene concentrar los esfuerzos.