Donc en plus d'avoir de mauvaises idées, ils ne sont même pas fichus de les implémenter correctement
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Donc en plus d'avoir de mauvaises idées, ils ne sont même pas fichus de les implémenter correctement
Ce comportement est actuellement paramétrable dans chrome://flags/. Il s'agit de l'option "Omnibox UI Hide Steady-State URL Scheme and Trivial Subdomains".« Au moins, il faut en faire une option modifiable », ajoute un autre. « Cela ne me dérange pas si les [sous-domaines] sont masqués par défaut. Mais s'il vous plaît, il faut avoir une option pour désactiver cela », a-t-il ajouté.
Chrome : après les "www", Google veut aussi supprimer les "file://" de la barre d'adresse de Chrome
Chrome : après les "www", Google veut aussi supprimer les "file://" de la barre d'adresse
pour éliminer toute information inutile dans l'omnibox
Google essaie décidément de supprimer toute information qui serait inutile ou en doublon dans la barre d'adresse URL ou omnibox de son navigateur Chrome. Les efforts allant dans ce sens incluent les notifications sur la sécurité des sites visités par les utilisateurs de Chrome.
En effet, avec Chrome 68, Google a décidé de supprimer les "http://" dans la barre d'adresse en les remplaçant par un libellé "Non sécurisé" à gauche de l'omnibox. Dans Chrome 69, Google a continué dans sa lancée. Le géant de l'internet va supprimer progressivement les "https://" et le libellé "Securisé", estimant que l'icône de verrou à gauche de la barre d'adresse est suffisante pour indiquer aux internautes qu'il s'agit d'un site https.
Toujours dans Chrome 69, de nombreux internautes ont découvert avec surprise que Google n'affiche plus les "www." et les "m." dans les noms de domaine. Autrement dit, si vous tapez par exemple "www.google.com" dans la barre d'adresse, le comportement normalement attendu est que la barre d'adresse affiche "www.google.com", mais c'est plutôt "google.com" qui sera affiché. Et si vous tapez par exemple "m.tumblr.com" pour aller sur la version mobile de Tumblr, Chrome va afficher dans la barre d'adresse "tumblr.com", alors que les deux sites (version mobile et desktop) sont totalement différents en termes de contenu. Google a en effet décidé de masquer les sous-domaines « triviaux » dans la barre d'adresse et considère que "www" et "m." en font partie.
Mais en raison de la controverse soulevée par ces derniers changements, la firme a décidé de restaurer le comportement initial de son navigateur via une mise à jour de Chrome 69. Autrement dit, Chrome 69 va à nouveau afficher les sous-domaines "www" et "m" dans l'omnibox. Mais ce ne sera que de courte durée - du moins pour les "www" - puisqu'ils seront à nouveau supprimés dans la barre d'adresse URL.
Mais ce n'est pas tout. Conformément à son objectif de supprimer tout texte inutile dans la barre d'adresse de Chrome, Google se prépare aussi à supprimer le schéma "file://".
Actuellement, lorsqu'un fichier local est ouvert dans Google Chrome, la barre d'adresse du navigateur affiche une adresse commençant par "file://" contenant le chemin d'accès au fichier local ouvert. Dans Chrome 70 (actuellement en Nightly build), Google a introduit une nouvelle notification "File" qui s'affiche à gauche de la barre d'adresse pour indiquer qu'un fichier local est ouvert dans le navigateur. Et puisque la notification "File" sera disponible dans Chrome 70, il ne sera plus nécessaire de continuer à afficher "file://" dans le navigateur. Google compte donc le supprimer dans la version suivante de son navigateur.
Si un utilisateur clique sur la notification File, selon un rapport de bogue sur le site du projet Chromium, Chrome affichera un message indiquant à l'utilisateur qu'il consulte un fichier local ou partagé. Google annoncera probablement bien d'autres changements allant dans ce sens, comme la suppression des "ftp://" dans la barre d'adresse par exemple. Mais contrairement aux récents changements visant à éliminer les informations inutiles de la barre d'adresse de Chrome, celui qui concerne les adresses de fichiers locaux n'est-il pas pertinent ?
Source : Projet Chromium
Et vous ?
Que pensez-vous de ces changements visant à supprimant toute information inutile de la barre d'adresse Chrome ?
Voir aussi :
Pour résumer, je masque une info pour l'afficher ailleurs... Dans le genre inutile, je demande la père !
je ne "comprends" plus google. je ne comprends pas ou ils vont avec toutes leur modifs de ces derniers mois..
enfin bon maitenant que firefox est au niveau avec leur quantum, meme pour les shaders, je vais desinstaller chrome, plus besoin de ce google sniffer sur mon pc
J'espère au moins qu'ils implémenteront tout ça à la manière de la barre d'adresse de l'explorateur de fichier Windows --> le chemin d'accès est sous forme d'étiquettes successives, on clique dans la barre, il affiche alors le chemin absolu.
Google va-t-il poursuivre en éliminant les '/' dans les adresses et présenter les différentes parties de la requête sous forme de tags successifs ? ^^'
Aiekick --> Si Firefox est plus éthique que Google, il n'est pas tout blanc non plus, pour un navigateur prônant le respect de la vie privée. Il a implémenter des fonctionnalités bien tardivement comparativement à certaines add-on qui l'accompagnait depuis bien des années et pourtant massivement utilisées.
C'est fou de penser qu'une entreprise puisse avoir autant envie de tout réformer et tout contrôler, ça me donne l'impression que si demain "il" décide que le logo d'internet est un chimpanzé avec une carotte dans le derrière, tout le monde sera obligé de s'adapter sans broncher. Franchement, j'ai parfois l'impression que les webmasters et autres acteurs du web vont devoir entrer en résistance.
Bientôt mon clavier va commencer par GOOGLE au lieu de AZERTY ^^
Ca commence sérieusement à me taper sur les nerfs que Google est là pour tout changer ce qui existe dans la barre d'adresse.
Déjà que c'est parfois galère pour voir si c'est HTTPS ou pas...
Leur Chrome ils peuvent se le mettre où je pense si ça continue.
Chrome 76 : Google poursuit avec le masquage de www dans la barre d’adresse, fournit un plugin anti polémique
Chrome 76 : Google poursuit avec le masquage de www dans la barre d’adresse
Et fournit un plugin pour afficher l'URL en entier
Chrome 76 est disponible depuis peu avec Flash bloqué par défaut, un mode incognito non détecté par les sites web et des améliorations pour les applications web progressives et le mode sombre. Après son installation, si vous avez l’impression qu’il manque quelque chose à la barre d’adresse votre coup d’œil ne vous aura pas trompé. Il y a des changements dans la façon dont le navigateur affiche les adresses URL depuis la version 68. De façon brossée, Google a décidé de retirer toutes les informations « inutiles » de la barre d’adresse via une série de masquages.
Avec Chrome 68, la firme de Mountain View a décidé de masquer les "http://" dans la barre d'adresse et les remplacer par un libellé "Non sécurisé" à gauche de cette dernière. Dans Chrome 69, Google a poursuivi sur sa lancée de supprimer les sous-domaines dits « triviaux » de l’affichage par défaut de l’adresse URL. C’est ainsi que les sous-domaines "www" et "m" sont venus allonger la liste. Comme le souligne Emily Schechter sur la liste de diffusion de bogues du projet Chromium, Google a dû revenir sur cette dernière en raison des plaintes de nombreux utilisateurs, mais avait promis de proposer une version ajustée à partir de la version 70 du navigateur. Avec la sortie de la version 76, elle revient sur la scène et apporte des précisions sur les modifications opérées. Ce qu’il faut retenir est que : primo, Google poursuit avec le masquage du sous-domaine "www" depuis Chrome 70. Deuxio, le sous-domaine "m" ne fait plus l’objet de masquage depuis la version 70 du navigateur ; d’après Google, cette décision est motivée par ceci que de nombreux sites ont leur sous-domaine "m" contrôlé par un utilisateur. Enfin, les indicateurs de protocole "https : //" et "http: //" font l’objet de marquage ; le cas "ftp : //" par contre semble toujours à l’étude.
Donc lorsqu’un utilisateur tape "www.google.com" dans la barre d’adresse, le comportement normalement attendu est que "www.google.com" soit affiché, mais c'est plutôt "google.com" qui l’est. Emily Schechter, explique que la manœuvre est destinée à rendre les URL plus aisées à lire et à comprendre. Un visuel avec le contenu qui suit :
Certes, il est possible de visualiser l’URL complète en effectuant un double-clic sur la barre d’adresse, mais de nombreux utilisateurs sont d’avis que cette décision de Google, au-delà de semer la confusion, pose des problèmes d’usabilité et même de sécurité.
« Pourquoi faut-il cliquer deux fois sur la barre d'adresse pour afficher l'URL complète ? Le premier clic devrait permettre d'y parvenir sinon la manœuvre imposée est tout simplement maladroite et contre nature. Si l'utilisateur veut placer le curseur sur une partie de l'URL, il lui faut deux clics. Au second clic, le curseur va soudainement sauter vers la droite car "https" et "www" vont intégrer la chaîne de caractères, ce qui n'est pas un comportement naturel », note l’un de ceux-ci.
« Comment pouvez-vous traiter le "www" comme un cas spécial ? Ça n’en est pas un. Il s’agit d’une information précieuse et qui s’avère souvent être critique. De plus, "www.example.com" et "example.com" ne renvoient pas forcément à la même page », ajoute un autre.
Puisque Edge est désormais basé sur Chromium, il peut y avoir un certain intérêt à savoir quel est le positionnement de Microsoft à l’égard des développements en cours. Sauf changement de dernière minute, on ne s’est pas aligné du côté de la firme de Redmond. Microsoft Edge continue bien d’afficher https : // et www dans le nom de domaine.
L’annonce de Google laisse filtrer qu’il y a un moyen d’empêcher que l’URL ne soit tronquée. Emily Schechter explique qu’il suffit d’installer l’extension Suspicious Site Reporter.
Un autre moyen est de désactiver le drapeau omnibox-ui-hide-steady-state-url-scheme-and-subdomains.
Source : Liste de diffusion de bogue Chromium
Et vous ?
Voir aussi :
L'extension proposée semble fonctionner très bien, merci.
Ca fait 20 ans que le grand public navigue sur le web.
Et maintenant il est infantilisé, parce que www ça serait trop dur à comprendre ? je trouve cela ridicule au niveau argumentaire.
Et au niveau sécurité c'est mauvais. L'url affichée n'est donc plus la bonne, risques de confusion.
C'est une tendance générale de Microsoft, Google et Apple : cacher la technologie aux gens.
Enlever les messages d'erreur parce que c'est anxiogène, les barres de chargement parce que c'est effrayant, les url parce que c'est moche, enlever les touches F1, F2, F3 etc...
Et ce n'est pas prêt de changer. Il y avait un article à ce sujet que les URL « doivent disparaitre ». En plus, avec l'apogée de site web “single page” ça ne va qu'empirer. Bientôt un site web sera similaire à une application. On s'éloigne de plus en plus des principes fondamentaux du web qui est de faire une page une responsabilité/ressource. Maintenant, tout est JS côté client avec uniquement de l'asynchrone page unique.Envoyé par bk417
Pour le coup je trouve l'approche de Mozilla (qui consiste à afficher l'URL en gris sauf le domaine en noir dans Firefox) plus pertinente. Là au moins, on voit le domaine du premier coup d'œil sans masquer le reste.
Google Chrome met fin à son projet visant à masquer les URL de la barre d'adresse, du moins pour l'instant
Google Chrome met fin à son projet visant à masquer les URL de la barre d'adresse, du moins pour l'instant.
Il s'avère que le fait de masquer les informations d'URL n'aide pas à améliorer sensiblement la sécurité
Chrome met fin à sa guerre contre les URL de la barre d'adresse, du moins pour le moment. Il y a environ un an, Chrome a commencé à expérimenter la suppression de l'URL affichée dans la barre d'adresse au seul nom de domaine, donc au lieu de quelque chose comme « https://www.developpez.com/actu/3060...communication/ », la barre d'adresse n'afficherait que « developpez.com » et vous n'auriez aucune idée de l'endroit où vous vous trouvez dans le répertoire du site.
Début 2014, Google semblait vouloir apporter une modification au comportement de son Omnibox, la barre d’adresse qui peut être utilisée à la fois pour effectuer des recherches sur le web (le moteur de recherche par défaut étant paramétrable) ou entrer une URL. Dans la version de Chrome Canary build 36, il était possible d'activer une option permettant de masquer l'URL complète d'un site consulté. Lorsque l'internaute naviguait au sein des différentes rubriques d'un site, seul le nom de celui-ci s'affichait dans la barre d'adresse. Dans cette mouture, pour accéder à la totalité de l'URL, il suffisait de cliquer le bouton « Origin Chip » sur le nom de domaine. Pour avoir accès à cette option, il était nécessaire d’activer le flag « Enable origin chip in the Omnibox » depuis chrome://flags.
L’un des objectifs derrière cette manœuvre était de fournir un rempart face aux attaques phishing, une technique utilisée par des fraudeurs pour obtenir des renseignements personnels dans le but de perpétrer une usurpation d'identité. L’une des clés du succès de ses attaques réside dans le fait de persuader sa victime qu’elle s’adresse à un site de confiance pour lui soutirer en douce ses renseignements personnels (numéro de carte de crédit, date de naissance, pseudo/MDP …). Avec des URL à rallonge, le navigateur peut tromper l'internaute et ainsi faciliter les tentatives de phishing de sites malveillants.
Mais plusieurs personnes n’ont pas manqué de faire entendre leur voix sur le sujet. Les avis étaient plutôt partagés, même au sein de l’équipe Chrome. Par exemple, Paul Irish a déclaré « J’imagine que cela aidera à défendre contre le hameçonnage » avant de rajouter « mon opinion personnelle est que c’est un très mauvais changement qui représente l’antithèse des objectifs de Chrome. »
Jake Archibald, un développeur Chrome, a soutenu la fonctionnalité : « trouvez quelqu’un qui ne travaille pas dans un domaine technologique, montrez-lui le site de sa banque, et demandez-lui ce que lui apprend l’URL. Mon expérience m’enseigne que la plupart des utilisateurs ne savent pas quelles parties de l’URL sont les signaux de sécurité. » Par la suite il a affirmé que « les navigateurs ont arrêté d’afficher les pseudonymes/MDP dans les URL parce que ça facilitait le hameçonnage. C’est une progression naturelle .»
La communauté developpez.com s’est également exprimée sur le sujet. Sodium par exemple a estimé que ce n’était pas la bonne approche : « Infantiliser les utilisateurs ne me semble jamais être une bonne chose. C'est parce qu'ils ne comprennent pas l'informatique qu'ils se font avoir par des tentatives de fraude souvent grossières. Moins ils comprendront ce qu'il se passe derrière leur machine, plus il y aura de risques de tomber dans les pièges d'Internet ». Même son de cloche pour mrqs2crbs qui a noté : « je crois surtout qu'il faut apprendre aux utilisateurs à lire correctement. Parce que, juste dire : "ça va vous protéger, vous n'aurez besoin de rien connaître", ça sonne surtout comme une grosse embrouille ».
Pour sizvix, cela pouvait cacher une stratégie de Google : « Éloigner encore un peu plus les utilisateurs des URL pour les rapprocher du moteur de recherche bien sûr »
Vanquish note : « IE affiche déjà la partie la plus significative de l'URL en noir, alors que le reste est en gris. Ça va un peu dans le même sens. Il faut voir la réalisation. Si en cliquant sur un bouton j'ai accès et peux modifier l'URL complète (c'est parfois utile), ça me va. Car pour l'utilisateur lambda, je partage le point de vue sur la complexité des URL : combien d’utilisateurs ne font pas la différence entre la zone d'URL et le champ de recherche de la page Google qui leur sert de homepage ».
Bon gré mal gré, Google a mis son projet au placard, notamment après le tollé que cela a provoqué en plus de la découverte de faiblesses dans la fonctionnalité « Origin Chip » par PhishMe, entreprise spécialisée dans les programmes de tests d’attaques de phishing, après seulement quelques tests.
Pourtant, quelques années plus tard, en 2020, l’entreprise est revenue de plus belle avec son projet. Quelques indicateurs de fonctionnalité sont apparus dans les canaux Dev et Canary de Chrome (V85), qui modifient l'apparence et le comportement des adresses Web dans la barre d'adresse. L'indicateur principal est appelé « Omnibox UI Hide Steady-State URL Path, Query, and Ref » qui masque tout dans l'adresse Web actuelle, à l'exception du nom de domaine.
La marche arrière (temporaire ?) de Google
Dans un billet sur le traceur de bogues Chromium, l'éditeur de Chrome a annoncé qu'il renonçait à cette idée. En juin 2020, au début de l'expérience, l'ingénieur de Google Emily Stark a expliqué que la société expérimentait un affichage d'URL simplifié « pour comprendre si cela aidait les utilisateurs à identifier les sites Web malveillants avec plus de précision ». C'est un an plus tard que Stark a indiqué que « l'expérience de domaine simplifiée » sera supprimée de la base de code, en expliquant que « cette expérience n'a pas apporté les métriques de sécurité pertinentes, nous n'allons donc pas la lancer. »
Le navigateur Safari d'Apple masque également les URL de ce type.
L'équipe Chrome n'a pas peur de faire exploser les normes Web existantes et a déclaré publiquement qu'elle voulait supprimer l'URL. Elle n'a tout simplement pas encore trouvé comment. Il ne serait donc pas surprenant de voir Google revenir à la charge.
Aujourd'hui, Chrome ne masque que le "https://" au début de l'URL, mais vous pouvez le désactiver sur les ordinateurs de bureau en cliquant avec le bouton droit sur la barre d'adresse et en cochant « toujours afficher les URL complètes ».
Source : Chromium
Et vous ?
Voir aussi :
Contre, bien entendu. Ça n'apporte rien à part de la confusion.
Tiens d'ailleurs ça me fait penser à une attaque de phishing qui marchait début 2000 en utilisant un bug d'une vieille version de IE, qui n'affichait pas les URL complètes s'il y avait certains caractères. Du coup avec l'idée de Google, on se retrouverait dans la même situation mais intentionnellement! C'est plutôt cocasse.
Plutôt, oui. Un an pour faire marche arrière sur une idée aussi stupide et pour arriver à une conclusion aussi évidente quand on est un géant du web, c'est trop.
Je ne comprends pas quelle information apporte à un utilisateur standard les parties chemin et paramètres de l'URL (après le nom du site).Contre, bien entendu. Ça n'apporte rien à part de la confusion.Êtes-vous pour ou contre le fait de masquer les URL de la barre d'adresse ?
Je parle pas des informaticiens qui peuvent comprendre profondément cette information et qui s'amuseront à forger des URLs — ce que je fais moi-même assez souvent. Mais je parle bien de la plupart des utilisateurs, comme ma mère, la secrétaire, l'adolescent du quartier, madame Michu ou quelque autre utilisateur non-informaticien.
Pour ces utilisateurs non-informaticiens, quel est l'intérêt de leur montrer cette information ?
Une idée de marketteux à la con qui aura quand même mis quatre ans à être dégagée.
Si madame Michu ne veut pas voir l'url, elle peut la supprimer. A la limite un popup de demande lors de la première utilisation suffirait.
C'est là tout le danger de Chrome et de Google.L'équipe Chrome n'a pas peur de faire exploser les normes Web existantes
On commence déjà à voir des outils utilisables exclusivement sur Chrome (officiellement), alors qu'ils fonctionnent tout aussi bien sous Firefox si on change le user-agent.
3615 Google
Ne pouvant plus copier/coller les urls pour transmettre à quelqu'un ceci oblige à passer par le moteur de recherche g$$gle (je pense leur intention ultime est de réinventer le minitel)
[Hors-sujet]
Madame Michu, le Michou le plus célèbre est un directeur de cabaret français...
[/Hors-sujet]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager