Des scripts trompent les navigateurs pour récupérer des données, le Français AdThink nous répond
Gestionnaire es-tu là ?
Le 03 janvier 2018 à 16h12
9 min
Internet
Internet
Des chercheurs de l’université de Princeton se sont penchés sur des scripts capables d’extraire des identifiants depuis les formulaires d’authentification à travers les gestionnaires de mots de passe intégrés aux navigateurs. L'une des entreprises concernées, Adthink, nous a répondu à ce sujet.
Gunes Acar, Steven Englehardt et Arvind Narayanan font partie du Center for Information Technology Policy de l’université de Princeton. Ils connaissent bien les attaques de type XSS (cross-site scripting), qui existent depuis plus d’une décennie. Mais au-delà des risques en matière de sécurité, le principe pose également un problème pour la vie privée quand il est exploité par certaines entreprises, notamment dans le domaine publicitaire.
Les chercheurs ont analysé en particulier deux scripts d'Adthink et OnAudience. Intégrés dans une page web, ils placent des formulaires invisibles d’authentification, destinés à faire réagir les gestionnaires de mots de passe natifs des navigateurs. De là, les scripts extraient l’identifiant, souvent une adresse email, et peuvent même (en théorie) récupérer les mots de passe.
À la clé un suivi très précis des habitudes de navigation à travers l'ensemble des sites utilisant le même script.
Fonctionnement du mécanisme
Le principe général se base sur les gestionnaires de mots de passe intégré aux navigateurs, pas ceux utilisés sous la forme d'une extension. Chrome, Edge, Firefox, Opera ou Safari possèdent cette fonctionnalité, que les utilisateurs affectionnent particulièrement. Et pour cause : elle évite d’avoir à se rappeler des mots de passe qui, idéalement, sont complexes à écrire et uniques à chaque service visité.
Adthink et OnAudience sont des scripts que les concepteurs de sites peuvent intégrer directement dans leurs pages. Ils ne sont alors pas considérés comme de tierces parties. Ils appellent un formulaire d’authentification associé au domaine principal, provoquant une action du gestionnaire intégré de mots de passe, qui remplit alors les champs proposés.
Dans leur page de démonstration, les chercheurs prouvent leurs dires : l'identifiant et le mot de passe peuvent être récupérés. Pour le second, seul Chrome réclame une action supplémentaire, sous la forme d'un simple clic n'importe où sur la page.
Les scripts créent une empreinte (hash) de l’identifiant, généralement un pseudo ou une adresse email. Or, dans ce dernier cas, l’internaute utilise très souvent la même et n'en change que très rarement. De fait, le hash d’une adresse devient une information fiable pour bâtir un profil de navigation. Ce dernier ne peut bien sûr se construire qu'à travers les sites utilisant les scripts d'un même acteur.
Le comportement des navigateurs
Tous les navigateurs considèrent les scripts comme des éléments intégraux des sites web visités, puisque le code est directement présent dans celui des pages. Les protections mises en place contre les éléments tiers ne fonctionnent donc pas.
Comme le soulignent les chercheurs, les navigateurs sont ici ballotés entre la sécurité et la facilité d'utilisation. Le consensus est de faire confiance aux éléments intégrés de premier niveau, et de faire plus attention aux contenus tiers appelés par les pages, notamment via des iframes. Certaines protections existent, mais elles dépendent des développeurs web, comme l’attribut HTTPOnly, bloquant l’accès des scripts aux cookies définis comme critiques pour la sécurité.
Cela étant, le comportement des navigateurs n’est pas le même sur le remplissage automatique. Chrome par exemple remplit l’identifiant, mais pas le mot de passe, à moins que l’utilisateur ne déclenche lui-même l’action. Firefox et les autres remplissent ce champ sans interaction. Ce qui donne une éventuelle piste de solution.
Les chercheurs insistent : le concept n’a rien de nouveau dans le fond, mais l’utilisation pour des scripts liés au profilage – et donc à la publicité – est plus récente. En tant que telle, elle pose un souci potentiel de sécurité, et très clairement de respect de la vie privée.
Adthink évoque un script expérimental
Adthink, l'une des deux entreprises abordées par les chercheurs, est justement française. Jonathan Métillon, directeur de l'innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d'ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ».
Le responsable nous affirme surtout que ce script ne comptait que « pour une infime fraction des données que l'on reçoit. Nous faisons surtout de la consolidation de profil sur la base des données que nos clients nous envoient spontanément ». Interrogé sur les catégories parfois très personnelles d'informations prises en charge (âge, taille, poids, adresse, identité sexuelle et autre), il nous indique que les scripts d'Adthink sont tout simplement « utilisés chez une grande variété de clients, dont des sites de rencontres ».
Jonathan Métillon insiste : « Nous n'avons pas de données personnelles. Nous ne possédons que des hashs d'adresses email, pas les adresses elles-mêmes ». La CNIL considère néanmoins tout identifiant unique, comme l'empreinte d'une adresse email, comme une donnée à caractère personnelle. Il confirme cependant que même si le script en question a été retiré et qu'il ne récupérait pas le mot de passe, « l'opération est tout à fait possible, et entre de mauvaises mains, ce genre de technique pourrait fait des dégâts ».
La finalité de ces profils se devine aisément : le ciblage publicitaire. Le directeur nous certifie que tout client utilisant ses scripts doit l'indiquer dans ses conditions d'utilisation et fournir un opt-out, en application des recommandations de la CNIL. Par ailleurs, Adthink travaille actuellement à se mettre en conformité avec les futurs RGPD et ePrivacy, qui doivent tous deux prendre effet en mai.
Des solutions immédiates et d'autres à venir
Mais même en comptant le retrait du script, le choix d'Adthink ne peut pas être généralisé à tous les acteurs. Comme l'indiquent les chercheurs, il ne s'agit que de deux scripts parmi d'autres. D'ailleurs, représentent-ils l’avenir du ciblage publicitaire ? Pas si sûr.
Pour contourner ce problème, le changement le plus « simple » à introduire pour les navigateurs serait de casser le remplissage automatique, par exemple en proposant une fonction qui nécessite un clic avant que les données ne soient affichées dans les champs correspondants. Du point de vue de l'utilisateur, la mesure passerait sans doute mal, tant les éditeurs cherchent à réduire les frictions, mais elle aurait le mérite d'être plus protectrice.
À plus longue échéance, l’API Credential Management en préparation au W3C pourrait elle aussi résoudre le souci, puisqu’elle adopte le même comportement que décrit précédemment : une action de l’utilisateur est requise. L’interface n’en est cependant qu’au statut de brouillon et il faudra encore que les navigateurs l’implémentent quand elle sera prête, ce qui aurait le mérite de rationaliser les usages.
Notez à ce sujet que la situation ne concerne bien que les gestionnaires de mots de passe intégrés et non les tiers, disponibles à travers des extensions comme 1Password (qui a d'ailleurs réagi dans les commentaires du compte-rendu des chercheurs pour le signaler), Dashlane ou Lastpass.
Ces produits enregistrent bien les identifiants, mais nécessitent tous une action de l’internaute pour remplir les champs du formulaire. Si vous êtes d’ailleurs utilisateur de l’une de ces solutions, une mesure à prendre peut être de couper le gestionnaire intégré au navigateur, tous proposant cette option.
Le fond du problème : un pistage toujours plus intense de l’utilisateur
Pour le chercheur Arvind Narayanan, le cœur du souci réside dans le choix des scripts opéré par certains sites : « Ces problèmes apparaissent en partie parce que les opérateurs de sites web ont été négligents en intégrant des scripts tiers sans en comprendre les implications ». Des entreprises ou développeurs se seraient donc fait séduire par des prestataires vantant les mérites de solutions promettant un profilage toujours plus poussé des visiteurs.
Même si tout porte à croire que le comportement de ces scripts n’est pas dangereux dans le sens « sécurité » du terme (du moins tant qu'ils se contentent de l'identifiant et ne récupèrent pas les mots de passe), ils ont un impact potentiel sur la vie privée. Le cas est à replacer dans un contexte plus global de réflexion sur la publicité et le ciblage précis des internautes qui l’accompagne, et la question du consentement.
Les actualités dans ce domaine sont particulièrement nombreuses depuis quelques mois, avec par exemple Mozilla, les approches différentes d'Apple et Google, ou encore nos propres choix en la matière. Trop nombreux sont encore les sites à se baser sur des méthodes ayant un point commun : elles cherchent à obtenir des données quitte à « tricher ».
On entend ici par tricherie la récupération d’informations que l’utilisateur n’aurait pas données de lui-même, ou pour lesquelles il n’a pas donné son accord. Le comportement de ces scripts n’est guère différent dans l’absolu de ceux abordés le mois dernier, qui permettaient pour rappel à des sites d’enregistrer toutes les frappes au clavier. Bien évidemment sans le consentement de l'internaute, et sans le prévenir.
Le 03 janvier 2018 à 16h12
Des scripts trompent les navigateurs pour récupérer des données, le Français AdThink nous répond
-
Fonctionnement du mécanisme
-
Le comportement des navigateurs
-
Adthink évoque un script expérimental
-
Des solutions immédiates et d'autres à venir
-
Le fond du problème : un pistage toujours plus intense de l’utilisateur
Commentaires (64)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 03/01/2018 à 16h22
#1
Et après on nous dira que les bloqueurs de pub/tracker c’est mal, ca tue le web gratuit…
N’empêche que ca protège des “gentils” scripts de récupération de données persos. " />
Le 03/01/2018 à 16h25
#2
Le gros problème ici c’est firefox qui donne gentiment toutes les infos sans rien demander à l’utilisateur…
Le 03/01/2018 à 16h26
#3
J’ai fait le test avec Chrome, uBLock Origin et Disconnect activés, et les deux n’ont pas empêché la récupération des identifiants et mot de passe.
Le 03/01/2018 à 16h27
#4
Les mecs sont justes en train de scier toujours plus frénétiquement la branche sur laquelle ils sont assis…
A force d’intégrer toujours plus de putasseries de ce genre (formulaire cachés, mineurs BT, etc), au final, le marché de la pub en ligne va juste se concentrer autour d’Apple, Google et MS (qui possèdent leur propre navigateur et leur propre régie pub) et tout le reste va être bloqué par défaut.
Et là, tout le monde aura perdu…
Parce que les pires pratiques ne viennent pas forcément des GAFA quoiqu’on en dise mais bien des plus petites régies qui abusent clairement à tous les niveaux. Par contre, ce sont les GAFA qui concentrent le plus d’informations et quand elles seront les dernières dans le game, on sera définitivement baisés car on aura aucune échappatoire.
Le 03/01/2018 à 16h29
#5
L’article précise bien que les scripts ne sont pas considéré comme des scripts tiers, donc pas comme des trackers, donc uBLock Origin et Disconnect ne voient rien. C’est encore plus inquiétant.
Le 03/01/2018 à 16h33
#6
Dois-je en déduire que l’utilisation d’un logiciel type lastpass ou dashlane suffit à empêcher ceci? Puisqu’ils ne stockent pas les infos dans le navigateur…
Le 03/01/2018 à 16h36
#7
Il est beau le web de nos jours …
Branchez une dynamo à la tombe de ses créateurs, vous aurez de l’énergie à l’infinie. " />
Bande de connards, pas d’autre réaction qui me vient en tête.
Le 03/01/2018 à 16h36
#8
Le 03/01/2018 à 16h37
#9
Si le logiciel rempli automatiquement les champs le même souci est présent (un script en js peut lire le champ une fois qu’il est rempli) j’utilise Kaspersky Password Manager et il rempli les champs automatiquement d’ailleurs :/
Le 03/01/2018 à 16h49
#10
En effet il remplit les champs automatiquement. Donc si le script récupère les infos dans les champs alors le stockage hors navigateur ne protège en rien…
Le 03/01/2018 à 16h50
#11
Dans Firefox, about:config, il y a cette clé qu’on peut passer à false : signon.autofillForms
Pas encore testé si ça peut résoudre le problème par contre.
Le 03/01/2018 à 16h57
#12
Dans la démo, le 3rd-party script est chargé depuis un site qui n’est pas blacklisté par uBLock. " />
Le 03/01/2018 à 16h59
#13
“Jonathan Métillon, directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était
expérimental et est d’ailleurs déjà désactivé. Il avait été mis en
place par des personnes qui ne travaillent plus chez nous ».
Le responsable nous affirme surtout que ce script ne comptait que « pour
une infime fraction des données que l’on reçoit. Nous faisons surtout
de la consolidation de profil sur la base des données que nos clients
nous envoient spontanément »
”
Traduction: “c’était juste pour voir, et puis on le fait plus, d’ailleurs on peut pas vraiment dire que c’était nous, c’était des anciens salariés, et puis c’était pas si grave”
" />
Le 03/01/2018 à 16h59
#14
La seule solution c’est d’utiliser des Dashlane et autres keepass, bref des manager de mot de passe. Mais ce n’est pas la panacée non plus, je connais un site qui (parce qu’il est mal codé je pense) arrive a injecter le formulaire de login à chaque page, même logué, et arrive a faire réagir les gestionnaire de mot de passe et leur faire injecter les infos dans le formulaire.
Au vu de cette news je vais investiguer. Si vous voulez le site contactez moi par MP. Ce n’est pas un site de boule ou de pirate ou illégal, pas du tout. C’est un bête site marchand.
Le 03/01/2018 à 16h59
#15
Plus qu’à désactiver l’autofill sur Kee, dommage c’était pratique :(
Le 03/01/2018 à 17h02
#16
Je ne ne sais pas comment Youtube a gardé mes recherches d’hier ? (ce n’est pas normal)
Le 03/01/2018 à 17h02
#17
Le 03/01/2018 à 17h07
#18
« […] directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d’ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ». » (article Next inpact)
Nous voilà rassurés " />
Le 03/01/2018 à 17h08
#19
C’est faux, Firefox ne remplit plus le Champs ID et MDP depuis plusieurs versions dont la dernière
Le 03/01/2018 à 17h09
#20
Le 03/01/2018 à 17h13
#21
Le 03/01/2018 à 17h14
#22
Le 03/01/2018 à 17h27
#23
facebook traquait/traque les utilisateurs via son bouton de partage disséminé un peu partout sur l’internet. Même les utilisateurs n’ayant pas de compte.
Donc niveau putasserie ils se mettent bien. Google je t’en parle pas. Reste Apple et MS qu’ont le bénéfice du doute.
Le 03/01/2018 à 17h28
#24
Le 03/01/2018 à 17h34
#25
Le 03/01/2018 à 17h42
#26
Une grosse amende, de la taule pour les responsables… À non ça va pas le faire désolé
Le 03/01/2018 à 17h44
#27
L’adresse mail que j’utilise pour chaque compte est unique. A partir de là, même si ça fonctionnait ( je ne laisse pas le navigateur mémoriser ce que je frappe), ça ne servirait à rien pour me tracer.
Le 03/01/2018 à 17h45
#28
Traduction: “c’était juste pour voir, et puis on le fait plus, d’ailleurs on peut pas vraiment dire que c’était nous, c’était des anciens salariés, et puis c’était pas si grave”
Si eux ne le font plus, d’autres le font toujours…
list of sites from Alexa top 1 million which embed scripts that abuse built-in password managers.
Le 03/01/2018 à 18h29
#29
Le 03/01/2018 à 18h38
#30
les opérateurs de sites web ont été négligents
Oups, j’ai ajouté un tracker malveillant par mégarde…
Peut-être qu’ils ne savaient pas ce qu’ils intégraient, mais de là à en être sûr…
Le 03/01/2018 à 19h19
#31
Attention, il y en a deux : une signon.autofillForms (sur True par défaut) et une signon.autofillForms.http (sur False par défaut).
Firefox 57.0.2 64bits.
Le 03/01/2018 à 19h24
#32
Il est possible de bloquer le remplissage automatique des formulaires sur Opera. ;)
Le 03/01/2018 à 19h26
#33
Idem sous Firefox.
Le 03/01/2018 à 19h40
#34
« Ces problèmes apparaissent en partie parce que les opérateurs de
sites web ont été négligents en intégrant des scripts tiers sans en
comprendre les implications »
C’est pas faute de signaler ces dérives pourtant… Mais les décideurs veulent juste la même chose que le concurrent, qui lui ne s’embarasse pas avec ces questions ! Donc on développe n’importe quoi viteuf’, on ajoute des scripts en pagaille “parce que ça a l’air sympa”, et tant qu’on n’a pas touché le sol, “jusqu’ici tout va bien” " />
Le 03/01/2018 à 19h45
#35
Idem ici. Dommage c’était pratique. Ensuite, la dernière version est plutôt bien fichue, elle affiche un petit icône pour saisir le login et le mdp dans le formulaire, mais bon ça fait toujours 2 clics de plus. " />
En tout cas, merci NI pour l’info. " />
Le 03/01/2018 à 20h14
#36
Pour désactiver le remplissage automatique dans Firefox :
Le 03/01/2018 à 20h47
#37
A ce niveau là, ce n’est plus de la triche ou du ciblage, mais limite de l’espionnage, voire du vol d’information à caractères personnelles… Jusqu’où va-t-on permettre le cible pour raison publicitaire ? Surtout que tout cela se fait à l’insu de l’utilisateur: qui peut dire ce qui se passe vraiment sur une page web sans aller voir le code source et y étudier les trop nombreux fichiers js ?
Le 03/01/2018 à 20h49
#38
Le mode de navigation privée n’a pas l’effet, mais il n’en reste pas moins que les identifiants sont enregistrés quel que soit le mode de navigation ! Il suffit donc d’une fois, et about:config s’impose. Merci à NXI pour ces news tout aussi INformatives qu’ahurissantes techniquement. " />
Le 03/01/2018 à 21h07
#39
Ouai, en gros ça rend encore plus dangereux le XSS. J’fais bien de pas enregistrer ma CB je me dis, avec le temps…
Le 03/01/2018 à 21h11
#40
Suite à cette faille, je me suis posé une question.
Imaginons que je veuille me connecter à un site. Sur la page de connexion, il y a les deux champs textes à remplir (Login et mot de passe). Je les remplis, avant de cliquer sur connecter.
Qui me dit que sur la page de connexion, il n’y a pas là aussi un script qui scrute ces deux champs pour récupérer mon login et mon mot de passe ?
Le 03/01/2018 à 21h13
#41
D’où l’intérêt de la navigation privée systématiquement :
1-ca évite toute information retenue dans le navigateur
2-ca entraine nos neurones à retenir les mots de passe !
Le 03/01/2018 à 21h47
#42
Fait !
Merci " />
Le 03/01/2018 à 22h21
#43
Il n’y a pas une loi récente contre l’intrusion dans un système informatique avec de sévères peines de prison à la clé? " />
En taule les publicitaires " />
Le 03/01/2018 à 23h01
#44
Bon ben je crois que je vais passer à un gestionnaire de mot de passe en 2018
Le 04/01/2018 à 08h55
#45
Avec l’extension lastpass il est possible de désactiver le remplissage automatique.
Le 04/01/2018 à 09h00
#46
Le 04/01/2018 à 09h17
#47
Ce genre de script ne peut pas être considéré autrement que comme un malware. " />
Le 04/01/2018 à 09h28
#48
Merci, je la cherchais justement et difficile de trouver l’info.
Et merci au passage à ceux qui ont donné la méthode sur les différents brouteurs et ne se sont pas contenté de dire “si on peut”. " />
Le 04/01/2018 à 10h44
#49
Pour moi ça le résoud, ça ne récupère plus les données sauvegardées par le gestionnaire de mot de passe.
Firefox Developer 58.0b13
Le 04/01/2018 à 10h49
#50
Merci Ra-mon, cela fonctionne, mais seulement après avoir redémarré le navigateur.
Pour Chrome bien entendu c’est chrome://flags/#fill-on-account-select qu’il faut mettre à Enabled (pas vivaldi://)
Le 04/01/2018 à 10h52
#51
Pas de problèmes chez moi avec firefox 57.03, ghostery et noscript
Le 04/01/2018 à 11h15
#52
Pas de trace c’est déjà une très bonne trace.
Le 04/01/2018 à 11h42
#53
Rien.
Quand tu donnes ton login/mdp à un site web, c’est que tu lui fais confiance pour les gérer… ce dont il est plus ou moins digne. Mais c’est logique que quand tu t’authentifies, il sache qui tu es (et puisse te tracer comme tel).
Ce qui est vicieux ici, c’est qu’il se débrouille pour savoir qui tu es même lorsque tu n’es pas authentifié et tu n’as rien saisi.
Le 04/01/2018 à 12h59
#54
Je suis le seul à penser qu’il n’y a pas réellement de faille dans ce cas ?
Que le mot de passe se rentre tous seul ou pas, tous les scripts inclus dans une page (third party ou non) ont accès aux mot de passe que l’on rentre pour se connecter.
C’est aux sites que revient la responsabilité de ne pas inclure de js third party qui ne sont pas de confiance.
Car même si on rentre le mot de passe à la main, tous les scripts de la pages y ont accès, donc vraiment je ne vois rien de surprenant dans cette démonstration…
Ou alors j’ai raté quelque chose!
Le 04/01/2018 à 13h13
#55
Bah pour le coup, c’est que c’est retro actif. Le script n’a pas eu besoin d’être la quand tu t’es loggé. Mais sinon en effet, ca me semble pas porter beaucoup plus loin.
edit : J’ajoute aussi qu’il n’a pas besoin d’etre présent sur la page de login, et ca pour le coup, c’est pas rien
Le 04/01/2018 à 13h26
#56
Cela dépend de ta config. Il y a maintenant 2 valeurs :
signon.autofillForms par défaut à true (vrai)
signon.autofillForm.httppar défaut à false (faux)
Donc par défaut si tu ne touches à rien, les formulaires https sont remplis mais pas ceux en http. Les scripts dont il est question étant intégrés par le site visité, il est probable que cela fonctionne si ceux-ci sont en https.
Le 04/01/2018 à 14h03
#57
D’un autre côté, est-il normal que des navigateurs remplissent des champs de formulaire cachés ? Je pense que le vrai problème est là.
Le 04/01/2018 à 20h47
#58
Le 05/01/2018 à 09h49
#59
hum encore un article à balancer au prochain qui viendra pleurnicher sur le fait que les vilains internautes font tout pour éviter de se faire traquer et ensuite matraquer à coup de pub.
Avec beaucoup de chances, peut-être que ça donnera au législateur européen un électrochoc, et que celui-ci imposera des règles strictes afin de garantir le droit à l’utilisateur de choisir de partager ses données personnelles.
Le 05/01/2018 à 10h11
#60
Jonathan Métillon, directeur de l’innovation et de la communication, nous a ainsi expliqué que le script en question « était expérimental et est d’ailleurs déjà désactivé. Il avait été mis en place par des personnes qui ne travaillent plus chez nous ».
En quoi le fait que ça a été mis en place par des personnes qui ne sont plus là change quoi que ce soit à la responsabilité de la société ? Ces personnes devaient être encadrées et donc les responsables ont laissé faire ou peut-être même encouragé. Bref, la société est responsable et devrait s’excuser platement.
Lui-même présent depuis 2013 à des postes de management devrait faire profil bas.
Mais quand je lis son appel à candidatures sur son profil LinkedIn, je suis sans illusion :
Adthink.com is looking for:
* Traders / Media Buyers
* Business Developers
* Product Managers
Accepting only smart and ambitious people with excellent analytical thinking and/or fabulous negotiation talent. Extremely incentivized package with multiple bonuses! Connect to me now to join Adthink.com
Bref, il pense que le fric sera leur motivation, fric fait sur l’exploitation des données personnelles.
Le 05/01/2018 à 12h27
#61
Salut,
Je ne trouve pas ton deuxième paramètre dans about:config. Problème de frappe ?
Le 05/01/2018 à 13h58
#62
Sur quelle version de firefox es-tu ? (certains com, dont celui auquel tu réponds d’ailleurs, laissent à penser que le 2eme est plus ou moins récent)
En version 57.0.3, en tapant juste signon dans la barre de recherche j’ai :
signon.autofillForms
signon.autofillForms.http
en ligne 2 et 3, respectivement
Le 05/01/2018 à 14h25
#63
Toutes les news sur les publicités me font dire que ce sont des menaces capables :
Interdiction des scripts publicitaires… “It’s the only way to be sure” comme disait Ripley.
Le 07/01/2018 à 00h02
#64
effectivement tu as raison.
J’ai donc modifié le “signon.autofillForms” en false pour être tranquille.
Merci pour l’info ;)