La traición de la extensión de Grammarly

 (dbushell.com)
2 puntos por GN⁺ 2025-03-31 | 1 comentarios | Compartir por WhatsApp

Por qué la extensión de Grammarly rompía los sitios web

  • En los últimos meses, recibió con frecuencia reportes de que el diseño de los sitios web se rompía de forma extraña
  • Se descubrió que la causa era la extensión de navegador de Grammarly, así que la instaló personalmente para comprobarlo

Cómo se descubrió el problema

  • La extensión de Grammarly solicita los siguientes permisos:
    • Acceso a los datos de todos los sitios web
    • Mostrar notificaciones
    • Acceso a las pestañas del navegador
  • Al hacer pruebas en Firefox, Grammarly inserta su propia hoja de estilos en la página web
    • Esta hoja de estilos no puede detectarse directamente desde la página web (hoja de estilos oculta)
    • Incluso elude la Content Security Policy
  • También se inserta un elemento <grammarly-desktop-integration> dentro de la etiqueta <html> (su propósito no está claro)

¿Por qué afectó a mi sitio?

  • Al final de la hoja de estilos de Grammarly se incluye el siguiente código: 
    :host,  
:root {  
  --rem:16  
}
  • Esta configuración se superpone con la unidad base de CSS, 1rem = 16px, y el autor también usaba la propiedad personalizada --rem
  • Grammarly fija globalmente un valor estático para --rem e intenta manejar un tamaño de fuente dinámico
  • Como resultado, se rompieron los cálculos de tipografía fluida del autor

Cómo respondió el autor

  • Al principio, usó Mutation Observer para detectar los elementos insertados por Grammarly y sobrescribirlos con estilos !important
  • Después cambió el nombre de su variable CSS de --rem a --🤡 (emoji Unicode)
  • Los emojis son válidos como nombres de variables CSS
  • Así puede evitar el conflicto con la configuración global de --rem de Grammarly

La esencia del problema

  • Como extensión web, Grammarly fuerza la inserción de estilos globales en todos los sitios web
  • En especial, usar un nombre de variable CSS tan común como --rem es muy perjudicial
  • Dentro de su código usan nombres de clase aleatorios, así que no se entiende por qué aplicaron de forma global un nombre tan compartido
  • El código se inserta incluso aunque no se use realmente la extensión

Conclusión y propuesta

  • El autor contactó a Grammarly; hubo una respuesta rápida, pero no logró que lo conectaran con alguien que entendiera el problema a nivel técnico
  • La solución ideal sería que Grammarly use un nombre de variable como --🤡, y que el resto de los desarrolladores puedan usar libremente --rem

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-03-31
Opiniones en Hacker News

  • Mi problema con las extensiones es un poco distinto. Distribuimos una extensión que facilita cambiar entre servidores proxy para pruebas de geolocalización

    • Hace unos meses tuve la peor demo con un cliente. Parecía que el producto no funcionaba
    • Después de mucho depurar, descubrimos que una actualización reciente de la extensión de 1Password había roto la nuestra
    • Estaban suscritos a eventos de autenticación, pero no hacían return, y por eso no se llamaba a nuestro suscriptor
    • El equipo de soporte de 1Password fue mejor que Grammarly, pero fue difícil convencerlos de que lo priorizaran
    • La extensión rusa requerida para sitios web gubernamentales también tiene el mismo problema

  • Al inyectar scripts o estilos en una página desconocida, ponerles un namespace a las variables es la cortesía mínima

  • Da miedo ver que muchas funciones de compartir pantalla y grabación incluyan por defecto intrusiones verdes en todos los sitios web

    • No solo es una molestia visual; también son un problema de privacidad y un vector de ataque
    • Chrome puede activar extensiones solo cuando se necesitan. Me pregunto por qué nadie hace esto

  • Soy ingeniero de la extensión de Grammarly. Perdón por arruinar la UX de dbushell.com

    • No era nuestra intención, y estamos usando varias técnicas para evitarlo
    • Agregamos temporalmente una excepción para dbushell.com
    • Estamos trabajando en cambios para garantizar el aislamiento de estilos

  • Ya pasé este problema al equipo de ingeniería

  • Tengo un problema parecido con Google Translate rompiendo mi app web

    • Los usuarios que usan Google Translate se quejan de que la app se rompe
    • Es porque Google cambia el estado de la app en un meta nivel superior
    • Estoy intentando detectar Google Translate y mostrar una advertencia

  • En el trabajo tenemos muchos errores de Sentry relacionados con extensiones del navegador

    • Google Translate en Chrome es famoso por romper sitios basados en React
    • Hay que hacer el engorroso trabajo de ignorar nuevos problemas causados por extensiones
    • Usamos filtrado del lado del cliente para reducir el volumen recopilado

  • Me pregunto cuál sería la variable que más podría romper la web

    • --primary-color: transparent

  • Me pregunto cómo manejan las extensiones de navegador hostiles

  • Me pregunto si este método podría usarse para secuestrar plugins

    • Como mínimo debería poder inyectar texto, y también podría renderizar un formulario de inicio de sesión abusando de la confianza del usuario
    • Me pregunto si de verdad es seguro inyectar elementos en un documento controlado por otra persona