A traição da extensão do Grammarly

 (dbushell.com)
2 pontos por GN⁺ 2025-03-31 | 1 comentários | Compartilhar no WhatsApp

Por que a extensão do Grammarly quebrou sites

  • Nos últimos meses, o autor recebeu com frequência relatos de que o layout de sites estava estranhamente quebrado
  • A causa do problema foi identificada como a extensão de navegador do Grammarly, e ele mesmo a instalou para confirmar isso

Processo de descoberta do problema

  • A extensão do Grammarly solicita as seguintes permissões:
    • acesso aos dados de todos os sites
    • exibição de notificações
    • acesso às abas do navegador
  • Em testes no Firefox, foi constatado que o Grammarly injeta uma folha de estilos própria na página
    • Essa folha de estilos não pode ser detectada diretamente na página web (folha de estilos oculta)
    • Ela até contorna a Content Security Policy
  • Um elemento <grammarly-desktop-integration> também é inserido dentro da tag <html> (a finalidade não está clara)

Por que foi no meu site?

  • No fim da folha de estilos do Grammarly, há o seguinte código: 
    :host,  
:root {  
  --rem:16  
}
  • Essa configuração colide com a unidade padrão do CSS, 1rem = 16px, e o autor também já usava a propriedade customizada --rem
  • O Grammarly define um valor fixo de --rem globalmente e tenta fazer dimensionamento dinâmico de fontes
  • Isso acabou quebrando os cálculos de tipografia fluida do autor

Como o autor reagiu

  • No início, ele usou um Mutation Observer para detectar os elementos inseridos pelo Grammarly e sobrescrevê-los com estilos !important
  • Depois, mudou o nome da sua variável CSS de --rem para --🤡 (emoji Unicode)
  • Emojis são válidos como nomes de variáveis CSS
  • Assim, é possível evitar conflito com a definição global de --rem do Grammarly

A essência do problema

  • Como extensão web, o Grammarly força a injeção de estilos globais em todos os sites
  • Em especial, usar um nome comum de variável CSS como --rem é algo muito prejudicial
  • Mesmo usando nomes de classes aleatórios internamente no código, não dá para entender por que aplicaram justamente uma nomenclatura pública de forma global
  • O código é injetado mesmo sem usar de fato a extensão

Conclusão e proposta

  • O autor entrou em contato com o Grammarly e recebeu uma resposta rápida, mas não conseguiu falar com alguém que entendesse tecnicamente o problema
  • A solução ideal seria o Grammarly usar um nome de variável como --🤡, deixando os demais desenvolvedores livres para usar --rem

Leituras relacionadas

1 comentários

 
GN⁺ 2025-03-31
Opiniões do Hacker News

  • O problema com a minha extensão é um pouco diferente. Distribuímos uma extensão que facilita alternar entre servidores proxy para testes de geolocalização

    • Há alguns meses tive a pior demonstração para cliente da minha vida. Parecia que o produto não funcionava
    • Depois de muito debugging, descobrimos que uma atualização recente da extensão 1Password tinha quebrado a nossa
    • Eles estavam inscritos em eventos de autenticação, mas não retornavam, e por causa disso nosso assinante não era chamado
    • A equipe de suporte da 1Password foi melhor que a da Grammarly, mas foi difícil convencê-los da prioridade
    • Uma extensão russa exigida em sites do governo também tem o mesmo problema

  • Ao injetar scripts ou estilos em páginas desconhecidas, usar namespace nas variáveis é o mínimo de educação

  • É assustador ver que muitos compartilhamentos e gravações de tela incluem por padrão invasões de tela verde em todos os sites

    • Não é só poluição visual; privacidade e vetores de ataque também são um problema
    • O Chrome pode ativar extensões apenas quando necessário. Fico me perguntando por que ninguém faz isso

  • Sou engenheiro da extensão do Grammarly. Peço desculpas por ter estragado a UX de dbushell.com

    • Não foi intencional, e estamos usando várias técnicas para evitar isso
    • Adicionamos temporariamente uma exceção para dbushell.com
    • Estamos trabalhando em mudanças para garantir isolamento de estilos

  • Encaminhei esse problema para a equipe de engenharia

  • Tenho um problema parecido com o Google Translate quebrando meu web app

    • Usuários que usam o Google Translate reclamam que o app quebra
    • Isso acontece porque o Google altera o estado do app em um nível meta mais alto
    • Estou tentando detectar o Google Translate e exibir um aviso

  • No trabalho, temos muitos erros no Sentry relacionados a extensões de navegador

    • O Google Translate no Chrome é notório por quebrar sites baseados em React
    • Isso exige o trabalho incômodo de ignorar novos problemas causados por extensões
    • Usamos filtragem no lado do cliente para reduzir o volume coletado

  • Fico curioso sobre qual variável conseguiria quebrar mais a web

    • --primary-color: transparent

  • Fico curioso sobre como vocês lidam com extensões de navegador hostis

  • Fico curioso se dá para sequestrar plugins usando esse método

    • No mínimo, deveria ser possível injetar texto, e talvez até renderizar um formulário de login abusando da confiança do usuário
    • Fico em dúvida se injetar elementos em um documento controlado por outra pessoa é realmente seguro