La trahison de l’extension Grammarly

 (dbushell.com)
2 points par GN⁺ 2025-03-31 | 1 commentaires | Partager sur WhatsApp

Pourquoi l’extension Grammarly a cassé des sites web

  • Ces derniers mois, l’auteur a souvent reçu des signalements de mises en page étrangement cassées sur des sites web
  • La cause s’est révélée être l’extension de navigateur Grammarly, qu’il a lui-même installée pour le vérifier

Comment le problème a été découvert

  • L’extension Grammarly demande les autorisations suivantes :
    • accès aux données de tous les sites web
    • affichage de notifications
    • accès aux onglets du navigateur
  • Lors d’une expérience sur Firefox, Grammarly injecte sa propre feuille de style dans la page web
    • Cette feuille de style ne peut pas être détectée directement depuis la page web (feuille de style cachée)
    • Elle contourne même la Content Security Policy
  • Un élément <grammarly-desktop-integration> est aussi injecté dans la balise <html> (but inconnu)

Pourquoi mon site ?

  • À la fin de la feuille de style de Grammarly, on trouve le code suivant : 
    :host,  
:root {  
  --rem:16  
}
  • Ce réglage entre en conflit avec l’unité CSS par défaut, 1rem = 16px, et l’auteur utilisait lui aussi une propriété personnalisée --rem
  • Grammarly définit globalement une valeur fixe pour --rem et tente de gérer dynamiquement la taille des polices
  • Cela casse les calculs de typographie fluide de l’auteur

Réponse de l’auteur

  • Au départ, il a utilisé un Mutation Observer pour détecter les éléments injectés par Grammarly et les surcharger avec des styles !important
  • Il a ensuite renommé sa variable CSS de --rem en --🤡 (emoji Unicode)
  • Les emojis sont valides comme noms de variables CSS
  • Cela permet d’éviter le conflit avec la définition globale de --rem par Grammarly

La nature du problème

  • En tant qu’extension web, Grammarly injecte de force des styles globaux sur tous les sites web
  • Utiliser un nom de variable CSS courant comme --rem est particulièrement nuisible
  • Alors même qu’ils utilisent des noms de classes aléatoires dans leur code interne, on comprend mal pourquoi ils ont appliqué globalement un nom aussi générique
  • Le code est injecté même si l’extension n’est pas utilisée activement

Conclusion et proposition

  • L’auteur a contacté Grammarly ; il a reçu une réponse rapide, mais sans réussir à être mis en relation avec un interlocuteur comprenant réellement le problème technique
  • La solution idéale serait que Grammarly utilise un nom de variable comme --🤡, afin que les autres développeurs puissent continuer à utiliser librement --rem

À lire aussi

1 commentaires

 
GN⁺ 2025-03-31
Avis Hacker News

  • Mon problème avec les extensions est un peu différent. Nous déployons une extension qui permet de basculer facilement entre des serveurs proxy pour des tests de géolocalisation

    • Il y a quelques mois, j’ai vécu la pire démo client possible. On aurait dit que le produit ne fonctionnait pas
    • Après beaucoup de débogage, nous avons découvert qu’une mise à jour récente de l’extension 1Password avait cassé la nôtre
    • Ils s’étaient abonnés aux événements d’authentification mais ne faisaient pas de retour, ce qui empêchait l’appel de notre abonné
    • L’équipe support de 1Password était meilleure que celle de Grammarly, mais il a été difficile de les convaincre d’en faire une priorité
    • L’extension russe requise pour les sites gouvernementaux a le même problème

  • Quand on injecte des scripts ou des styles dans une page inconnue, le minimum de politesse est de mettre les variables dans un namespace

  • C’est effrayant de voir à quel point le partage d’écran et les enregistrements incluent par défaut des intrusions visuelles sur tous les sites web

    • Au-delà de la gêne visuelle, cela pose des problèmes de confidentialité et ouvre des vecteurs d’attaque
    • Chrome peut activer les extensions uniquement quand c’est nécessaire. Je me demande pourquoi presque personne ne fait ça

  • Je suis ingénieur sur Grammarly Extension. Désolé d’avoir cassé l’UX de dbushell.com

    • Ce n’était pas intentionnel, et nous utilisons diverses techniques pour éviter ce genre de problème
    • Nous avons temporairement ajouté une exception pour dbushell.com
    • Nous travaillons sur des changements pour garantir l’isolation des styles

  • J’ai remonté ce problème à l’équipe d’ingénierie

  • J’ai un problème similaire avec Google Translate qui casse mon application web

    • Des utilisateurs qui utilisent Google Translate se plaignent que l’application est cassée
    • C’est parce que Google modifie l’état de l’application à un niveau de métadonnées supérieur
    • J’essaie de détecter Google Translate et d’afficher un avertissement

  • Nous avons beaucoup d’erreurs sentry liées aux extensions de navigateur pendant le travail

    • Google Translate sur Chrome est notoirement connu pour casser les sites basés sur React
    • Cela oblige à un travail pénible pour ignorer les nouveaux problèmes causés par les extensions
    • Nous utilisons un filtrage côté client pour réduire le volume collecté

  • Je me demande quelle variable pourrait le plus casser le web

    • --primary-color: transparent

  • Je me demande comment les gens gèrent les extensions de navigateur hostiles

  • Je me demande si cette méthode permettrait de détourner un plugin

    • On devrait au minimum pouvoir injecter du texte, et on pourrait aussi exploiter la confiance de l’utilisateur pour afficher un formulaire de connexion
    • Je me demande vraiment s’il est sûr d’injecter des éléments dans un document contrôlé par quelqu’un d’autre