Google Chrome: Omnibox versteckt fortan wieder Teile von Adressen
von Benjamin Mamerow | 39 Kommentare
Es ist nicht das erste Mal, dass Google bei seinem Browser Chrome mit der Omnibox umher experimentiert und dabei wichtige Teile einer Adresse, wie das „www“ oder das „https://“ einfach optisch entfernt. Zuletzt musste das Unternehmen im vergangenen Jahr wieder einlenken, nachdem sich zahlreiche Nutzer beschwerten und unter anderem die zukünftige Sicherheit im Netz als Grund mit anbrachten.
Wie nun aber Emily Schechter von Google erläutert, ist die Omnibox mit Chrome 76 wieder zu jenem Stand zurückgekehrt und blendet fortan wieder das www und https aus. Nur den Zusatz „m“, den man bei mobil angepassten Webseiten vorfindet, will man weiterhin einblenden. Jenes Modell der Omnibox habe man nun über die letzten Monate ausgiebig getestet und sei sich daher mehr als sicher, dass dieser Standard nun auch für die Stable von Chrome 76 geeignet ist.
Doch natürlich gibt es Lösungsansätze, wenn man sich partout nicht an die neue Darstellung gewöhnen mag. So reicht ein Doppelklick/einfaches Antippen der Adresszeile aus, um die vollständige Adresse anzuzeigen. Außerdem weist Google auch auf die Chrome-Erweiterung „Suspicious Site Reporter“ hin, mit deren Hilfe Power-User verdächtige Seiten melden können, da die Erweiterung unter anderem die vollständige Adresse einblendet.
Emily Schechter im Bug-Tracker von Chromium:
Hi all,
The Chrome team values the simplicity, usability, and security of UI surfaces. To make URLs easier to read and understand, and to remove distractions from the registrable domain, we will hide URL components that are irrelevant to most Chrome users. We plan to hide “https” scheme and special-case subdomain “www” in Chrome omnibox on desktop and Android in M76.
In Sept 2018, we rolled out a change to hide special-case subdomains “www” and “m”. Per my above message on this thread, we rolled back these changes, and announced our intent to re-ship an adjusted version: we will hide “www” but not “m”. For several months, we’ve had this version enabled in our Canary, Dev and Beta channels and are confident that it is ready to be enabled in the Stable channel as well.
We’ve worked with other browser representatives to incorporate URL display guidance into the web URL standard (https://url.spec.whatwg.org/#url-rendering-simplification). The URL spec documents that browsers may simplify the URL by omitting irrelevant subdomains and schemes in security-sensitive surfaces like the omnibox.
We’ve also worked to build a Chrome extension (https://security.googleblog.com/2019/06/new-chrome-protections-from-deception.html) to help power users recognize suspicious sites and report them to Safe Browsing. Power users can use this extension to display the full URL with no scheme or subdomain hiding, and report suspicious sites to Safe Browsing if they choose. The full URL is also revealed by clicking twice in the URL bar on desktop, and once on mobile.
I’ve cross-posted this message in this bug and on security-dev + chromium-dev for continuity.
Wird geladen ...
Aktuell läßt sich das noch beheben, in dem man unter chrome://flags/ sowohl Omnibox UI Hide Steady-State URL Scheme und Omnibox UI Hide Steady-State URL Trivial Subdomains auf disabled setzt.
Das sind die oberen beiden, wenn man in der Suche omnibox eingibt.
Unter Canary habe ich auch noch „Omnibox UI Hide Steady-State URL Path, Query, and Ref“ disabled (In the omnibox, hide the path, query and ref from steady state displayed URLs. Hidden portions are restored during editing)
Hoffen wir, daß sie wieder einen Rückzieher mach wie letztes Mal.
Naja, vermutlich schränkt Google die technische Universalität der Adresszeile ihres Browsers ein damit mehr Leute auf Dienstleistungen zur Websuche angewiesen sind. …denn wir erinnern uns: Google ist ein Quasimonopolist in der Websuche.
Klar, für sich genommen sind all diese Abwandlungen leicht auf die klassischen Adresskomponenten rückführbar. Das heißt nicht, dass es längerfristig nicht doch funktioniert.
Technische Universalität einer Adresszeile? Was für ein Schwachsinn…
Was bringt dir persönlich das Verstecken von URL-Bestandteilen?
Und wie suchst du nach einer bestimmten Domain auf einem anderen Gerät? In dem du die Google-Suche aufrufst oder in dem du die URL eintippst? Ersteres will Google gerne haben – sie schlagen in ihren Suchvorschlägen auch nie komplette URLs vor, sondern nur einen Domainnamen ohne TLD, damit man die Suche aufrufen muss.
Das Verstecken von URL-Bestandteilen finde ich persönlich Schwachsinn. Ich habe schon genügend Erfahrungen mit Nutzern von Safari, die auch die keinen rechten Überblick mehr haben, auf welcher (Sub-)Domain sie gerade unterwegs sind.
Ich war zwar nicht gemeint, aber ich antworte trotzdem einmal:
> Was bringt dir persönlich das Verstecken von URL-Bestandteilen?
Ich finde es übersichtlicher. Ob „https“ oder „http“ ist an der restlichen Anzeige einfacher und ich behaupte für den Laien auch deutlich verständlicher zu erkennen.
„www“ finde ich einfach unnötig, ich benutze keine Seite die mit und ohne www anderes liefert, und wenn doch würde ich dem Betreiber auf den Kopf steigen, nicht Google. Aus technischer Sicht ist „www“ manchmal notwenig, aber praktisch nie interessant für den Benutzer.
> sie schlagen in ihren Suchvorschlägen auch nie komplette URLs vor, sondern nur einen Domainnamen ohne TLD, damit man die Suche aufrufen muss
Relevanz zum Thema? Google hat nicht vor in Chrome die TLDs auszublenden.
> Ich habe schon genügend Erfahrungen mit Nutzern von Safari, die auch die keinen rechten Überblick mehr haben, auf welcher (Sub-)Domain sie gerade unterwegs sind.
Aber das sicher nicht, weil http(s) und www ausgeblendet werden. Wenn überhaupt macht Safari es am einfachsten, zu erkennen auf welcher (Sub-)Domain abzüglich „www“ man ist. In der Adresszeile steht nämlich exakt nur diese Subdomain und nichts anderes. Da gibt es absolut keinen Interpretationsspielraum und der Laie muss auch kein Verständnis dafür haben, was zum Hostnamen und Pfad gehört, und was „https“ vorne überhaupt heißen soll. Steht da oben nicht exakt „meine.postbank.de“, ist der Benutzer auf der falschen Seite.
Nächste Woche in der Agentur…:
Wir arbeiten am Relaunch der Site „beispiel.foo“. Die Entwicklung läuft bereits auf dem zukünftigen Produktivsystem, der Livegang erfolgt dann lediglich durch DNS-Umschaltung. Zur Entwicklungszeit ist das System einstweilen auch erreichbar unter „www.beipiel.unsere-agentur.foo“ und „beipiel.unsere-agentur.foo“.
Telefon klingelt. Kunde dran. Site nicht erreichbar. Welche Adresse er denn verwende? „beipiel.unsere-agentur.foo“. Hm. OK. Geht bei uns. Untersuchung der Authentifikation (Rest der Welt darf Site noch nicht sehen), der Route (Wir, Kunde, GItlab und das System für automatisierte Userakzeptanztests sollen ohne Passwort draufkommen) — Route stimmt. DNS wird geprüft — alles sauber. Zwei Leute beim Hoster suchen nach dem Problem — kein Problem. Unterstützt durch zwei Leute von uns — auch kein Problem. Zwei Stunden Arbeit für 4 Leute a 200 EUR pro Stunde. Fazit: „Ach, warte, wenn ich draufdrücke, steht auch noch www davor!“. Am Arsch! Wir reden die ganze Zeit über die falsche Subdomain!?
Mein Auto braucht kein Getriebe, das würde die Fahrer nur verwirren.
Es wird nur das Protokoll und „www“ ausgeblendet. Wärst du so freundlich zu erklären, wie dadurch mehr Leute auf Dienstleistungen zur Websuche angewiesen sein sollten?
Und wie sieht das dann eigentlich bei Apple aus? Mein Safari zeigt gerade nur „stadt-bremerhaven.de“ an, also nochmal deutlich weniger als Chrome in Zukunft. Stecken die mit Google unter einer Decke? Oder einfach nur ein blöder Kommentar ohne inhaltliche Relevanz?
Prinzipiell hat die Websuche sehr viel Wettbewerb. Der Umstand, dass google quasi „der Standard“ ist liegt schlicht daran, dass die Suche – mit großem Abstand – für die meisten Nutzer die besten Ergebnisse produziert.
Ich habe es immer mal wieder mit bing und Co versucht, bin dann aber recht schnell wieder bei google gelandet da die Qualität der Suchergebnisse beim Wettbewerb schlicht schlechter ist.
Zumindest technisch etwas versierteren Benutzern gibt die Adressleiste, der Aufbau und eventuelle Subdomains durchaus wichtige Informationen an die Hand.
Ein technisch versierter Nutzer kann eventuell in die Adresszeile klicken, sich die Flags setzen oder ein Plugin nutzen. Das Argument der Unsicherheit lasse ich ja gelten, nur das scheint hier niemand zu bemerken 😉
Klar „kann“ man das machen. Es ist aber wieder ein zusätzlicher Aufwand, den man sich in der normalen Einstellung sparen kann.
Ich habe meinen Chrome an allen Geräten so konfiguriert, dass er mir brav weiterhin die volle URL anzeigt.
Mir ist das ehrlich gesagt relativ egal, ob da nun HTTPS davor steht oder nicht. Auch ohne das Anzeigen von HTTPS sehe ich doch ob ein Schloss angezeigt wird oder nicht. Ich sehe da ehrlich gesagt keinen Vor- oder Nachteil.
Ich habe vor etwas über einem Jahr wieder zurück zu Firefox migriert.
Die ständige Bevormundung von Google nervt, ich hakte diese Aktion für extrem gefährlich da man ohne wirklich triftigen Grund dem User Informationen vorenthält.
Es wird Zeit wieder ein Gegengewicht im Browsermarkt aufzubauen.
Für HTTPS Seiten wird doch ein Schloss angezeigt. Welche Info fehlt dann noch?
Auf die Gefahr hin, dass das offensichtlich ist: Das https:// in der Adresse fehlt.
…davon abgesehen ist auf „die Bevormundung nervt“ mit „Was sähest du denn gerne an der vom Vormund erzwungenen Lösung geändert?“ zu antworten inhaltlich off-topic.
Klar fehlt das „https://:“. Aber es wird ein Schloss angezeigt. Und wenn die Seite nicht sicher ist, wird sie auch noch ROT eingefärbt.
Und zum Thema Bevormundung…. klar, aber du musst dich mehr oder weniger bei jedem Browser mit den Voreinstellungen des Herstellers arrangieren. Da musst du eben den Browser aussuchen, der deinen Vorlieben am nächsten kommt. Gibt ja genügend Auswahl.
Welche Informationen werden dir denn Vorenthalten?
Es ist gut, dass es Firefox gibt. Aber leider hinkt dieser bei der Performance und auch der Benutzerfreundlichkeit (besonders wenn man google Dienste nutzt) immer noch Chrome hinterher.
Schon mal daran gedacht, dass Google gewisse Tricks verwendet, um Nutzer zu Chrome zu zwingen? Sie bauen in die eigene Javascript-Engine Dinge ein, die die Konkurrenz nicht hat und verwenden gezielt in den eigenen Diensten solche Funktionen oder Funktionsaufrufe.
Teilweise gibt es künstliche Schranken die selbst mit Chromium-basierten Browsern Probleme machen. Da können die anderen Browserhersteller leider nur versuchen die Funktionalität per Reverse-Engineering nachzubauen. Man kann diese Probleme nicht dem Firefox anhängen.
Nebenbei: Die Diskussion um die FF-Performance taucht immer wieder im Netz auf. Aus meiner praktischen Parallelnutzung mehrerer Browser sehe ich keine Performancenachteile bei FF. Es scheint auch in diversen Benchmarks keinen Nachweis dafür zu geben.
Das Problem betrifft eine kleine Anzahl von Webseiten die unter http(s)://domain.ch etwas anders anzeigen als unter http(s)://www.domain.ch
Aber ansonsten braucht die Info von www. oder http wirklich niemand. Das eine Webseite über das http Protokoll aufgerufen wird weiss man so oder so (oder es interessiert niemand). Und www. War schon immer eine unnötige Subdomain.
Aber was genau bringt es dir, wenn diese Informationen versteckt werden? Ich sehe bisher keinen Vorteil. Ich bin mir sicher, dass Betrüger in Kürze Wege finden werden, über solche Automatiken Nutzer auf falsche Seiten zu locken. Als Webentwickler achte ich aber auch mehr darauf, wo genau ich lande.
Und natürlich ist es auch eine Bevormundung von Seitens Google, wenn z.B. https als unsicher markiert wird. Viele Nutzer verstehen die Hintergründe nicht und sind verunsichert, wenn sie eine solche Seite nutzen. Ohne Formular und ohne Inhalte, die als vertraulich einzustufen sind, sehe ich keinen wirklichen Grund, warum http unsicher sein soll.
Ich unterstelle Google, dass sie kein Interesse haben, dass Menschen durch direkte URL-Eingabe auf eine Seite kommen. In den Suchvorschlägen findet man auch nie eine komplette URL zum Anklicken. Darum sollen die Nutzer jetzt auch die URL nicht mehr komplett sehen. Du siehst bei den Safari-Nutzern, dass viele Nutzer nicht wissen, dass man mit einem Klick in die Adresszeile mehr zu sehen bekommt. Google hat natürlich ein großes Interesse, dass man nur über die Suche navigiert. Jeder Direktaufruf bringt ihnen kein Geld mehr.
Die Web-Entwickler treffen sich ich bin auch einer. Und klar als Web-Entwickler will ich beim Entwickeln auch die vollständige URL sehen.
Die http/https „Bevormundung“ kam ja nicht nur von Google – auch Mozilla hat das gefördert. Das eine Seite ohne Formular und ohne vertraulichen Inhalte kein https brauchen kann man so sehen. Muss man aber nicht, bei https geht es ja nicht nur darum das die Inhalte auf dem Transportweg verschlüsselt werden – sondern auch darum, dass keine Inhalte verändert werden (Man-in-the-Middle).
Ich kann also sicher sein, dass die Webseite so auf meinem Engerät angekommen ist, wie sie der Webserver losgeschickt hat. Ausserdem bietet https ja gerade den Vorteil das http 2.0 Protokoll zu nutzen – dadurch wird eine Webseite schneller ohne das du als Web-Entwickler was ändern musst – ist doch super!
Gerade Sicherheitstechnisch finde ich das ausblenden von nicht relevanten Inhalten eigentlich besser. Bei Pishing zum Beispiel. Ich muss den Menschen nur erklären das dort oben „meinebank.ch“ stehen muss.
Bei einem Pishing hat man ja oft solche Dinge wie „meinebank.ch.vollboeserserverextrasuperlange.domain.usw.to“ oder sowas und die Menschen werfen einen Blick nach oben – sehen das dort „meinebank.ch“ steht lesen den Rest dahinter nicht und denken sie sind am richtigen Ort.
Mit der neuen Anzeige würde dort nur noch „usw.to“ stehen und jedem ist klar, dass er am falschen Ort ist.
Daher ich sehe hier die Problematik nicht so. Liegt vielleicht auch daran, dass ich Privat Safari als Browser nutzt (nicht zum entwickeln, dafür taugt er nicht aber einfach zum surfen) und dort ist das schon lange so und hat mich auch nie gestört.
> Ohne Formular und ohne Inhalte, die als vertraulich
> einzustufen sind, sehe ich keinen wirklichen Grund,
> warum http unsicher sein soll.
Habe ich auch immer gedacht. Es gibt genau ein Argument, dass mich überzeugt hat:
Weil https garantiert, dass beim Benutzer genau das ankommt, was der Server geantwortet hat. Wenn ich deinen Router hacke, kann ich eine Malware in jede http-Seite einfügen, nicht aber über https.
Eben und da ist und bleibt Firefox nun mal eben der beste.
Das ist wirklich eine absolute Unsitte von Google. Zum Glück kann man dieses Verhalten noch über die Einstellungen korrigieren.
Das ganze ist eine Katastrophe, und die Kommentare hier dazu sind in ihrer Ignoranz erschreckend.
Es gibt zwei Sorten Leute: Die, denen die URL egal sein kann, weil sie grad auf Facebook Kochrezepte suchen und sehen, dass sie richtig sind. Und dann die andere Sorte von Leute, die MACHEN irgendwas im Netz. Und da liegt zwischen http und https ebenso ein weltbewegender Unterschied wie zwischen mit-und-ohne-WWW. Wen will Google hier bedienen? Den einen bringt es nichts, den anderen schadet es gewaltig.
Firefox ist da nicht besser. Mit ihren Plänen, den System-DNS zugunsten eigener gefrickelten Lösung komplett zu umgehen tut sich hier dasselbe Problem auf: Bitte lasst eure unegalen Pfoten von System-Interna.
Wenn ihr eine hübsche Designleistung für nicht-technische Nutzer erbringen wollt, dann gebt ihnen einfach die Möglichkeit, die URL gar nicht anzuzeigen — die wissen sowieso nix anzufangen mit Phishing-URLs wie http://www.facebook.com@myuserprofile.foo — aber falsch anzeigen ist eine Katastrophe für alle Webworker.
Du begreifst schon das du dir das alles brav anzeigen lassen kannst? Safari versteckt auch schon seid ewig und drei Tagen subdomains, da stört es keinen. Das jetzt wieder den selbsternannten UX Profis und Möchtegern Security-Experten auf Heise und co. das Messer in der Hose aufgeht war natürlich klar, aber im Gegensatz zum letzten mal ist es eher ein Taschenmesser. Ich weiß nicht was ein Webworker ist, klär mich mal auf.
Und was soll der Scheiss? Warum sollte man etwas FALSCH anzeigen und dann eine versteckte Konfigurationsoption haben, die es dann wieder richtig anzeigt? Wer hat denn was davon?
Und das Resultat ist, dass dann alle Vollhonks rumlaufen und erzählen, mit und ohne www ist das gleiche. Steht ja da oben. Und mit dem nächsten Redesign das Browser fliegt die Option dann eh raus, „hat ja kaum jemand benutzt“.
Webworker sind Leute, die beruflich „was mit Web“ machen und darauf angewiesen sind, dass ihnen ein Protokoll, ein Port etc. richtig angezeigt werden.
Safari ist übrigens der größte Drecksbrowser überhaupt — google mal „safari is the new ie“. Wenn Apple das Ding nicht seinen iOS-Usern in den Rachen schieben würde wäre das Ding längst weg, siehe Safari für Windows. Sobald die User die Wahl haben, z.B. auf dem Mac, wird das Ding ersetzt.
Subdomain: es macht nicht den geringsten Unterschied ob da jetzt www vor der Domain steht oder nicht. www ist sowieso überholt und war höchstes in Anfangstagen des World Wide Web relevant, als andere Protokolle noch mehr genutzt wurden. Heutzutage will man in 99.99% der Fälle mit nem Browser auf den HTTP-Server um die Website zu betrachten. So genau hat das eh niemand genommen. Da gibt’s dann bei manchen Hostern so Stilblüten wie ftp://ftp.www.meinserver.de.
Schema: bei HTTPS ist da ein Schloss, bei HTTP kommt gleich die Meldung dass die Verbindung nicht sicher ist.
Ausserdem kann man so die Leute darauf trainieren mal genau hinzuschauen.
„google.de/…“ ist sofort für Laien erkennbar, „https://www.google.de–hacker.ru/…“ eher nicht. Mit der Änderung sieht der Laie dann direkt „de–hacker.ru/…“
Kleine Korrekturen, die inhaltlich deinem Kommentar aber keinen Abbruch tun:
> Mit der Änderung sieht der Laie dann direkt „de–hacker.ru/…“
„google.de-hacker.ru/…“ würde der Laie sehen, nur die „www“ Subdomain wird ja ausgeblendet. Aber der Host wird ja eh farblich anders dargestellt, ein Laie sollte hier hoffentlich also trotzdem schneller eine Unstimmigkeit sehen.
> www ist sowieso überholt und war höchstes in Anfangstagen des World Wide Web relevant
„www“ hat durchaus noch seine Daseinsberechtigung, aber nur aus technischer Sicht. Für den Benutzer – egal ob Laie oder nicht – ist sie in fast allen Fällen irrelevant. Die Seiten, die mit und ohne www unterschiedliches anzeigen, haben auch vorher schon „gefährlich“ gelebt. Der technische Hintergrund ist, dass auf „google.de“ kein CNAME-Eintrag angelegt werden kann, auf „www.google.de“ aber schon. In vielen Fällen ist dieser sehr nützlich, deswegen ist es sinnvoll weiter „www“ zu benutzen (aber unnötig dem Benutzer dies anzuzeigen)
> Der technische Hintergrund ist, dass auf „google.de“ kein
> CNAME-Eintrag angelegt werden kann, auf „www.google.de“
> aber schon.
Das ist so nicht korrekt. Es handelt sich um eine technische Limitierung des „bind“-DNS-Servers, nicht von DNS an sich. Andere DNS-Server bieten dafür z.B. ALIAS an, und dann geht das. Ich benötige dieses Feature z.B. für ein Hosting auf platform.sh, wo sich technisch bedingt die IP des Servers minütlich ändert.
ALIAS ist nicht Standard, sondern wird von DNS-Servern dazugebaut. Also doch, dass ist erstmal eine Limitierung des DNS-Standards. Außerdem sind ALIAS und CNAME nicht äquivalent, auch wenn sie am Ende für den Anwender ein gleiches Ergebnis liefern.
Dein „Das ist so nicht korrekt“ ist abgesehen davon sowieso quatsch. Auch wenn andere DNS-Server ALIAS anbieten, bleibt meine Aussage korrekt, dass CNAME auf Apex Domains nicht angewendet werden kann. Manche DNS-Server bieten einen (nicht-äquivalenten) Workaround, aber wer strikt im DNS-Standard bleiben will oder wenn der eigene DNS-Server etwas derartiges nicht bietet, muss weiter auf eine „www“ Subdomain setzen.
Ich fasse zusammen: Du zerrst pingelige Kleinst-Details aus alter Doku, während das Netz schon lange so funktioniert, wie ich schrieb: Dynamische IP-Adressen für Apex-Domains sind nicht nur möglich, sondern essentiell nötig für ale Cloud-Hostings wie AWS oder Azure. „nicht-äquivalenter Workaround“. My shit…
Ich zerre keine pingelige Kleinst-Details aus alter Doku (im übrigen ist ein Standard keine Doku…). Du hast die Aussage „Es handelt sich um eine technische Limitierung des „bind“-DNS-Servers, nicht von DNS an sich“ getroffen, die erwiesenermaßen falsch ist. Es handelt sich um eine technische Limitierung von DNS.
Essentiell nötig sind dynamische IP-Adressen für Apex-Domains ebenfalls nicht. Wessen eigener DNS-Server ALIAS (oder ANAME) nicht unterstützt, oder wer strikt nach Standard handeln will, benutzt ein CNAME auf „www“ und hat das gewünschte Ergebnis.
Über „nicht-äquivalenter Workaround“ kannst du lachen wie du willst. Der Unterschied ist da, und impliziert nunmal auch Nachteile von ALIAS gegenüber einem CNAME auf „www“.
Falsch. Mit und ohne www davor sind zwei völlig unterschiedliche Adressen, die beide separat konfiguriert werden müssen: Im DNS-Server, im Webserver, im Loadbalancer. Derjenige, der die Website baut, muss höllisch aufpassen, dass er nur eine Variante davon verwendet, sonst verliert er seinen Login (neue Session durch Domainwechsel), kann keine Ajax-Requests ausführen (Domainwechsel) oder verliert Punkte im SEO-Ranking (Canonical verweist auf falsche Domain).
Das fällt mir alles innerhalb von 30 Sekunden ein. Wenn ich 30 Minuten nachdenke, wir das mehr.
Kommen wir nun zur langen Liste der Vorteile: „DaS SiEhT HübScH aUs ohNE dReI BuChStaBeN mEhR“ (facepalm)
Geil gememt, Brudi. Ich habe aus Anwendersicht gesprochen. Dem kann es wurscht sein ob www davor steht oder nicht. Dass das für Admins, Devs, etc ein Thema ist das sollte auch klar sein. Die können die Anzeige immer noch ändern. Das weist du auch.
> Anwendersicht
Mich wundert immer wieder, dass Generationen von Leuten ihr Auto wieder fit kriegen, wenn Kleinigkeiten anliegen — aber so was kompliziertes wie eine URL braucht angeblich eine „Anwendersicht“. Und am Ende des Tages braucht man „Antivirensoftware“, damit man nicht auf http://www.bank.phising.foo reinfällt.
Wenn schon „Anwendersicht“, dann einfach ein Häkchen, um die URL gar nicht mehr zu zeigen. Aber sicher nicht falsch.
Wir warten übrigens immer noch auf eine Begründung, weswegen man vorne vier Zeichen einsparen muss, während hinten noch 2 Kilobyte Pfad+GET-Parameter dran hängen.
Hallo,
ich weiß nicht, ob das an meinem Linux liegt. Aber beim Chrome (Version 78.0.3904.70) gibt es in den Flags keine „Omnibox UI Hide“ Option mehr, diese abzuschalten. Vor zwei Wochen gab es die Option noch. Nun ist die komplett draussen.
Liegt nicht an Linux ! Auch unter Windows, Chrome 78.0.3904.97 gibt es in den Flags keine „Omnibox UI Hide“ Option mehr.
Aber, wie oben beschrieben, die aktiviert die Chrome-Erweiterung „Suspicious Site Reporter“ https://chrome.google.com/webstore/detail/suspicious-site-reporter/jknemblkbdhdcpllfgbfekkdciegfboi die vollständige Anzeige der Adresse wieder.