Pour info j'ai posté un message sur le forum XenForo et à l'équipe à l'origine de cet article pour mieux comprendre. En espérant avoir rapidement une réponse pertinente...
Wait & see...
David
Wait & see...
David
Pour ceux (mais ils semblent si rare ici) qui veulent se rendre compte vraiment de quoi il retourne, voici une page de test qui devrait réveiller votre vigilance.
https://senglehardt.com/demo/no_boundaries/loginmanager/
Mais cela reste une extraction de données personnelles à l'insu de son plein gré.Fortunately, we haven’t found password theft on the 50,000 sites that we analyzed. Instead, we found tracking scripts embedded by the first party abusing the same technique to extract emails addresses for building tracking identifiers.
[2] We tested the following browsers: Firefox, Chrome, Internet Explorer, Edge, Safari.
Ci-dessous le lien de la page final du test où était indiqué cette précision.On Chrome you need to interact with the page (i.e., click anywhere) for the password to be sniffed.
J'ouvre la page des paramètres,accéder à cette page de paramétrage?
Houla, je n'irai pas jusque là en étant affirmatifDonc d'après toi en mettant ces deux domaines dans le hosts puis en les mettant dans la liste des sites bloqués au niveau de javascript, on est tiré d'affaire ?
Publishers can isolate login forms by putting them on a separate subdomain, which prevents autofill from working on non-login pages. This does have drawbacks including an increase in engineering complexity. Alternately they could isolate third parties using frameworks like Safeframe. Safeframe makes it easier for the publisher scripts and iframed scripts to communicate, thus blunting the effect of sandboxing. Any such technique requires additional engineering by the publisher compared to simply dropping a third-party script into the web page.