Chrome 68 disponible, les sites sans HTTPS marqués comme « non sécurisés »

Chrome 68 disponible, les sites sans HTTPS marqués comme « non sécurisés »

L'exception change de camp

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

25/07/2018 5 minutes
39

Chrome 68 disponible, les sites sans HTTPS marqués comme « non sécurisés »

Chrome 68 est disponible, et avec lui un changement de comportement attendu depuis longtemps : les sites n’utilisant pas le HTTPS sont marqués comme « non sécurisés ». Le navigateur de Google est l’un des premiers à effectuer cette bascule, prévue par tous les concurrents.

Depuis longtemps, l’internaute peut identifier un site « sécurisé » par le petit cadenas vert situé à gauche de l’adresse du site. Il symbolise la présence d’une connexion HTTPS, signifiant que les données échangées avec le serveur sont chiffrées.

Ce cadenas (ou bouclier selon les navigateurs) a eu des vertus éducatives et devait inciter l’utilisateur à faire confiance. Une condition bien importante pour faire notamment décoller le commerce en ligne. Mais les choses ont bien changé, notamment sous l’impulsion d’initiatives comme Let’s Encrypt (qui a récemment passé la barre des 100 millions de certificats SSL/TLS, avec les dangers que cela comporte).

Maintenant que le HTTPS est utilisé par une grande majorité de sites, les navigateurs placardent depuis plusieurs mois maintenant une alerte pour signaler ceux qui ne le proposent pas quand des données sont sur le point d’être échangées. Deux exemples simples : l’envoi d’identifiants et les achats en ligne.

Il est désormais temps de franchir une nouvelle étape.

Les sites sans HTTPS deviennent « non sécurisés »

Chrome 68 introduit un changement aux vertus éducatives. Les sites avec HTTPS gardent leur cadenas et leur « Sécurisé », mais ceux ne l’ayant pas sont affublés d’un « Non sécurisé » gris. Les internautes vont donc apprendre progressivement ces deux facettes du web, avant d'affronter des changements plus radicaux.

Bon nombre d’internautes ne remarqueront sans doute même pas cette nouveauté. C’est d’ailleurs l’idée : accompagner l’adresse d’une information discrète, mais essentielle. Les utilisateurs n’auront cependant que quelques semaines pour s’y faire avant que Chrome n’aille plus loin.

chrome httpschrome https

Chrome 69 et 70 fermeront la marche

En septembre et octobre, les futures moutures du navigateur termineront ce travail éducatif. Dans un premier temps, Chrome 69 va supprimer l’étiquette « Sécurisé » pour un site possédant HTTPS. Le cadenas restera en place mais perdra sa couleur verte pour un simple gris. De quoi insister encore sur l’idée qu’une connexion chiffrée est la norme.

Environ six semaines plus tard, Chrome 70 viendra accentuer la pression sur les sites sans certificat. Déjà signalés comme non sécurisés, le navigateur colorera son avertissement en rouge dès que l’internaute inscrira des données dans un formulaire.

chrome https

Après ces trois versions successives, Google espère que l’internaute aura compris le message : seuls les sites n’utilisant pas HTTPS seront pointés du doigt. Un changement conséquent et une inversion de philosophie qui devraient concourir à améliorer encore la sécurité générale du web. Car en dépit des efforts réalisés, la marge d’amélioration reste importante.

Selon Google, le trafic via Chrome montre ainsi une utilisation déjà massive de HTTPS, mais avec parfois de gros écarts. Au 21 juillet par exemple, 84 % des sites visités aux États-Unis étaient chargés via HTTPS. En France, le chiffre est presque aussi élevé : 82 %. L’Indonésie, la Turquie et le Japon sont cependant loin derrière, avec respectivement 68, 67 et 66 %.

Un mouvement général

Chrome est le premier à marquer tous les sites sans HTTPS comme non sécurisés. Safari, depuis sa mouture 11.1, affiche bien un message en rouge, mais uniquement pour les pages contenant des formulaires. Chrome 68 généralise son avertissement, bien qu’il faille attendre la version 70 pour l'arrivée du rouge sur les pages à formulaires.

Mais Google a beau être le premier à se jeter dans le grand bassin, les autres suivent ou prévoient de le faire. Côté Firefox, un cadenas barré d’un trait rouge apparait quand une page sans HTTPS propose un champ d’identification. À terme, le navigateur l’affichera pour toutes les pages avec du simple HTTP, mais Mozilla n’a pour l’instant pas de calendrier. Dans le menu about:config, on peut néanmoins forcer cet affichage, via le réglage security.insecure_connection_icon.enabled. Il suffit alors de le basculer en « true ».

Les navigateurs reposant sur la base Chromium vont hériter du changement introduit par Google et devraient donc proposer le même comportement au cours des prochains mois. Quant à Edge, il suit pour l’instant le comportement courant : un cadenas pour les pages HTTPS, rien pour les pages classiques et une étiquette « Non sécurisé » si ces dernières présentent un formulaire. Microsoft n’a pas encore évoqué la suite du programme.

Notez que même si HTTPS n’est pas une protection absolue, il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers. Le changement introduit par Chrome est donc important, et ce d’autant plus qu’il est le navigateur le plus utilisé au monde (environ 59 % selon StatCounter).

Enfin, ceux souhaitant aller un peu plus loin pourront se pencher sur l’extension HTTPS Everywhere de l’EFF, qui s’assure de toujours basculer sur une connexion HTTPS si le serveur contacté l’autorise. Elle est disponible pour Chrome, Firefox et Opera. Le navigateur Brave l'intègre directement.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les sites sans HTTPS deviennent « non sécurisés »

Chrome 69 et 70 fermeront la marche

Un mouvement général

Fermer

Commentaires (39)


Excellente chose pour internet mais problématique pour les appli web en local car même avec un certificat, on a un message d’alerte, le certificat n’étant pas “valide”








mrtoine a écrit :



Excellente chose pour internet mais problématique pour les appli web en local car même avec un certificat, on a un message d’alerte, le certificat n’étant pas “valide”





Suffit de l’ajouter au magasin de certificat de confiance de ta machine, ou si t’es en entreprise, de monter ta propre CA et de déployer son certif avec les stratégies de groupe.



Par contre, quid des certificats EV ? Ce sera toujours indiqué ? Si non, ça va être le bordel, déjà que je prévois les dizaines d’appels de clients “le cadenas s’affiche pluuuuus” … Sont marrant chez Google avec leur lubies, mais c’est toujours les développeurs qui trinquent …



Pour ceux qui, comme moi, auraient un problème de couleurs avec cette mise à jour:

 chrome://flags/#force-color-profile et changez de Default en sRGB


Bientôt un : Site non IPv6 ?


“il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers” Euhh, le HTTPS assure la confidentialité des données mais à quel moment il assure l’intégrité ? J’ai pas souvenirs de signatures ou de contrôles de hash pour les réponse HTTPS…








iFrancois a écrit :



Suffit de l’ajouter au magasin de certificat de confiance de ta machine, ou si t’es en entreprise, de monter ta propre CA et de déployer son certif avec les stratégies de groupe.





Oui mais c’est quand même bien chiant, ils peuvent afficher en rose avec des points bleus on s’en fout, mais y en a marre de devoir à chaque fois qu’on configure un nouveau matos en local valider l’exception pour avoir le droit de le faire. Ilfaudrait au moins qu’on puisse désactiver en local simplement pour ceux qui savent ce qu’ils font.



Ah bah, en soit c’est bien.



 Mais ça va quand même être le foutoir lorsqu’ils vont supprimer le cadenas avec les gens qui vont faire (globalement à juste titre) : ah mais c’est pas sécurisé, y a pas de cadenas, surtout si la concurrence le laisse.








iFrancois a écrit :



Suffit de l’ajouter au magasin de certificat de confiance de ta machine, ou si t’es en entreprise, de monter ta propre CA et de déployer son certif avec les stratégies de groupe.





Méthode valide, mais rajoute de la gestion CA / Deploiement.



Une autre méthode, acheter un certificat Wildcard ( *.maboite.fr ) pour 20 ou 30 euros, et déployer ses applicatifs sur des url de type git.maboite.fr, imputations.maboite.fr, … ). Le fait que le service soit accessible hors du réseau de la boite est une autre problématique.









eureux a écrit :



Le fait que le service soit accessible hors du réseau de la boite est une autre problématique.



Pas forcément, tu peux avoir des versions différentes en intranet et en internet (réglages DNS / Parefeu…)



j’avais 33 raccourcis sur la bookmark bar depuis des années , je n’en vois plus que 30 car il y a un espace de facilement 5mm entre chaque bookmark !

fait ch…

<img data-src=" />








bilbonsacquet a écrit :



Pas forcément, tu peux avoir des versions différentes en intranet et en internet (réglages DNS / Parefeu…)





Oui, mais cela marchera tout de même si tu y mets, sur les 2 versions, le même certificat wildcard à 2030 euros.&nbsp; En fait, cette bascule n’est un soucis que pour les boites suffisamment radine économe pour ne pas dépenser 30 euros.



Ils ne prévoient pas de suppression du cadenas pour l’instant&nbsp;


Je ne suis vraiment pas à l’aise avec le mantra des navigateurs https = sécurisé.

Bordel, la « sécurité » d’un site s’arrete pas à ça… or, ils en font tellement des caisses la dessus que ca en devient l’alpha et l’omega de la sécurité.

Quand on voit comment certains sites sont faits et maintenus, ça fait franchement peur. « Mais c’est pas grave car on est sécurisé avec le cadenas vert »… pff, on est juste en train de tranquillement paver la route pour des vagues de phishing et de vol de pass encore plus intenses qu’on en a jamais connu car la seule chose qui retenait les “phishers” de se faire passer pour des sites “sécurisés” était le cout des certificats. Tout le mantra “https = sécurisé” repose là dessus.

Or, maintenant que ce cout est nul, cette belle incantation vaudou n’a plus aucune valeur (elle n’en avait deja pas beaucoup…)








Vincent_H a écrit :



Ils ne prévoient pas de suppression du cadenas pour l’instant&nbsp;







Ce n’est pourtant pas ce qui est indiqué dans l’image après Chrome 69 et ni dans l’article :







NextINpact a écrit :



Après ces trois versions successives, Google espère que l’internaute aura compris le message : seuls les sites n’utilisant pas HTTPS seront pointés du doigt.










KP2 a écrit :



Je ne suis vraiment pas à l’aise avec le mantra des navigateurs https = sécurisé.

Bordel, la « sécurité » d’un site s’arrete pas à ça… or, ils en font tellement des caisses la dessus que ca en devient l’alpha et l’omega de la sécurité.

Quand on voit comment certains sites sont faits et maintenus, ça fait franchement peur. « Mais c’est pas grave car on est sécurisé avec le cadenas vert »… pff, on est juste en train de tranquillement paver la route pour des vagues de phishing et de vol de pass encore plus intenses qu’on en a jamais connu car la seule chose qui retenait les “phishers” de se faire passer pour des sites “sécurisés” était le cout des certificats. Tout le mantra “https = sécurisé” repose là dessus.

Or, maintenant que ce cout est nul, cette belle incantation vaudou n’a plus aucune valeur (elle n’en avait deja pas beaucoup…)





Je confirme avoir déjà vu des tentatives (heureusement trop grossières) de phishing avec un site en HTTPS et certificat valide (oui oui) donc qui peut dans l’absolu tromper pas mal de personnes …



Au temps pour moi, j’ai lu de travers, et la drogue n’arrange rien








Vincent_H a écrit :



Au temps pour moi, j’ai lu de travers, et la drogue n’arrange rien





Avec le faux-ami “Eventually” (finalement, à la fin), ça peut se comprendre aussi…



La drogue c’est mal, sauf si elle est fabriquée par un grand lobby pharmaceutique <img data-src=" />



Oui on le connait bien celui-là :)








yope7 a écrit :



“il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers” Euhh, le HTTPS assure la confidentialité des données mais à quel moment il assure l’intégrité ? J’ai pas souvenirs de signatures ou de contrôles de hash pour les réponse HTTPS…







bien sûr et heureusement qu’il y a vérification de l’intégrité et c’est via un MAC - Message Authentication Code, qui est bien plus sécurisé qu’un simple hash



https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity



Et pourtant les TLS Records sont bien assurés en intégrité. C’est d’ailleurs bien clair dans les suites de chiffrement utilisées, via usage d’un HMAC : TLS_RSA_WITH_AES_128_CBC_SHA256



Pour les suites de chiffrement récentes, l’usage d’un mécanise AEAD assure la confidentialité, l’intégrité et l’authenticité : https://en.wikipedia.org/wiki/Authenticated_encryption








yope7 a écrit :



“il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers” Euhh, le HTTPS assure la confidentialité des données mais à quel moment il assure l’intégrité ? J’ai pas souvenirs de signatures ou de contrôles de hash pour les réponse HTTPS…







Si, ça va de pair dans tous les protocoles chiffrés (et sérieux).

Par contre, le protocole ne peut pas garantir si les données transférées sont légitimes et bien celles demandées et voulues par l’utilisateur.









roncamma a écrit :



Bientôt un : Site non IPv6 ?







Tellement !









iFrancois a écrit :



Par contre, quid des certificats EV ? Ce sera toujours indiqué ?





&nbsp;Oui, sinon ça ruinerait tout l’intérêt des certifs EV.





yope7 a écrit :



“il reste crucial pour s’assurer – autant que possible – que les données échangées n’ont pas été modifiées par un tiers” Euhh, le HTTPS assure la confidentialité des données mais à quel moment il assure l’intégrité ? J’ai pas souvenirs de signatures ou de contrôles de hash pour les réponse HTTPS…





Bien sur que si, https utilise un système de signature pour garantir l’échange des clé de chiffrement. Tu va avoir du mal a modifier un message chiffré sans la clé sans que ça soit détecté.

&nbsp;





KP2 a écrit :



Je ne suis vraiment pas à l’aise avec le mantra des navigateurs https = sécurisé.

Bordel, la «&nbsp;sécurité&nbsp;» d’un site s’arrete pas à ça… or, ils en font tellement des caisses la dessus que ca en devient l’alpha et l’omega de la sécurité.





&nbsp;&nbsp;Personne n’a dit que le https était le seul problème de sécurité mais s’en ait clairement un, d’autant plus maintenant ou l’on se connecte souvent via des réseau wifi publics.

&nbsp;J’ai pas l’impression que les développeurs de navigateurs en fassent particulièrement plus que sur d’autres points. Mais comme c’est une contrainte supplémentaire pour les développeurs et directement visible pour les utilisateurs, forcément ça fait plus parler.

&nbsp;





KP2 a écrit :



Quand on voit comment certains sites sont faits et maintenus, ça fait franchement peur. «&nbsp;Mais c’est pas grave car on est sécurisé avec le cadenas vert&nbsp;»…



&nbsp;

Justement le cadenas sera moins visible et c’est tant mieux car en effet un élément trompeur.

&nbsp;





&nbsp; KP2 a écrit :



&nbsp;pff, on est juste en train de tranquillement paver la route pour des vagues de phishing et de vol de pass encore plus intenses qu’on en a jamais connu car la seule chose qui retenait les “phishers” de se faire passer pour des sites “sécurisés” était le cout des certificats. Tout le mantra “https = sécurisé” repose là dessus.&nbsp;





Le cadenas seul n’a jamais été un élément probant contre le phishing.

Les phishers n’ont jamais hésité a faire certifier leur site, il y a toujours eu des combines assez facile pour avoir des certificats pas cher et le cout est négligeable par rapport eu bénéfice.

&nbsp;









Uther a écrit :



&nbsp;Le cadenas seul n’a jamais été un élément probant contre le phishing.

Les phishers n’ont jamais hésité a faire certifier leur site, il y a toujours eu des combines assez facile pour avoir des certificats pas cher et le cout est négligeable par rapport eu bénéfice.

&nbsp;







Oui sauf qu’il y a des campagnes de communication qui expliquent que s’il y a le cadenas c’est sécurisé -&gt; les gens pensent qu’il n’y a aucun risque donc ils peuvent faire confiance au site



Ce qui était faux et le sera toujours : il faut sortir de ce mensonge. Et justement, ce que fait Chrome est clairement un pas dans la bonne direction.



Le cadenas seul n’a jamais été une garantie que le site est de confiance. Il est tout a fait logique de rendre moins visible et même de le faire disparaitre a terme. Par contre un site, même si son propriétaire est honnête, peut être détourné par un intermédiaire si la connexion n’est pas chiffrée. c’est donc normal d’afficher un avertissement sur ces connexions.


Ça va, le symbole “i” dans un petit rond, ça fait juste informatif pour le http.



&nbsp;Ils auraient pu vouloir prévoir à terme un symbole plus fort, genre un point d'exclamation ou une croix rouge ou un cadenas rouge ouvert.    





edit : ah mais c’est le cas, j’avais zappé le paragraphe.


Je viens d’avoir un échange de mail avec un fournisseur pro qui m’a envoyé un devis, à valider sur le compte en ligne que j’ai créé, et dans le mail il me donne l’identifiant/pass que j’ai choisi pour le compte. Quand je lui dit que c’est gravissimme (donc mot de passe stocké en clair chez eux), il me répond que c’est pas un soucis, que c’est juste stocké dans leur CRM sécurisé derrière un av et un pare-feu… Heureusement que j’ai un pass bien à part pour ce site, et qu’on paye par virement (pas de paiement en ligne)… Même pas de hash sur le mot de passe… Mes premiers sites en 98 on utilisait md5 (bon dépassé maintenant…)


Merci pour vos retours. C’est juste que ça m’étonnais qu’on parle d’intégrité pour HTTPS car dans la plupart des cours que j’ai eu sur la question on mettait en avant la confidentialité.








Uther a écrit :



Personne n’a dit que le https était le seul problème de sécurité mais s’en ait clairement un, d’autant plus maintenant ou l’on se connecte souvent via des réseau wifi publics.

 J’ai pas l’impression que les développeurs de navigateurs en fassent particulièrement plus que sur d’autres points. Mais comme c’est une contrainte supplémentaire pour les développeurs et directement visible pour les utilisateurs, forcément ça fait plus parler.







Ben quand je vois le b blocage qu’ils font sur les certificats non valides (alors que la connexion HTTPS est tout de même active et sécurisée), ils n’aident pas…

Après, je veux bien entendre que tout ça est complexe pour le grand public mais quand même.

 

 



Uther a écrit :



Justement le cadenas sera moins visible et c’est tant mieux car en effet un élément trompeur.







Clairement…

 

 



Uther a écrit :



Le cadenas seul n’a jamais été un élément probant contre le phishing.

Les phishers n’ont jamais hésité a faire certifier leur site, il y a toujours eu des combines assez facile pour avoir des certificats pas cher et le cout est négligeable par rapport eu bénéfice.







Ben ceux qui utilisaient https avant let’s encrypt étaient très rares… pour pas dire inexistants.

Aujourd’hui, on a le principe “cadenas = sécurisé” qui est imprimé dans le cerveau des gens sauf que, en vrai, le cadenas n’est qu’un tout petit morceau de la chaine de sécurité, qu’ils restent exposés quand même à un sacré paquets de risques et que les tiers de confiance n’existent plus puisqu’ils sont openbar !



Et je suis d’accord pour dire que les navigateurs ne sont pas les seuls à avoir créé cette confusion mais ils étaient clairement en pointe en en faisant, je répète, des caisses sur le sujet. Au point que TOUT LE MONDE se focalise là dessus presqu’à l’exclusion de tout le reste (notamment la sécurité applicative)…

Je pleure des larmes de sang d’entendre les devs de mes clients me dire “c’est secure, on est en https”.









KP2 a écrit :



Ben quand je vois le b blocage qu’ils font sur les certificats non valides (alors que la connexion HTTPS est tout de même active et sécurisée), ils n’aident pas…

Après, je veux bien entendre que tout ça est complexe pour le grand public mais quand même.





&nbsp;&nbsp;Faire le forcing pour abandonner des technos de sécurité que l’on sait complètement trouées ou en voie de l’être me parait le minimum. Je dirais même qu’ils n’en font pas assez. Après bloquer complètement le site peut être trop mais indiquer clairement la connexion comme non sécurisée me semble le minimum.



&nbsp;





KP2 a écrit :



Ben ceux qui utilisaient https avant let’s encrypt étaient très rares… pour pas dire inexistants.



&nbsp;

J’ai l’expérience contraire, quasiment tout les sites de phishing que j’ai eu l’occasion de voir en avaient. Le cadenas donnant une illusion de sécurité aux gens qui n’ont pas une connaissance assez poussée du web. Un certificat de base ca n’a jamais été assez chez pour être dissuasif, même avant l’arrivée de let’s encrypt.







KP2 a écrit :



Et je suis d’accord pour dire que les navigateurs ne sont pas les seuls à avoir créé cette confusion mais ils étaient clairement en pointe en en faisant, je répète, des caisses sur le sujet. Au point que TOUT LE MONDE se focalise là dessus presqu’à l’exclusion de tout le reste (notamment la sécurité applicative)…

Je pleure des larmes de sang d’entendre les devs de mes clients me dire “c’est secure, on est en https”.





Là encore j’ai des retours complètement différents des tiens. Ces dernier temps du coté de nos clients on parle bien plus de XSS que de HTTPS qui est juste une formalité. Et les browser font ce qu’ils peuvent dans le domaine (CORS et autre) mais ça reste avant tout un problème coté serveur.

Râler sur les navigateurs c’est se tromper de sujet.









Daweb a écrit :



Je viens d’avoir un échange de mail avec un fournisseur pro qui m’a envoyé un devis, à valider sur le compte en ligne que j’ai créé, et dans le mail il me donne l’identifiant/pass que j’ai choisi pour le compte. Quand je lui dit que c’est gravissimme (donc mot de passe stocké en clair chez eux), il me répond que c’est pas un soucis, que c’est juste stocké dans leur CRM sécurisé derrière un av et un pare-feu… Heureusement que j’ai un pass bien à part pour ce site, et qu’on paye par virement (pas de paiement en ligne)… Même pas de hash sur le mot de passe… Mes premiers sites en 98 on utilisait md5 (bon dépassé maintenant…)





Il y a une URL sur NI pour signaler tout site qui envoie les mdp en clair après une inscription. Mais je ne m’en rappelle plus 🙄.

@Vincent, si tu pouvais nous éclairer stp <img data-src=" />









Uther a écrit :



Là encore j’ai des retours complètement différents des tiens. Ces dernier temps du coté de nos clients on parle bien plus de XSS que de HTTPS qui est juste une formalité. Et les browser font ce qu’ils peuvent dans le domaine (CORS et autre) mais ça reste avant tout un problème coté serveur.



Râler sur les navigateurs c'est se tromper de sujet.









D’une maniere generale l’ensemble des vulnerabilite du top 10 OWASP, datant de plus de 5 ans ne devrait plus etre trouvees sur n’importe quel site et pourtant c’est pas du tout le cas.



En meme temps quand la securite n’est pas budgetee dans les projets, les devs et les admins sys ne peuvent pas faire des miracles&nbsp;<img data-src=" />



http://motdepasseenclair.fr/ ?

J’avais envie un mail il y a plusieurs mois pour rajouter un site mais j’ai pas eu de retour..


C’est pas forcément aussi binaire. envoyé en clair dans un email != stocké en clair.

J’ai eu bossé sur un site avec des connecteurs vers un crm et un outil pour commerciaux, à l’inscription d’un internaute, on générait un pwd de 8 caractères (lol) et avant de le hasher (en md5 aussi… mais bien après 98 <img data-src=" /> )et de le persister, on envoyait un mail à l’internaute avec le pwd généré.



Ca vaut pas un token avec obligation définir un pwd à la 1ère connexion, mais c’est pas un pwd en clair et sans sel en base non plus ;)


Oui enfin dans ce cas précis, c’est bien le mot de passe choisi par l’utilisateur qui lui a été renvoyé, et pas un mot de passe généré au niveau du serveur, si je comprends bien.



Donc le mot de passe se balade bien en clair quelque part côté fournisseur.


Au renvoi, tout a fait, c’est inadmissible, et à fuir au plus vite.

J’avais compris à la création, auquel cas c’est pas terrible, mais ne présuppose pas qu’il est en clair en BDD pour autant








PtiDidi a écrit :



http://motdepasseenclair.fr/ ?

J’avais envie un mail il y a plusieurs mois pour rajouter un site mais j’ai pas eu de retour..





Exactement ! Merci <img data-src=" />



Pour info le probleme de bookmark bar dont je me plaignais va être réparé

https://bugs.chromium.org/p/chromium/issues/detail?id=848631